Heute wird mal wieder ne lange Nacht... Muss meine Thesis Morgen Drucken lassen 
Sollte wohl mal wieder mir schnell einige koffeinhaltige Getränke mit hoher Dosis Kaufen gehen. Zum Glück gibts die noch bei Rewe 
Das längste Thema
- fLoo
- Unerledigt
-
-
Wieso kein Kaffee? :o
-
Pff, Kaffee. Schwarzer Tee, das ist das Wundermittel! Wir haben hier zuhause sowie auf Arbeit immer losen Ceylon - einen starken NetCup voll davon trinken und du fühlst dich wie Asterix nach einem Schluck Zaubertrank.
Nur nicht vor dem Schlafen gehen trinken - das habe ich einmal gemacht, da habe ich tatsächlich die halbe Nacht gebraucht, eh ich richtig in den Tiefschlaf gekommen bin.
-
Wieso kein Kaffee?
Zu Schwach
-
Meine Studienkollegen schwörten für Nächte, in denen durchprogrammiert wurde, auf Earl Grey mit Red Bull. Ich hab das Zeug nie angerührt und werde es auch nicht probieren. Schon von Red Bull alleine "in kleiner Dose" krieg ich davon das Herzflattern. Ich brauche das nicht. Zu Risiken und Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker... der Vollständigkeit halber sei auch das erwähnt.
-
-
https://lists.zx2c4.com/piperm…/2020-January/004906.html
WireGuard ist jetzt Upstream im Kernel. -
Hat sich von euch jemand näher mit dem SCP Webservice befasst? Ich hab mal irgendwo gelesen, dass es mehr Befehle gibt als im WIKI beschrieben.
Ziel wäre es einen Server neu zu installieren, z. B. Mit einem der Netcup Image.
Vg fisi -
-
Amazon Marketplace Händler schicken ja gerne mal keine PDF-Rechnung, wenn der Versand über Amazon erfolgt. Normalerweise reicht eine kurze Nachricht an den Händler, manchmal muss auch der Amazon Support freundlich "nachhelfen". Aber diese Antwort ist interessant…
Die schicken mir doch ernsthaft eine chinesische Rechnung als Screenshot in einer PNG-Datei. Soweit, so unspektakulär. Aber das ist nicht meine Rechnung, da steht ein anderes Produkt, ein anderer Preis, ein anderes Datum und…
Alle persönlichen Daten eines anderen Kunden aus Deutschland!
-
-
Manchmal sucht man einfach viel zu umständlich
-
Jetzt mal rein theoretisch... wenn man LXC Container betreibt, dann hat man ja irgendwo die Platten der Container im Filesystem gemountet und kann vom Hostsystem aus direkt darauf zugreifen.
Könnte man dann also hergehen und die Container direkt per Borg sichern, indem man den entsprechenden Ordner angibt, in den dessen rootfs gemountet ist?
Weil so Gerätedateien und sowas liegen ja in RAMdisks, die können einem da nicht in die Quere kommen... oder habe ich da noch irgendwas übersehen, was da Probleme verursachen könnte?
Hintergrund wäre der, dass man mit borg halt einfach Storage sparen kann. Weil die komprimierten vzdump Images brauchen immer so viel Storage und lassen sich auch nicht wirklich inkrementiell speichern. Ist zwar praktisch, weil man die einfacher restoren kann, aber ich sehe irgendwo halt nicht ein, Dateien die sich so ziemlich nie ändern, doppelt und dreifach zu speichern...
-
Erstelle einfach unkomprimierte vzdump Backups. Dann sollte Borg das diffen sauber hinbekommen. Alles andere riskiert die Integrität des Backups.
-
(1) Jetzt mal rein theoretisch... wenn man LXC Container betreibt, dann hat man ja irgendwo die Platten der Container im Filesystem gemountet und kann vom Hostsystem aus direkt darauf zugreifen.
(2) Könnte man dann also hergehen und die Container direkt per Borg sichern, indem man den entsprechenden Ordner angibt, in den dessen rootfs gemountet ist?
Ad (1): Eingebunden sind die "Platten der Container" in der Regel genau dann, wenn die Container laufen; das muss man ansonsten ggf. selbst temporär nachholen. Während die Container laufen, ist zu überlegen, wie sinnvoll/konsistent eine Sicherung zu diesem Zeitpunktist, also sind diese ggf. zu stoppen oder "kontrolliert" einzufrieren.
Ad (2): LXC/LXD arbeitet mit Namespaces, d.h. man muss bei der manuellen Einbindung auch darauf achten, dass dies im Kontext des Archiv-Prozesses berücksichtigt wird, sonst bleiben die Mountpoints "leer" (das ist genau das, was bei Verwendung der LXC/LXD-eigenen Archivierung im Hintergrund gemacht wird).
Abgesehen von diesen beiden Punkten/nach deren Adressierung lassen sich natürlich jegliche Arten von Backups/Werkzeugen einsetzen, um inkrementelle Backups zu erzeugen…
-
Erstelle einfach unkomprimierte vzdump Backups. Dann sollte Borg das diffen sauber hinbekommen. Alles andere riskiert die Integrität des Backups.
Also ich hatte das mal auf dem Server eines Kumpels getestet, den ich für diesem administriere. Da läuft ein ZFS Filesystem mit lzo - im Normalfall sollte das ja auch deduplizieren bzw. live komprimieren. Da haben zwei nahezu gleiche unkomprimerte Tarballs null Kompression o.Ä. gezeigt... jeweils ca. 25 GB, ca. 50 GB waren dann auch belegt.
Ich tendiere da also eher zu einem Backupscript, dass die von m_ueberall angesprochenen Gesichtspunkte beachtet... aber vielleicht teste ich auch erstmal unkomprimierte Tarballs, das wäre tatsächlich einfacher... mal schauen. Danke auf jeden Fall für die Infos!
-
Da läuft ein ZFS Filesystem mit lzo - im Normalfall sollte das ja auch deduplizieren bzw. live komprimieren. Da haben zwei nahezu gleiche unkomprimerte Tarballs null Kompression o.Ä. gezeigt... jeweils ca. 25 GB, ca. 50 GB waren dann auch belegt.
Wieso sollte das deduplizieren? lzo spart nur die Nullen aus, welche du nicht haben kannst.
Für Deduplizierung musst du die Daten aber an den Standard 128k Blöcken ausrichten. Da aber jedes FS 4k Bloclgrösse hast, musst du im ZFS die Recordsize auf 4K setzen. Dann explodiert aber die Dedup-Tabelle in der Größe und du brauchst sehr viel mehr RAM. Für reine tar Archive wie bei lxc via rsync hast du kein 4k Aligment, da ist es sogar noch schlimmer. Dort liegen die Daten auf zufälligen Boundaries.
Keine Deduplizierung, die Standard-Komprimierung bei Standardblockgrösse bzw. 256/512k bringt dir viel mehr für reine tar Files. Dann kannst du ZFS auch mit 512MB betreiben. Das würde ich aber nur fürs Archiv nutzen. Die laufenden VMs/Container kannst du auf einem btrfs mit Standardkomprimierung betreiben. -
Achso - wusste ich nicht. Wieder etwas gelernt.
Naja umbauen kann ich da jetzt nichts mehr (bzw. nur mit hohem Aufwand), will ich auch nicht...
Habe nur der Optimierung halber drüber überlegt, was man so machen könnte.
Aktuell ist es halt auf meinem eigenen Server so, dass die Container in lzo komprimierten tarballs per vzdump auf einer ext4 Partition mit großer Blockgröße gespeichert werden. Und die werden dann nochmal per borg auf mein NAS gesichert, wo sie dann auch nochmal etwas länger liegen.
Die Container selbst laufen live auf ZFS mit lzo. Ist ne feine Sache und dadurch, dass ich die 8GB RAM kaum nutze, kann man da sowohl von der Performance als auch vom Speicherverbrauch her gut was rausholen. Performance nur im Rahmen der Schwuppdizität, ungemessen.
Mein Gedanke lag darin, dass bei den Container ja der Debian (also OS) Unterbau z.B. immer der selbe ist. Allein schon auf Basis der Tatsache, dass jeder Container in einen eigenen Tarball gesichert und anschließend komprimiert wird, verschwendet man da Storage. Denn prinzipiell müsste man das ja z.B. nur einmal speichern. War halt so meine Idee...
Nochmal aus der Theorie heraus die Idee - würde es dann Sinn machen, die tarballs alle unkomprimiert zu speichern und dann alle per Script in einen großen Tarball "reinzukomprimieren"? Oder was würde sich hier anbieten? -
Ich habe mich für Variante mit einer 1TB SSD entschieden. Damit habe ich genug Platz.
Wieso willst du dein ZFS unkomprimiert betreiben? Das macht keinen Sinn, egal ob SSD oder HDD. Du verschenkst Performance damit. -
Wieso willst du dein ZFS unkomprimiert betreiben? Das macht keinen Sinn, egal ob SSD oder HDD. Du verschenkst Performance damit.
Sorry - aber versuchst du mich gerade zu trollen oder hast du meinen Beitrag bloß überflogen?
Weder tu ich das, noch habe ich das vor. Mir ist klar, dass das sinnlos wäre. Das habe ich aber auch geschrieben.
Ich habe 400GB Storage, das ist für mich durchaus ausreichend. Auch wenn das eigentlich keine Rolle spielt... Hier daheim auf dem NAS habe ich sogar noch viel mehr.
Mir geht es nur darum, dass alle LXC Container durch das OS zu eigentlich mindestens 50% gleich sind und man da beim Backup ja eigentlich ein bisschen Storage verschenkt, wenn man das jedes mal für jeden Container extra speichert... und ich überlege, wie man das am elegantesten vermeiden kann.
Ich habe genügend Storage - ich überlege doch nur, wie ich ihn effizienter nutzen kann.
