Ein kleiner Fehler ist im Text versteckt: "Der KVM-Host reagiert auch dann noch zufriedenstellend, wenn gerade ein Backup läuft, der Platzbedarf des Backups ist OK, der Zeitaufwand ebenso."
Interessant wäre es auch gewesen, mal zu sehen wie sich ein per Hand implementiertes Run-Length-Encoding schlägt. Ich nehme an, dass bei Plattenimages viele Wiederholungen (beispielsweise Nullen) vorkommen. Wenn aber irgendwann alle Blöcke mindestens einmal mit Daten aus dem Dateisystem belegt waren wird die Kompressionsrate vermutlich ziemlich gering ausfallen...
Gängige Kompressionsalgorithmen sind generell besser als naives Run-Length-Encoding.
Wenn aber irgendwann alle Blöcke mindestens einmal mit Daten aus dem Dateisystem belegt waren wird die Kompressionsrate vermutlich ziemlich gering ausfallen...
Das versucht man zu minimieren, indem man die virtuelle Disk als Sparse File anlegt oder komplett mit Nullen initialisiert. Aber selbst wenn mal alles voll ist, ist lzop trotzdem noch viel schneller als die anderen
LZ4 und Snappy sollten gleich schnell und gleich gut komprimieren, sind jedoch zusätzlich bei der Dekompression bis zu doppelt so schnell. (kleiner Benchmark des LZ4 machers: https://code.google.com/p/lz4/) Snappy ist von Google und für 64bit Betriebssysteme optimiert. Bei 32bit ist jedoch LZ4 bei weitem schneller. Leider keine Ahnung ob es dafür schon fertige Pakete gibt.
dd umgeht einige Optimierungen beim Zugriff indem es direkt RAW auf das Device-Zugreift, ein normales "<" oder ein cat sollte noch einmal schneller sein und man spart sich das herausfinden der "korrekten" Blockgröße.
Habe auch nie verstanden, warum man bei Block-Devices immer 'dd' benutzt. Vielleicht sehe ich aber auch nur nicht den Unterschied zwischen dd und cat (abgesehen von Blockgrößen und ähnlichem Kram, von DD den ich aber eher hinderlich finde).
Persönlich benutzte ich gerne 'pv' um Block-Devices auszulesen, da man da noch ne schicke Fortschrittsanzeige mitbekommt.
rzip und lzip haben z.B. in einigen Versionen/Compileroptionen Bitfehler produziert. Und defekte Hardware - ein überraschend häufiges Problem - macht das sowieso immer.
Und auch wichtig: Die Prüfsumme extra und nicht inline bilden, also nicht mittels tee vor dem Packen sondern anschliessend mit
gzip -cd test.gz | md5sum
Man will ja wissen ob die Daten korrekt gepackt wurden und nicht ob sie korrekt dem Packer übergeben wurden.
Von Sicher ist sicher am Di, 15. Mai 2012 um 17:51 #
> Und auch wichtig: Die Prüfsumme extra und nicht inline bilden, also nicht mittels > tee vor dem Packen sondern anschliessend mit > > gzip -cd test.gz | md5sum > > Man will ja wissen ob die Daten korrekt gepackt wurden und nicht ob sie korrekt > dem Packer übergeben wurden.
Wenn du eine Prüfsumme von den komprimierten Daten bildest (und prüfst) weißt du doch nicht ob der Komprimierer korrekt gearbeitet hat. Du musst schon die Originaldaten prüfsummen. Was ich oben unterschlagen habe war natürlich das anschließende Überprüfen der MD5-Summe:
> Haben Sie schon einmal versucht, 40 GByte mit gzip zu komprimieren? Das dauert > (fast) ewig, die CPU wird heiß und Ihr Server, wenn er nicht gerade im Leerlauf > läuft, reagiert plötzlich nur noch träge.
Ein Nachtrag: Wer auf einem Vielbenutzer-VM-System unnötig parallel arbeitet verschwendet nunmal Resourcen. Ob der lownice-Job nun mit einem Threat in vier Stunden fertig ist oder mit vier Threats in einer Stunde - das ist egal. Wichtiger ist daß der Viererthreat mehr RAM belegt, mehr Plattenzugriffe in kürzerer Zeit erzeugt usw. D.h. es bleiben für die anderen Mitbenutzer weniger Hochleistungszeitfenster übrig.
1. Hier geht es nicht um Parallelverarbeitung sondern um Hintergrundjobs 2. Ob 1h oder 4h ist nicht egal 3. Die Plattenzugriffe dürften mit xz (was du ja unten selbst vorschlägst) keine Rolle spielen 4. Bei nice 20 werden keine "Hochleistungszeitfenster" verschwendet 5. Threats [sic] treten hoffentlich überhaupt nicht auf
Images werden dadurch MASSIV kleiner. Selbst frisch installierte Partitionen werden bei gzip anschliessend 20-40% kleiner. Bei lange genutzten Partitionen reduziert sich die Grösse oft auf ein Viertel. Das klappt natürlich auch gut mit Windows-Partitionen, selbst ein recht verbasteltes Windows Server oder Arbeitsplatz belegt damit als xz -9e nur einstellige GB-Bereiche.
Wenn es sich irgendwie vermeiden läßt umgehe ich Snapshots auf LVM-Ebene - das gibt "LVM-Fragmentierung" und die kostet unter Umständen höllisch Leistung. Falls man zwei Plattenstapel hat kann man regelmässig die LVMs manuell defragmentieren mittels pv/lvmove.
Also ist mein Ansatz: -VM runterfahren -LV/Partition mittels ionice -c 3 dd als lv.img unkomprimiert sichern -VM hochfahren -lv.img als Loopback mounten und mit Nullen füllen (siehe oben) -lv.img mittels nice -20 xz -9e komprimieren (ionice braucht man bei xz -9e wirklich nicht)
Je nach Wichtigkeit zwischendurch noch eine md5sum.
Ein kleiner Fehler ist im Text versteckt:
"Der KVM-Host reagiert auch dann noch zufriedenstellend, wenn gerade ein Backup läuft, der Platzbedarf des Backups ist OK, der Zeitaufwand ebenso."
Interessant wäre es auch gewesen, mal zu sehen wie sich ein per Hand implementiertes Run-Length-Encoding schlägt. Ich nehme an, dass bei Plattenimages viele Wiederholungen (beispielsweise Nullen) vorkommen. Wenn aber irgendwann alle Blöcke mindestens einmal mit Daten aus dem Dateisystem belegt waren wird die Kompressionsrate vermutlich ziemlich gering ausfallen...
Puh danke, ich hätte den Satz sonst nämlich nicht verstanden mit dem Schreibfehler ...
Ja, der Sinn ist geradezu diametral entgegengesetzt... Schön, dass ich helfen konnte.
Danke, wurde korrigiert.
Cheers,
demon
Gängige Kompressionsalgorithmen sind generell besser als naives Run-Length-Encoding.
Das versucht man zu minimieren, indem man die virtuelle Disk als Sparse File anlegt oder komplett mit Nullen initialisiert. Aber selbst wenn mal alles voll ist, ist lzop trotzdem noch viel schneller als die anderen
Neben gzip, bzip2 und lzop, sollte man auch unbedingt lzip und xz Utils ausprobieren.
Insbesondere mit lzip haben wir sehr gute Erfahrungen gemacht, wenn es um Speed versus Compression geht.
7z und peazip nicht zu vergessen.
LZ4 und Snappy sollten gleich schnell und gleich gut komprimieren, sind jedoch zusätzlich bei der Dekompression bis zu doppelt so schnell.
(kleiner Benchmark des LZ4 machers: https://code.google.com/p/lz4/)
Snappy ist von Google und für 64bit Betriebssysteme optimiert.
Bei 32bit ist jedoch LZ4 bei weitem schneller.
Leider keine Ahnung ob es dafür schon fertige Pakete gibt.
Und wo ist rar?
Das macht sich rar.
Warum dd?
dd umgeht einige Optimierungen beim Zugriff indem es direkt RAW auf das Device-Zugreift, ein normales "<" oder ein cat sollte noch einmal schneller sein und man spart sich das herausfinden der "korrekten" Blockgröße.
Habe auch nie verstanden, warum man bei Block-Devices immer 'dd' benutzt. Vielleicht sehe ich aber auch nur nicht den Unterschied zwischen dd und cat (abgesehen von Blockgrößen und ähnlichem Kram, von DD den ich aber eher hinderlich finde).
Persönlich benutzte ich gerne 'pv' um Block-Devices auszulesen, da man da noch ne schicke Fortschrittsanzeige mitbekommt.
Die Macht der Gewohnheit ... Ich habe es gerade schnell getestet, cat spart tatsächlich nochmals ein paar Sekunden. Danke für den Hinweis!
Klingt irgendwie nach der Wildsau von Graz,
der den UPX-Packer geschrieben hat.
;)
Siehe hier:
http://www.oberhumer.com/opensource/
Jahrelange solide Systemarbeit. Bewundernswert.
Wer einem solch unbekannten Programm nicht ganz traut, hängt noch ein md5sum mit rein:
dd if=/dev/vg0/vmname_snap bs=4M | tee >(md5sum > /backup/vmname.img) | lzop -c > /backup/vmname.img.lzo
(die >(...)-Syntax ist allerdings bash-spezifisch!)
Sollte natürlich heißen:
md5sum > /backup/vmname.img.md5
Sehr wichtiger Hinweis:
IMMER nochmal mit md5sum eine Prüfsumme bilden!!!
rzip und lzip haben z.B. in einigen Versionen/Compileroptionen Bitfehler produziert. Und defekte Hardware - ein überraschend häufiges Problem - macht das sowieso immer.
Und auch wichtig: Die Prüfsumme extra und nicht inline bilden, also nicht mittels tee vor dem Packen sondern anschliessend mit
gzip -cd test.gz | md5sum
Man will ja wissen ob die Daten korrekt gepackt wurden und nicht ob sie korrekt dem Packer übergeben wurden.
> Und auch wichtig: Die Prüfsumme extra und nicht inline bilden, also nicht mittels
> tee vor dem Packen sondern anschliessend mit
>
> gzip -cd test.gz | md5sum
>
> Man will ja wissen ob die Daten korrekt gepackt wurden und nicht ob sie korrekt
> dem Packer übergeben wurden.
Wenn du eine Prüfsumme von den komprimierten Daten bildest (und prüfst) weißt du doch nicht ob der Komprimierer korrekt gearbeitet hat. Du musst schon die Originaldaten prüfsummen. Was ich oben unterschlagen habe war natürlich das anschließende Überprüfen der MD5-Summe:
lzop -dc < /backup/vmname.img.lzo | md5sum -c /backup/vmname.img.md5
> Haben Sie schon einmal versucht, 40 GByte mit gzip zu komprimieren? Das dauert
> (fast) ewig, die CPU wird heiß und Ihr Server, wenn er nicht gerade im Leerlauf
> läuft, reagiert plötzlich nur noch träge.
träge? -> man nice
für die .bash_aliases:
alias lownice='ionice -c 3 nice -n 20'
Hätte man besser nicht zusammenfassen können.
Ein Nachtrag: Wer auf einem Vielbenutzer-VM-System unnötig parallel arbeitet verschwendet nunmal Resourcen. Ob der lownice-Job nun mit einem Threat in vier Stunden fertig ist oder mit vier Threats in einer Stunde - das ist egal. Wichtiger ist daß der Viererthreat mehr RAM belegt, mehr Plattenzugriffe in kürzerer Zeit erzeugt usw. D.h. es bleiben für die anderen Mitbenutzer weniger Hochleistungszeitfenster übrig.
1. Hier geht es nicht um Parallelverarbeitung sondern um Hintergrundjobs
2. Ob 1h oder 4h ist nicht egal
3. Die Plattenzugriffe dürften mit xz (was du ja unten selbst vorschlägst) keine Rolle spielen
4. Bei nice 20 werden keine "Hochleistungszeitfenster" verschwendet
5. Threats [sic] treten hoffentlich überhaupt nicht auf
Ich arbeite ähnlich, aber die Unterschiede sind sicher interessant:
Eine zu sichernde Partition(*1) fülle ich erstmal mit Nullen damit das Image wirklich klein wird, z.B.
mount /dev/whatever /mnt && cat /dev/zero >/mnt/zero ; rm /mnt/zero && umount /mnt
Images werden dadurch MASSIV kleiner. Selbst frisch installierte Partitionen werden bei gzip anschliessend 20-40% kleiner. Bei lange genutzten Partitionen reduziert sich die Grösse oft auf ein Viertel. Das klappt natürlich auch gut mit Windows-Partitionen, selbst ein recht verbasteltes Windows Server oder Arbeitsplatz belegt damit als xz -9e nur einstellige GB-Bereiche.
Wenn es sich irgendwie vermeiden läßt umgehe ich Snapshots auf LVM-Ebene - das gibt "LVM-Fragmentierung" und die kostet unter Umständen höllisch Leistung. Falls man zwei Plattenstapel hat kann man regelmässig die LVMs manuell defragmentieren mittels pv/lvmove.
Also ist mein Ansatz:
-VM runterfahren
-LV/Partition mittels ionice -c 3 dd als lv.img unkomprimiert sichern
-VM hochfahren
-lv.img als Loopback mounten und mit Nullen füllen (siehe oben)
-lv.img mittels nice -20 xz -9e komprimieren (ionice braucht man bei xz -9e wirklich nicht)
Je nach Wichtigkeit zwischendurch noch eine md5sum.
> Wenn es sich irgendwie vermeiden läßt umgehe ich Snapshots auf LVM-Ebene - das gibt "LVM-Fragmentierung"
Wenn man nicht gerade während eines Backups ein "normales" LV anliegt, gibt es keine Fragmentierung.
Außerdem kann man die SS-LVs auch auf ein extra PV legen.