Auf sourceforge.net steht seit kurzem ein von mir bereits heftig verwendetes Backup Tool, welches ein Backup in einem (anderem) Filesystem (z.B. über NFS) anlegt. Hierbei werden inhaltlich gleiche Dateien sowohl innerhalb eines Backups, als auch zur vorherigen Backup-Version verlinkt, so dass nur die Unterschiede Plattenplatz (komprimiert) belegen. Weiterhin sind diverse Massnahmen implementiert, um eine gute Performance (auch auf Multiprozessorsystemen) zu gewährleisten. Tools für das Recovery u.ä. sind ebenfalls vorhanden.
Das Tool ist seit etwa einem halben Jahr im produktiven Einsatz, um knapp 1,5 Mio. Dateien mit etwa 120GB zu sichern. Ein Zugriff auf die zusätzlich vorhandenen Bänder (ausgelagerter Tresor) war seit dem nicht mehr notwendig. Dieses bedeutet eine erhebliche Minderung von Zeit und Aufwand für das Finden und Restaurieren von Dateien. Der Zugriff auf die Dateien ist transparent, kann also z.B. auch über Samba erfolgen.
Es würde mich interessieren, wie die Erfahrungen der Community mit den Tools sind.
> Tools für das Recovery u.ä. sind ebenfalls vorhanden.
Wie schnell und wie erfolgreich sind die Recoverytools bei einem (simulierten) Notfall? Welche Erfahrungen gibt es dafür ?
Das ganze funktioniert (etwas vereinfacht und vom Vorgehen her falsch) folgendermaßen: Der zu sichernde Tree wird an eine andere Stelle kopiert. Über Pattern kann dabei festgelegt werden, welche Dateien kopiert und welche komprimiert werden. Dateien mit demselben Inhalt innerhalb eines Backups werden über Hardlinks erzeugt, ebenfalls zum letzten Backup. Es existiert also jede Datei (nach Inhalt unterschieden) nur ein mal im Backup. Der benötigte Plattenplatz wächst inkrementell, trotzdem sind in jedem Backup alle Dateien vorhanden (gleichzeitig Vorteile von inkrementellen und full Backup). Die Rechte werden gesetzt, wie im Original (falls root das Backup durchführt). Zusätzlich wird eine Datei angelegt, in… Mehr »
Hallo Heinz-Josef,
noch eine Frage zu Hardlinks. Angenommen ich habe in einem Verzeichnisbaum, den ich sichern will, mehrere Directory-Einträge, die auf den gleichen Inode zeigen, also Hardlinks. Werden diese Dateien nach einem eventuellen Restore auch wieder als Hardlinks angelegt?
Harald
Bisher ist diese Option nicht eingebaut. Vielleicht mache ich das noch. Der Bedarf war bisher nicht gegeben, weil wir hauptsächlich folgende Anwendung haben: – Home-Verzeichnisse von Usern (viele MS über Samba) – /etc u.ä., um Änderungen auf Rechnern zu protokollieren (die Verzeichnisse werden erst per rsync auf den Backup-Rechner geholt) – Spiegelung der User-Daten von Windows-Notebooks mittels rsync, dann das gespiegelte in’s storebackup – Sicherung der User-Daten von Laptops mit Linux direkt mit storeBackup. Ein “retten” der originalen Hardlinks sollte optional sein, da das bei großen Verzeichnissen Performance kostet. (Es muss ein weiters dbm-File mit den notwendigen Informationen aufgebaut und… Mehr »
In den nächsten Tagen kommt version 1.4 raus. Die unterstützt dann auch das Restore von Hardlinks.
Momentan laufen noch die letzten Tests, ob alles richtig funktionieriert.
So wie Du das beschreibst, könnte man das ja eigentlich auch mit CVS machen: einfach ein Repository anlegen, alle zu sichernden Dateien mit ‘cvs add’ eintragen und jede Nacht ein automatisches ‘cvs add’ (für neue Dateien – da muss man aber noch mittels ‘file’ erkennen, ob es sich um Daten handelt, weil man da die Option ‘-ko’ geben muß) und ‘cvs ci’ laufen lassen.
Tschüß Andreas
Es existieren (mindestens) folgende Unterschiede: – CVS erkennt Unterschiede in ASCII-Files (für Binärfiles funktioniert es nicht) und speichert Deltas, storebackup komprimiert Dateien – storebackup erkennt doppelt vorkommende Dateien, die dann nur einmal gespeichert werden (Ein extremer Effekt ergibt sich beim Backup von Laptops, die vorher z.B. mittels rsync auf eine zentrale Platte gesichert wurden). – Es kann mittels rm -rf ein beliebiges Backup gelöscht werden. (Keine Ahnung, wie man das mit CVS hinbekommen soll.) – Der Zugriff auf die Daten ist transparent, für ein einfaches Zurücksichern wird kein extra Programm benötigt. Ein “normaler” User (ohne bes. IT-Kenntnisse, z.B. Sekretärin o.ä.)… Mehr »
– Es kann mittels rm -rf ein beliebiges Backup gelöscht werden. (Keine Ahnung, wie man das mit CVS hinbekommen soll.)
Mal eine filleicht dumme Frage. Wenn ich das richtig verstehe, kann es aber dann passieren, dass dadurch eine Originaldatei gelöscht wird, auf die von einem späteren Backup nur noch verlinkt wird. Oder verstehe ich das falsch?
kann es aber dann passieren, dass dadurch eine Originaldatei gelöscht wird, auf die von einem späteren Backup nur noch verlinkt wird. Nein, denn die Links werden bei den Backups als Hardlinks angelegt. Bei Hardlinks zeigen alle Verzeichniseinträge auf den gleichen Inode. Es gibt dabei kein Original und keine Kopien, alle Hardlinks sind gleichberechtigt. Im Inode existiert ein Zähler, der anzeigt, wie viele Verzeichniseinträge es für diesen Inode gibt. Wird nun ein Verzeichniseintrag mit dem Befehl rm gelöscht, so wird auch diser Zähler um eins ernidrigt. Solange der Zähler noch nicht Null ist wird aber der Inode und die Blöcke mit… Mehr »
vielleicht noch ein Beispiel zum Komprimieren und verlinken: Auf dem im obigen Beispiel genannten Rechner benötigen die Sicherungen ungefähr denselben Plattenplatz wie das Original. Das hängt natürlich von den Daten (Kompression) und der Änderungshäufigkeit ab. Folgende Sicherungen existieren (das sieht normalerweise nicht so bescheiden aus, aber Optik ist hoffentlich nicht so wichtig): # storeBackupls.pl /vol0/storeBackup/ Fri Jan 18 2002 2002.01.18_20.23.32 -117 Fri Jan 25 2002 2002.01.25_20.06.22 -110 Fri Feb 01 2002 2002.02.01_20.07.55 -103 Fri Feb 08 2002 2002.02.08_20.05.52 -96 Fri Feb 15 2002 2002.02.15_20.09.31 -89 Fri Feb 22 2002 2002.02.22_20.08.45 -82 Fri Mar 01 2002 2002.03.01_20.06.11 -75 Fri Mar 08… Mehr »
Ich kenne zumindest ein Programm, das (im wesentlichen) das gleiche macht: faubackup. Leider kann ich die Homepage gerade nicht finden, aber zumindest ist es bei Debian zu finden. Da das Paket zwischenzeitlich wegen eines Namenskonflikts nicht verfügbar war, habe ich mir selbst so ein Programm geschrieben. Das gibt es allerdings nirgends öffentlich, weil ich zu bequem bin, dafür Dokumentation zu schreiben. Der Vorteil meines Programms ist, dass es keine zusätzlichen Verwaltungsdateien benötigt und dass man Dateien auch aus dem “Backup” weglassen kann. Beispielsweise werden bei mir (sinngemäß) die Verzeichnisse (und Unterverzeichnisse) “/home/*/.mozilla/default/*/Cache” ausgeschlossen. Ich würde das ganze allerdings nicht als… Mehr »
In der kurzen Beschreibung oben sind nicht alle Optionen enthalten. Das Sicherungsprogramm hat 32 mögliche Parameter (3 müssen angegeben werden). Man kann natürlich auch Verzeichnisse ausblenden. Man kann z.B. definieren, wie log-Dateien rundgeschrieben werden, man kann vor Ablauf einen rsync einbinden, es verwaltet parallele Warteschlangen zum Kopieren und Komprimieren mit anschließender paralleler Abarbeitung. Man kann z.B. sagen, bis zu welcher Tiefe symlinks wie Directories behandelt werden sollen. Hiermit können ganz unterschiedliche Verzeichnisse von einem Startpunkt aus gemeinsam verlinkt und gesichert werden. Es gibt noch weitere nette Optionen, die man sich am Besten im README durchliest. Die zusätzlichen Verwaltungsdaten (komprimiertes ASCII-File)… Mehr »
Eine zusätzliche Info:
Inzwischen sind von sourceforge auch die Mailinglisten freigeschaltet worden.Falls also jemand Fragen, Anregungen o.ä. hat, …
Das Tool “rdiff-backup” http://www.stanford.edu/~bescoto/rdiff-backup/ könnte für einige von euch auch sehr geeignet sein, da es im Prinzip einen Mirror erzeugt und eine Historie beibehält (vielleicht etwas unglücklich von mir formuliert ;-))
–> Vielleicht wäre ein Vergleich/Gegenüberstellung interessant
[1] http://www.stanford.edu/~bescoto/rdiff-backup/