View previous topic :: View next topic |
Author |
Message |
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Mon Dec 23, 2013 3:45 pm Post subject: Inkrementelles Backup eines qemu-qcow2-Images |
|
|
Hallo :-)
Wie mache ich am besten ein inkrementelles Backup eines qemu-qcow2-Images? Namentlich geht es mir vor allem um die „Daten“-Partition eines Windows-Servers, den ich in einer qemu-VM aufgesetzt habe. Da kommen ständig neue Daten dazu, aber die meisten schon vorhandenen ändern sich nicht mehr. Also wäre ein inkrementelles Backup à la rdiff-backup ja eigentlich ganz nett.
Der Server soll, wenn er fertig ist, produktiv bei mir in der Arbeit laufen, deswegen will ich mir vorher ein vernünftiges Backupkonzept überlegen.
Jetzt habe ich mir gedacht, dass ich z. B. immer mal den (virtuellen) Server herunterfahre (tut einem Windows-Server ja eh ganz gut …) und dann das „Daten“-Partitionsimage via qemu-nbd auf dem Host mounte. Klappt ja trotz NTFS wunderbar, und für das Backup brauche ich ja auch nur Lesezugriff. Dann könnte ich davon direkt ein Backup mit rdiff-backup ziehen.
Interessanter wird dann die Wiederherstellung, aber das müsste man ja eigentlich auch hinbekommen. Evtl. mit einer anderen virtuellen Maschine.
Ein komplettes Backup des ganzen Images zu ziehen wäre natürlich von der Wiederherstellung her das komfortabelste, weil ich dann im Fall der Fälle genau das Image wieder booten bzw. verwenden könnte, notfalls auch auf anderer Hardware.
Es sind aber schon ein paar Gigabyte, die da anfallen, deswegen würde ein vollständiges Backup immer sehr lange dauern – man müsste ja immer alles speichern.
Jedes Mal einen Snapshot machen führt natürlich dazu, dass ich irgendwann mal sehr viele Snapshots habe, die alle aufeinander aufbauen … im Prinzip würde ja aber ein Snapshot exakt die Daten enthalten, die sich geändert haben – also die, die meinem letzten Backup fehlen. Könnte man evtl. z. B. den Server mit einem Snapshot fahren, dann immer den Snapshot kopieren und danach in die backing file mergen? Damit sich eben nicht die Snapshots anhäufen?
Wie stellt man das am besten an? Gibt es da evtl. eine elegante Lösung?
VG |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Mon Dec 23, 2013 4:45 pm Post subject: |
|
|
rsync würde nur die Änderungen im Image übertragen, aber auf die Optionen für Sparsefiles achten. |
|
Back to top |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Mon Dec 23, 2013 5:24 pm Post subject: |
|
|
Aber muss rsync dafür nicht das komplette Image lesen? Sowohl auf der einen, als auch auf der anderen Seite? Da würden doch auch große Datenmengen bewegt, oder? |
|
Back to top |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Tue Dec 24, 2013 10:58 am Post subject: |
|
|
Ich habe gerade mal rdiff-backup ausprobiert (was ja rsync nutzt). Das Backup dauert ewig, auch wenn sich kaum was verändert hat (z. B. die VM nur gebootet und wieder heruntergefahren, der Snapshot war ca. 40 MB groß). Es dauert eigentlich genauso lang, wie gleich das ganze Image zu kopieren.
Was wäre mit folgendem Konzept:
Ich lasse die VM nicht direkt auf dem Image laufen, sondern mit einem Snapshot, der das eigentliche Image als Backing-File benutzt. Dann werden ja alle Änderungen in dieses zweite Image geschrieben. Als Backup habe ich (ja sowieso) erstmal das Original-Image. Wenn ich jetzt mein Backup aktualisieren will, dann kopiere ich einfach den Snapshot (der ja alle geänderten Daten enthält). Danach merge ich den Snapshot ins Backing-File, lösche ihn und erstelle einen neuen, auf dem dann die VM wieder hochgefahren wird.
Man müsste halt auch auf der Backupseite den Snapshot mergen, weil der neue Snapshot ja dann nicht mehr auf dem alten, sondern auf dem aktualisierten Image beruht, oder? Also könnte man zwar keine älteren Zustände wiederherstellen, aber zumindest hätte man das komplette lauffähige Image immer aktuell, ohne es komplett übertragen zu müssen.
Oder habe ich jetzt da irgendwo einen Denkfehler?! |
|
Back to top |
|
|
ixo Guru
Joined: 09 Jul 2005 Posts: 375
|
Posted: Sun Dec 29, 2013 10:12 pm Post subject: |
|
|
Du könntest storeBackup (mit "blocked files") verwenden. Dann ist jedes Backup ein Full Backup obwohl nur der Platz eines inkrementellen benötigt wird. Im Backup sind die Daten (wenn Du willst) auch noch komprimiert. Die Zurücksicherung kannst Du mit dem Tool oder mit Bordmitteln (cat bzw. z.B. bzcat) durchführen.
Schnell ist es auch noch, insbesondere mit der Option lateLinks.
Finden kannst Du das Ganze hier:
http://savannah.nongnu.org/projects/storebackup
bzw.
http://www.nongnu.org/storebackup/de/
Falls Du Dir das ansehen willst; hier http://www.nongnu.org/storebackup/de/node20.html werden die zugrunde liegenden Prinzipien erläutert.
Grüße, ixo |
|
Back to top |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Tue Dec 31, 2013 12:59 pm Post subject: |
|
|
Klingt interessant, das werd ich mal ausprobieren! Was bisschen gruselig ist, ist die Tatsache, dass es in Perl geschrieben ist … |
|
Back to top |
|
|
ixo Guru
Joined: 09 Jul 2005 Posts: 375
|
Posted: Tue Dec 31, 2013 7:05 pm Post subject: |
|
|
l3u wrote: | Was bisschen gruselig ist, ist die Tatsache, dass es in Perl geschrieben ist … |
Noch schlimmer - das Zeugs läuft auf irgendwas in C geschriebenem von langhaarigen, bekifften Bombenlegern ...
SCNR,
ixo
PS: berichte mal, ob's passt |
|
Back to top |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Wed Jan 01, 2014 11:55 am Post subject: |
|
|
Mal im Ernst: ich hab früher auch einiges in Perl geschrieben, aber ich bin runter von dem Zeug ;-)
Hab’s mal ausprobiert.
Das System-Image hat ca. 11 GB. Das erste Backup hat entsprechend lang gedauert, etwa 10 Minuten.
Dann hab ich mal die VM gebootet, ein paar Programme geöffnet und geschlossen und sie wieder heruntergefahren.
Hinterher ging das Backup dann in ca. 5 Minuten. Also schonmal was! Immerhin ist es inkrementell und schneller im Vergleich zum „einfach so“ kopieren. Denke ich zumindest.
Hat man eigentliche eine Chance, zu sehen, wir groß das Inkrement eigentlich ist? Weil du- sh . scheint ja die Hardlinks mitzuzählen, so dass in meinem Beispiel (trotz nur kleiner Änderungen) beide Backupstadien ca. 11 GB groß waren. |
|
Back to top |
|
|
bell Guru
Joined: 27 Nov 2007 Posts: 510
|
Posted: Wed Jan 01, 2014 4:20 pm Post subject: |
|
|
Wenn Du Code: | du -sh $backup1dir $backup2dir | eingibst, werden bei $backup2dir die Hardlinks nicht mitgezählt. Mit "-c" bekommst Du auch den tatsächlich verbrauchten Speicher. |
|
Back to top |
|
|
ixo Guru
Joined: 09 Jul 2005 Posts: 375
|
Posted: Wed Jan 01, 2014 4:41 pm Post subject: |
|
|
Also ich habe hier zwei Backups (auch mit "blocked files"):
Code: | # du -sh 2013.12.19_20.16.29 2013.12.20_15.52.59
18G 2013.12.19_20.16.29
57M 2013.12.20_15.52.59
|
Das heißt, das erste Backup hat insgesamt 18G, beim zweiten kommen 57M neu dazu. Das heißt nicht, dass die zweite um 57M größer sein muss, es können ja auch Dateien entfallen sein (da zwischendurch im Original gelöscht oder es sind überschriebene Blöcke einer der "blocked files").
Verwendest Du noch Kompression? Was hast Du für Werte?
Du kannst auch die Option lateLinks verwenden. Dann siehst Du vor Lauf von storeBackupUpdateBackup.pl genau, wie groß Dein inkrementelles Backup (noch ohne vervollständigende Hardlinks) ist.
Außerdem gibt es bei dem Tool noch ein Programm namens storeBackup_du.pl, was aber nicht ganz einfach zu verstehen ist.
Grüße, ixo
Ach ja, und Edith meint, mit der Option progressReport sagt Dir das Teil auch noch ein bisschen, wie weit es so ist. |
|
Back to top |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Thu Jan 02, 2014 1:51 pm Post subject: |
|
|
Kompression habe ich bisher nicht benutzt, weil mir der benötigte Speicherplatz erstmal egal ist – ich will erst das Backup an sich zum Laufen bekommen!
Die Sache mit der Option lateLinks habe ich auch gesehen, aber ich komm doch eh nicht drum rum, die Hardlinks zu erstellen, oder?! Weil sonst kann doch das Programm beim nächsten Backup nicht mehr auf das vorherige Inkrement aufbauen – oder sehe ich das falsch?
Weil dann dauert zwar das Backup weniger lang, aber dafür muss ich die Zeit eben hinten dranhängen … |
|
Back to top |
|
|
ixo Guru
Joined: 09 Jul 2005 Posts: 375
|
Posted: Thu Jan 02, 2014 2:15 pm Post subject: |
|
|
Ich verwende das "blocked files" hauptsächlich für mehrere pst-Dateien (der Outlook Kram, bin ich gezwungen zu verwenden ). Die größte ist etwa 3,6GB groß und für eine (zusätzliche) Sicherung benötigt ich meist so ein oder zwei dutzend MB. Kompression verwende ich, da sie wenig Zeit kostet (außer beim ersten Mal) und ich so einfach mehr Backups (also eine längere Historie) unterbringe.
LateLinks bringt in Summe nur etwas, wenn Du über das Netz sicherst und die Links dann später lokal (anstelle über's Netz) erzeugt werden. Lokal führt es nur dazu, dass die reine Backupzeit (mit ggf. Downtime) niedriger ausfällt. Das Setzen der restlichen Hardlinks passiert dann später. Übrigens kannst Du mit lateCompress auch später komprimieren.
Du kannst auch so viele Backups mit lateLinks hintereinander machen, wie die willst. Nur musst Du irgendwann die Hardlinks erzeugen, damit Du wieder vollständige Backups zum Zurücksichern hast und irgendwann auch Löschen kannst. (Das Tool berücksichtigt das - nur wenn Du anfängst mit rm selbst herumzulöschen kann das in die Beinkleider gehen.)
Übrigens sollte das Backup Deines Images auch ohne Kompression wahrscheinlich kleiner sein als das Original. Wenn es sich um Dateien mit vielen Nullen drin (oder Sparse Files) handelt, bewirkt die Deduplikation von storeBackup, dass diese identischen (also nur Nullen) Teilstücke ver-hardlinkt werden.
Beim Zurücksichern kannst Du übrigens auch wieder Sparse-Files erstellen (Irgend'ne Option bei storeBackupRecover.pl).
Wieviel zusätlichen Platz hast du in Deinem Beispiel denn noch benötigt? (Die Spannung erreicht inzwischen im Forum sicherlich schon den Siedepunkt .)
ixo |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|