Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Inkrementelles Backup eines qemu-qcow2-Images
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum
View previous topic :: View next topic  
Author Message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2099
Location: Konradsreuth (Germany)

PostPosted: Mon Dec 23, 2013 3:45 pm    Post subject: Inkrementelles Backup eines qemu-qcow2-Images Reply with quote

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
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1493
Location: St. Wendel

PostPosted: Mon Dec 23, 2013 4:45 pm    Post subject: Reply with quote

rsync würde nur die Änderungen im Image übertragen, aber auf die Optionen für Sparsefiles achten.
Back to top
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2099
Location: Konradsreuth (Germany)

PostPosted: Mon Dec 23, 2013 5:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2099
Location: Konradsreuth (Germany)

PostPosted: Tue Dec 24, 2013 10:58 am    Post subject: Reply with quote

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
View user's profile Send private message
ixo
Guru
Guru


Joined: 09 Jul 2005
Posts: 375

PostPosted: Sun Dec 29, 2013 10:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2099
Location: Konradsreuth (Germany)

PostPosted: Tue Dec 31, 2013 12:59 pm    Post subject: Reply with quote

Klingt interessant, das werd ich mal ausprobieren! Was bisschen gruselig ist, ist die Tatsache, dass es in Perl geschrieben ist …
Back to top
View user's profile Send private message
ixo
Guru
Guru


Joined: 09 Jul 2005
Posts: 375

PostPosted: Tue Dec 31, 2013 7:05 pm    Post subject: Reply with quote

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

:lol:

PS: berichte mal, ob's passt :-)
Back to top
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2099
Location: Konradsreuth (Germany)

PostPosted: Wed Jan 01, 2014 11:55 am    Post subject: Reply with quote

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
View user's profile Send private message
bell
Guru
Guru


Joined: 27 Nov 2007
Posts: 426

PostPosted: Wed Jan 01, 2014 4:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
ixo
Guru
Guru


Joined: 09 Jul 2005
Posts: 375

PostPosted: Wed Jan 01, 2014 4:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2099
Location: Konradsreuth (Germany)

PostPosted: Thu Jan 02, 2014 1:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
ixo
Guru
Guru


Joined: 09 Jul 2005
Posts: 375

PostPosted: Thu Jan 02, 2014 2:15 pm    Post subject: Reply with quote

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 :P .)

:-) ixo
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum All times are GMT
Page 1 of 1

 
Jump to:  
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