# Inkrementelles Backup eines qemu-qcow2-Images

## l3u

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

----------

## py-ro

rsync würde nur die Änderungen im Image übertragen, aber auf die Optionen für Sparsefiles achten.

----------

## l3u

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?

----------

## l3u

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?!

----------

## ixo

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

----------

## l3u

Klingt interessant, das werd ich mal ausprobieren! Was bisschen gruselig ist, ist die Tatsache, dass es in Perl geschrieben ist …

----------

## ixo

 *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

 :Laughing: 

PS: berichte mal, ob's passt  :Smile: 

----------

## l3u

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.

----------

## bell

Wenn Du 

```
du -sh $backup1dir $backup2dir
```

 eingibst, werden bei $backup2dir die Hardlinks nicht mitgezählt. Mit "-c" bekommst Du auch den tatsächlich verbrauchten Speicher.

----------

## ixo

Also ich habe hier zwei Backups (auch mit "blocked files"):

```
# 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.

----------

## l3u

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 …

----------

## ixo

Ich verwende das "blocked files" hauptsächlich für mehrere pst-Dateien (der Outlook Kram, bin ich gezwungen zu verwenden   :Sad:  ). 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   :Razz:  .)

 :Smile:  ixo

----------

