darUrsprünglich gepostet auf debian-user-german:
Date: Fri, 13 Jul 2007 00:49:47 +0200
From: Fabian Pietsch <fabian@canvon.dyndns.org>
To: debian-user-german@lists.debian.org
Subject: Re: rsync für Wechseldatenträger
Message-ID: <20070712224947.GB20274@zzznowman.dyndns.org>
User-Agent: Mutt/1.5.9i
Hallo Martin!
* Martin Steigerwald <Martin@lichtvoll.de> (Thu, 12 Jul 2007 22:53:05 +0200):
> Kennt jemand so etwas wie rsync für Wechseldatenträger?
>
> Konkret möchte ich wichtige Teile meines Homeverzeichnisses, ingesamt
> bestimmt so 20GB, auf DVD-RAM-Rohlinge sichern. Da hätte ich gerne etwas,
> dass einerseits wie rsync nur die Änderungen kopiert, andererseits jedoch
> die Datenmenge in Rohling-gerechte Happen aufteilt:
>
> Ein Verzeichnis kleiner 4GB sollte es möglichst auf einen Rohling
> kopieren, größere aufteilen. So, dass man halt dann sehr einfach mit
> Bordmitteln wie rsync ein Verzeichnis zurückkopieren kann. Oder es sollte
> halt selbst eine gute Restore-Funktion bieten.
>
> Am liebsten jedoch möchte ich die Dateien wie mit rsync 1:1 kopieren. Das
> kann mitunter bei DVDRAM lange dauern, jedoch müssen ja nur beim ersten
> Mal alle Dateien kopiert werden.
>
> Es sei denn, jemand überzeugt mich von den Vorteilen eines anderen
> Ansatzes ;).
Etwas DVD-RAM-spezifisches oder semantisch sinnvoll aufteilendes wüsste
ich jetzt nicht; aber vielleicht könnte dir dar (Disk ARchiver)
gefallen. (Wurde auch kürzlich in einem anderen Thread thematisiert,
vielleicht ab [1].)
Mit dar kannst du in dar-spezifische Archivdateien sichern, aus denen
man dank dem Vorhandensein eines Index im Archiv effizient einzelne
Dateien/Verzeichnisse extrahieren kann, ohne das ganze Archiv lesen zu
müssen (wie z.B. bei tar). Es kann Kompression (-z, -y) und
Verschlüsselung (-K).
dar kann die Archivdateien in "slices" vorgegebener Größe aufteilen
(-s)[a]; dies kann auch nachträglich vorgenommen und leicht von einer
Slice-Größe auf eine andere umgeschrieben werden (dar_xform), außerdem
kann für das erste Slice eine andere Größe angegeben werden (-S)[b].
Reslicing erfordert keine Rekompression oder Ent- und Neuverschlüsselung.
[a] z.B. die eines DVD-Mediums; nach jedem Slice kann ein
beliebiger Befehl ausgeführt (-E) oder einfach gewartet (-p) werden,
z.B. bis man sie gebrannt und gelöscht hat, bei wenig Platz.
[b] z.B. der restliche Platz auf einem bereits angefangenen Medium.
Inkrementelle Backups sind möglich (-A)[2]; dazu kann man ein bestehendes
Archiv oder einen daraus nachträglich extrahierten (-C) oder während der
Sicherung erstellten (-G) Index bzw. "catalogue" als Referenz verwenden.
Man kann Archive oder Indices an eine Index-Verwaltung (dar_manager)
verfüttern, die einem Auskunft darüber geben kann, welches Archiv die
letzte Version einer Datei enthält, und dar mit den nötigen Parametern
zur Wiederherstellung selbst aufrufen kann.
Dadurch, dass man bei inkrementeller Sicherung die Referenz explizit
angibt, sind verschiedene Sicherungs-Schemata möglich; z.B. ein
Full-Backup (ohne Referenz), ein inkrementelles (das das Full-Backup als
Referenz angibt), ein weiteres inkrementelles (mit dem letzten
inkrementellen als Referenz) und immer so weiter. Geht einem da aber
auch nur ein Glied in der Kette verloren, vorzugsweise ziemlich zu
Anfang, kann man einen Teil der Daten möglicherweise nichtmehr
wiederherstellen.[3]
Alternativ könnte man *jedes* inkrementelle Backup mit dem Full-Backup
als Referenz erstellen, bräuchte zum Wiederherstellen also nur diese
beiden. Auch könnte man die Ketten-Referenz-Strategie von oben
verwenden, aber einmal die Woche erneut das Full-Backup (statt dem
letzten inkrementellen) referenzieren und die Kette dadurch quasi (fast)
von vorne beginnen. Vielleicht auch monatlich ein neues Full-Backup
ziehen und ab dann das referenzieren.[3] Beliebige andere Kombinationen
sind denkbar.
Willst du medientechnisch günstige Verteilung deiner Daten, kannst du
vielleicht manuell das beste Ergebnis erzielen: In Gruppen aufteilen
durch Ein-/Ausschluss bestimmter Verzeichnisse (-I/-X, -[/-]), am besten
in Kombination mit dar-Konfigurationsdateien (-B). Der Index-Verwaltung
gibt man eh explizit eine Datenbankdatei an, es ist also kein Problem,
hier voneinander unabhängige Backup-Ketten zu verwalten.
Viel Erfolg!
Fabian
[1] http://lists.debian.org/debian-user-german/2007/07/threads.html#00396
[2] Meines Wissens nach ist dies jedoch nur auf Dateisystems-Ebene
inkrementell; d.h., hast du eine sehr große Datei, die sich häufig
ändert (z.B. ein disk image für einen Emulator wie qemu?), hättest du
ein Problem -- denn bei jedem Backup würde es wieder im Ganzen
gesichert.
Meiner Erfahrung nach komprimieren solche Images aber erstaunlich gut,
es ist also mit -z/-y vielleicht gar kein Problem. Ansonsten könnte man
das Image auch vom Backup ausschließen (-X, -]) und das enthaltene
System "von innen heraus" sichern.
[3] Man fürchte sich vor Medien-Fehlern! ;) Auch durch Alterung allein.
Dagegen kann man aber wohl par verwenden, z.B. über -E:
http://lists.debian.org/debian-user-german/2007/07/msg00558.html
--
Fabian "zzz" Pietsch - http://zzz.arara.de/
Note: This document is (somewhat) valid HTML4.01, not XHTML.