Hallo, -------- Original-Nachricht --------
Datum: Sun, 22 Mar 2009 19:19:57 +0100 Von: Heinz Diehl <htd@fancy-poultry.org> An: opensuse-de@opensuse.org Betreff: Re: Danke: backup-Programm
At Sun, 22 Mar 2009 15:26:08 +0100, Thomas Michalka wrote:
Heinz, Deine Empfehlung ist eher eine Synchronisation von Verzeichnisinhalten als, was man unter einem Backup versteht.
Ja, so habe ich das auch beschrieben. Es gleicht das Zielverzeichnis mit dem Quellveryeichnis ab, und da...
Ja, aber nach dem Subject wollte der OP eben ein Backup-Programm, kein Synchronisationswerkzeug für den allerletzten Stand.
Sie ist sogar gefährlich, und zwar wegen --delete. Hast Du nämlich im Zielverzeichnis schon ein älteres Backup, werden dort mit Deiner Empfehlung alle Dateien gelöscht, die zuvor im Quellverzeichnis und dessen untergeordneten Verzeichnissen gelöscht wurden.
...ist es perfekt, wenn die Veraenderungen aus dem Quellverzeichnis auch im Zielverzeichnis ausgefuehrt werden.
Ist es das für Dich auch, wenn Du versehentlich eine ultra-wichtige Datei löschst? Woher holst Du die dann zurück? Na, Du wirst ja sicher noch an anderer Stelle ein richtiges Backup haben.
War nur ein Vorschlag, analog zu dem, wie ich meine Backups mache. Wenn bei mir eine Platte defekt
Also machst Du "Backups" doch so. Nach allen Regeln der Kunst sind das aber keine, denn: Schlagartig defekte Platten kommen (nicht nur nach meinen Erfahrungen) extrem selten vor im Gegensatz zu benutzerverursachten "Unfällen" und schleichenden Ausfällen. In der Häufigkeit vergleichbar mit letzteren sind n. m. Erf. Defekte in Dateisystemen - klar, weil schleichend kaputtgehende Platten Inkonsistenzen in Dateisystemen verursachen können. Das ist eine besonders heimtückische Fehlerquelle, bei der sich über Tage die defekten Superblocks, Inodes häufen können und sich damit die Zahl der unerreichbaren Dateien allmählich häuft. Das kann dazu führen, daß mit --delete Dateien auf dem Backup-Medium in der einzigen Sicherung gelöscht werden, die Du selber auf dem Quellmedium nicht mal versehentlich gelöscht hast, denn eine Datei, die nicht auffindbar ist, ist für rsync nicht vorhanden.
ist, dann will ich den aktuellen Stand zurueckspielen,
In den von mir beschriebenen Fällen, ist der letzte Stand ein Mißstand, wahrscheinlich voller Inkonsistenzen, den Du doch kaum wiederhaben willst, oder?
und da nuetzen mir evtl. aeltere Daten nichts. Deswegen --delete.
Ältere Daten, die Du nicht mehr willst, wirst Du sicher absichtlich gelöscht haben. Überlege Dir mal, was rsync --link-dest in einem anschließenden Backup tut, besser gesagt "nicht tut". Es sichert natürlich in den letzten gültigen Backup, zunächst ein leeres Verzeichnis, nennen wir es <backup-base-dir>/2009-03-3__daily.letzter/home, *keine* gelöschten Dateien, d.h. es legt auch keine Hardlinks auf Dateien an, die in einem früheren Backup noch gesichert wurden. Hardlinks legt rsync --link-dest nur auf vorhandene _und_ unveränderte Dateien im Backup <backup-base-dir>/2009-03-3__daily.1/home an, wenn man das als Referenzverzeichnis hinter --link-dest angibt. Natürlich kann man auch *.daily.28/home wählen, dann ist nur die Menge der tatsächlich kopierten Daten größer, was sowohl den Vorteil der Speicherplatz- als auch der Backup-Zeitersparnis schmälert. Sagen wir, Du behältst 28 tägliche Backups von *.daily.01/home bis *.daily.28/home, dann besteht eine gute Chance, die wie auch immer in den letzten 28 Tagen verlorenen Dateien aus 28 Backup-Generationen wiederherzustellen. Diese Chance hast Du überhaupt nicht, wenn Du immer nur im selben Zielverzeichnis den allerletzten Stand zu Deiner Quelle synchron hältst. Also nützen Dir ältere Backup-Generationen sehr wohl etwas.
Das ist in diesem Falle kein Sicherheitsrisiko, sondern erwuenscht.
Ein Sicherheitsrisiko ist es auf jeden Fall für den, der glaubt oder den man glauben macht, er hätte damit ein sicheres Backup. Wer, wie Du, weiß was er tut, geht das Risiko bewußt ein. Aber Du solltest niemandem raten, mit --delete Backups anzulegen, der noch kein Backup-Werkzeug kennt und auch noch fragt, wie man die Dateisysteme auf den Partitionen bestimmen kann. Da wäre es ja noch besser ohne --delete in nur ein Verzeichnis zu synchronisieren. Fällt Dir eine Platte ohne Vorwarnungen aus, dann haben Backups mit Hardlinks den Vorteil, daß Du den letzten gesicherten Stand, wie von einem Voll-Backup auf einen Rutsch wiederherstellen kannst. Also mußt Du nicht einen alten Voll-Backup plus eine oder mehrere differentielle Sicherungen einspielen. Zusätzlich kannst Du evtl. früher schon gelöschte Dateien wiederherstellen. Noch ein Vorteil: jeder Benutzer kann das selber tun, wenn Du ihm z.B. per NFS die Backup-Generationenverzeichnisse vom Backup-Server readonly zur Verfügung stellst, vorausgesetzt, Du hast die Daten mir der Option --numeric-ids gesichert, denn die Benutzer-Accounts wird es dort i.d.R. nicht geben. Solltest Du aber gar keine richtigen Backups machen wollen, sondern nur den letzten Stand sychronisieren, dann habe ich an Deiner Intention vorbeigeschrieben, aber Du hättest dann in diesem Thread das Thema verfehlt, denn es ging von Anfang an um Backup-Software. BTW: Interessanterweise sieht man an der Statistik, die rsync am Ende eines Backups ausgibt (--stats, s.u.), wenn sich die Zahl der Dateien in einem Quellverzeichnis über einen relativ kurzen Zeitraum ungewöhnlich stark verringert, vorausgesetzt man liest das Logfile hinundwieder. Das sieht z.B. so aus: Number of files: 2351460 Number of files transferred: 713 Total file size: 154.07G bytes Total transferred file size: 273.97M bytes Literal data: 273.97M bytes Matched data: 0 bytes File list size: 53.73M File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 327.95M Total bytes received: 212.58K sent 327.95M bytes received 212.58K bytes 208.52K bytes/sec total size is 154.07G speedup is 480.76 Diesen Endabschnitt des Logfiles kann man auch automatisch auf ungewöhnliche Veränderungen charakteristischer Kennzahlen analysieren und sich das Ergebnis per Mail schicken lassen. Verringern sich z.B. "Number of files", "Total file size" und/oder "File list size", könnte mit dem Dateisystem was faul sein. Aber dafür gibt es vielleicht noch bessere Indizien. Da käme --delete vielleicht doch wieder zu Ehren. Man könnte z.B. ein Verzeichnis zur Kontrolle parallel zu jedem Backup-Lauf mitsynchronisieren (mit --delete und mit --link-dest, was enorm Zeit und Platz spart). Wenn eines Tages im Logfile ungewöhnlich viele Löschungen verzeichnet würden, könnte einen das auch stutzig machen. Aber: Das Löschen von großen Verzeichnisbäumen kann beim Backup erheblich Zeit kosten, so daß der Zeitraum des Backups relativ lang wird, was bei voneinander abhängigen Dateien zu Inkonsistenzen führen kann. Übrigens ist gerade der Zeitvorteil bei Backups mit Hardlinks gegenüber Voll-Backups gewaltig. Meine 154 GBytes von /home werden vollständig in knapp sechs Stunden, als differentieller Backup plus Hardlinks in ca. 26 Minuten kopiert! Nur so kann man überhaupt sinnvolle stündliche Backups machen.
Ansonsten hatte ich dem OP auch zualererst empfohlen, die manpage zu lesen. ;-)
Das ist generell sinnvoll, vor allem bei einer so guten. Ciao, Tom -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org