michahe
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 824
|
Ich möchte die Backup-Strategie für meinen Arbeitsrechner (Laptop) neu definieren und bitte um Euer Feedback zu folgenden Ansätzen und Fragen:
Die Backups sollen in Einzeldateien erfolgen. Gesichert werden alle Verzeichnisse gemäß Wiki Datensicherung Was und woher ... Die Backup-Routine soll alle Einzeldateien in den zu sichernden Verzeichnissen komplett synchron halten (Neue Dateien werden im Sicherungsziel hinzugefügt, veränderte (Größe, Zeitstempel, Eigenschaften) im Sicherungsziel überschrieben, gelöschte im Sicherungsziel entfernt. Sicherungsziele sind Festplatten / SSD, teils in Wechselrahmen, über lokales Netz erreichbar, gelagert an unterschiedlichen Orten; online-Sicherung mangels Bandbreite kaum möglich. Die Platten werden gemäß Türme-von-Hanoi - Prinzip bespielt: Z: täglich A: 2 Wochen B: 4 Wochen C: 8 Wochen D: 16 Wochen
Mängel am oder Verbesserungspotentiale für das Konzept? Software- oder Skript-Empfehlungen für dieses Konzept? Die Einstellungen der zu sichernden Verzeichnisse ist ja immer gleich; das Sicherungsziel jedoch unterschiedlich. Ich möchte für alle Varianten eine "Oberfläche", in der A..D oder Z ausgewählt wird und los geht's. Wahrscheinlich werden die Sicherungen manuell angestoßen, da es kein festes Zeitschema gibt, in dem der Laptop im lokalen Netz ist und wenig / nicht genutzt wird. Wenn möglich auch Nutzung von USB-Platten mit einer Software / einem Skript. rsync sagt mir zu, ein Beispiel-Script würde mir beim Lernen helfen. Mit diesem Konzept hätte ich eine Generationen-basierte Sicherung der Anwendungsdaten. Bei Ausfall des Arbeitsrechners müsste ich in Kauf nehmen, Betriebssystem und Software zunächst neu zu installieren und zu konfigurieren. Macht es Sinn, parallel dazu noch ein Image zu haben und wie kann ich Nutzerdaten von Konfigurationen beim Restore sauber abgrenzen? Wird die Laptop-Platte zerstört, könnte das Image das Neu-Aufsetzen beschleunigen, bei Ausfall des Bildschirms kommt ganz neue Hardware und das Image nützt gar nichts, oder? Plattenprüfung: Erforderlich oder sinnvoll? Wenn ja: Wie? Sonstige Empfehlungen?
Vielen Dank.
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8525
|
Bei dem Konzept hast Du eine riesige "Verschwendung" von Plattenplatz. Ich würde höchstens 1-2 Platten für eine direkte Dateissynchronisation nehmen, z.B. täglich und wöchentlich. Ansonsten würde ich zur Langzeitarchivierung zusätzlich platzsparende inkrementelle Sicherungen, z.B. mit BorgBackup anlegen. Die kannst Du täglich (oder öfter) machen und die Snapshots automatisch "ausdünnen" lassen. Ggf. kannst Du mehrere Platten noch wöchentlich rotierend wechseln und an unterschiedliche Orten lagern.
|
Seebär
Anmeldungsdatum: 2. Mai 2009
Beiträge: 829
|
Zuerst: Zustimmung zu Thomas_Do. BorgBackup kann ich aus der Praxis (!) empfehlen. michahe schrieb: Sonstige Empfehlungen?
Ja, mal hinterfragen was die Anforderungsliste soll. Ernsthaft. Mir kommt das z.T. theoretisch vor. Das "Türme von Hanoi"-Prinzip ist schlechter als das was was du mit vorgenannter Lösung/SW erreichen kannst. Du wirst alleine schon gigantische Aufwände bis hin zur Nichtverwendbarkeit haben die für einen Restore richtige Platte zu finden. Nebenbei: was ist denn bitte eine "Einzeldatei"? Ich dachte hier zuerst an eine Sicherung in einer .tar.gz (nur bei kleineren Datenmengen sinnvoll, da sonst nicht handlich/träge), das meintest Du aber nicht. Was die örtlich getrennte Sicherung angeht: wie soll man sich das vorstellen? Einen Satz Datenträger im 2. Stock, einen weiteren im 7. Stock? Dann ok (es sei denn das ganze Gebäude brennt ab). Wenn es aber Rack-A und Rack-B nebeneinander sind: dann für die Füße. Was das Prüfen der Datenträger angeht: das klingt gut, da hätte ich auch gerne eine Antwort.
Und nebenbei: immer den Restore prüfen, sonst nutzt alles nüschte. Nachtrag: du redest hier von der Sicherung der Daten (d)eines Laptops? Das wichtigste ist es, überhaupt die Sicherung zu machen (weniger Hanoi etc...). Alles, was nicht automatisch geht, geht vergessen / wird schwierig. Wie man das machen will, hängt aber von den Gegebenheiten ab. Eine Möglichkeit wäre z.B. anachron und als Ziel Verwendung eines NAS (oder was immer als Sicherungsziel verfügbar ist). Oder: Disziplin.
|
michahe
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 824
|
Vielen Dank Thomas_Do und Seebär für Eure Hinweise und Ratschläge. Ich weiß, dass ich (fast) nichts weiß und beim Thema Backup ganz am Anfang stehe. Ich mache seit Jahren Backups von meinem WINDOWS-Laptop, aber .... Ich versuche, Eure Anmerkungen gemeinsam zu kommentieren: Seebär schrieb: was ist denn bitte eine "Einzeldatei"?
Damit meine ich eine Datei im Backup, die genauso aussieht und zugreifbar ist, wie in der Quelle (= Arbeits-Laptop). Das heißt: Das Backup soll kein Archiv (oder tar etc.) sein, sondern (via DOLPHIN oder FileZilla) die Dateien einzeln und mit Eigenschaften direkt zeigen. Deshalb nach meinem bisherigen Eindruck (Software nicht angewendet) kein BorgBackup. Thomas_Do schrieb: Bei dem Konzept hast Du eine riesige "Verschwendung" von Plattenplatz. Ich würde höchstens 1-2 Platten für eine direkte Dateissynchronisation nehmen, z.B. täglich und wöchentlich. Ansonsten würde ich zur Langzeitarchivierung zusätzlich platzsparende inkrementelle Sicherungen, z.B. mit BorgBackup anlegen. Die kannst Du täglich (oder öfter) machen und die Snapshots automatisch "ausdünnen" lassen. Ggf. kannst Du mehrere Platten noch wöchentlich rotierend wechseln und an unterschiedliche Orten lagern.
OK, die "Verschwendung" ist wirklich ein Thema. Ich habe jetzt einiges gelesen aber immer noch ein gewisses Verständnisproblem zum Thema Differentielles / Inkrementelles Backup Wikipedia Sicherungsarten:
Differentiell = alle Daten, die seit der letzten Komplettsicherung geändert wurden oder neu hinzugekommen sind. Inkrementell = nur die Dateien, die seit der letzten inkrementellen Sicherung oder (bei der ersten inkrementellen Sicherung) seit der letzten Komplettsicherung geändert wurden oder neu hinzugekommen sind. Die Unterscheidung macht Sinn, wenn die Sicherungsziele z.B. der Komplettsicherung und einer nachfolgenden Inkrementellen Sicherung unterschiedlich sind. Ist das Ziel (wie bei mir derzeit) identisch, habe ich im Ergebnis immer ein vollkommenes Abbild der gewählten Verzeichnisse vom aktuellen Arbeits-PC. Außerdem sind inkrementelle / differentielle Sicherungen immer schneller als die Komplettsicherung, da unveränderte Dateien nicht übertragen werden müssen. Was ist mit am aktuellen Arbeits-PC gelöschten Dateien? Meine bisherige WINDOWS-Backup-Software löscht diese im Backup und das ist auch von mir gewollt.
Ich könnte mit zwei Platten (im Wechselrahmen) für direkte Dateissynchronisation leben (Platte_A/SynchronisationA/ und Platte_B/SynchronisationB/. Diese bekommen je ein Vollbackup und dann jeweils inkrementelle Sicherungen (einschließlich Löschen!) in jeweils das o.a. Ziel. Ergebnis: Je ein vollkommenes Abbild der gewählten Verzeichnisse vom aktuellen Arbeits-PC. Seebär schrieb: Was die örtlich getrennte Sicherung angeht: Wie soll man sich das vorstellen?
Die beiden Platten werden z.B. wöchentlich getauscht: Die eine am LAN zugreifbar, die andere Feuer-geschützt eingelagert. Außerdem z.b. täglich Inkrementelle Sicherungen auf individuelle Ziele: /Platte_X/InkrementSicherung_20161024, wobei Platte X die jeweils am LAN hängende Platte A oder B ist. Auch hierfür würde ich "Einzeldateien" (s.o.) bevorzugen? In der Vergangenheit habe ich (toi, toi, toi!) kein Backup wegen Plattenchrash etc. benötigt. Allerdings habe ich einige Male Dateien aus dem Backup genutzt, nach versehentlichem Löschvorgang oder fälschlich überschriebener Datei. Deshalb sind mir die "historischen" Versionen wichtig, da ich tatsächlich solchen Fehler manchmal erst nach Wochen bemerkt habe. Das Finden der historischen Version war kein Problem. Im Sinne der "Verschwendung" wäre traumhaft, wenn eine Software nach Abschluss der Inkrementellen Tagessicherung /Platte_X/InkrementSicherung_20161024 die älteren Versionen 20161023, 20161022 etc. durchgeht und dort Dateien löscht, die identisch (Zeitstempel, Dateigröße etc.) in der aktuellen 20161024 vorhanden sind. Dann könnte diese Routine auch alle Inkrementellen Sicherungen älter als z.B. 16 Wochen löschen. Bleiben außerdem folgende Fragen:
Konzept jetzt OK oder weiterer Verbesserungsbedarf? Software- oder Skript-Empfehung für dieses Konzept und / oder Lern-Skript für rsync? Ist Zusätzlich eine Image-Sicherung sinnvoll, um bei Ausfall des Arbeitsrechners Betriebssystem und Software nicht neu konfigurieren zu müssen? Wie lassen sich dann Nutzerdaten von Konfigurationen beim Restore sauber abgrenzen? Plattenprüfung: Sinnvoll? Wenn ja: Wie? Seebär:> "immer den Restore prüfen ..." Wie macht man das ohne den Arbeits-Rechner potentiell zu gefährden?
Vielen Dank für's Lesen und Eure wertvolle Unterstützung.
|
Seebär
Anmeldungsdatum: 2. Mai 2009
Beiträge: 829
|
michahe schrieb: Deshalb nach meinem bisherigen Eindruck (Software nicht angewendet) kein BorgBackup.
Falscher Eindruck. Du hast ein Repository. Darin gibt es Sicherungen (z.b. tägliche). Du kannst das ganze Repo (oder gezielt einzelne Sicherungen) mounten. Und dann ganz normal via Fileexplorer deiner Wahl auf deine "Einzeldateien" einer Sicherung zum Zeitpunkt X zugreifen. Das ist kein unhandlicher tar-Klumpen.
OK, die "Verschwendung" ist wirklich ein Thema. Ich habe jetzt einiges gelesen aber immer noch ein gewisses Verständnisproblem zum Thema Differentielles / Inkrementelles Backup
Ich mag das nicht im einzelnen durchgehen, steht ja doch auch vieles im Artikel. Aber die Grundlagen:
Daten werden komprimiert natürlich wird nicht neu gesichert, wenn sich nichts getan hat (das kann z.B. auch rsync, oder unter Windows sogar "robocopy" (das konnte auch schon xcopy...)) es werden aber identische Datenblöcke ("chunks") nicht n-mal, sondern nur 1x gesichert. Das zahlt sich bpws. bei grosßen DB-Dumps oder VM-Abbildern aus.
michahe schrieb:
Wenn du es komplett durchziehen willst geht es nicht ohne Gefahr: "wasch mich aber mach mich nicht nass". Die harte Nummer wäre:
a) erstelle ein Image b) mache zusätzlich eine Datensicherung (Feigling!) c) mach den Rechner platt d) jetzt Image einspielen. Wenn es geht: gut. Wenn nicht: neu aufsetzen, dann per Hand b) benutzen. Wenn das auch nicht klappt: dann war es das.
Was ich aber eher meinte: alle reden immer vom Backup, keiner vom Restore. Du musst mindestens mal prüfen / wissen, wie Du z.B. an die gesicherten Daten ran kommst. Bei Borg wusstest Du es nicht, sonst wäre Deine Annahme ja nicht falsch gewesen. Da ist das aber recht einfach machbar. Wenn Du nun aber ein Image erstellst: wie stellst Du Dir denn vor, wie du das wiedereinspielen des Images testen willst? Generell: ich würde nicht bis zum "perfekten Konzept" warten, fang einfach an und schau wie es sich bewährt. Ansonsten feilst Du solange an deinem Konzept bis 1 Tag vor Start der Umsetzung die Platte abraucht.
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3391
|
Hallo michahe. michahe schrieb: Die Unterscheidung macht Sinn, wenn die Sicherungsziele z.B. der Komplettsicherung und einer nachfolgenden Inkrementellen Sicherung unterschiedlich sind. Ist das Ziel (wie bei mir derzeit) identisch, habe ich im Ergebnis immer ein vollkommenes Abbild der gewählten Verzeichnisse vom aktuellen Arbeits-PC.
Nein! Die Sicherungen werden vom gewählten Backupprogramm so angelegt, dass auch Sicherungsstände in der Vergangenheit erreichbar sind. Du hast ja bei Inkrementeller Sicherung immer auch eine Vollsicherung auf der deine letzten Inkrementellen Sicherungen aufbauen und kannst dann die Daten zum Zeitpunkt der Vollsicherung, oder einer älteren Inkrementellen Sicherung wiederherstellen.
Bei den meisten Programmen müsstest du darauf warten, dass die Vollsicherung mit diesen Dateien gelöscht wird. Ist das sofortige Löschen (z.B. wegen den Anforderungen des Bundesdatenschutzgesetzes oder Telemediengesetzes) für dich dringend erforderlich, fällt einiges an Software weg. Dann kannst du aber auch diesen Fall nur sehr eingeschränkt absichern:
Allerdings habe ich einige Male Dateien aus dem Backup genutzt, nach versehentlichem Löschvorgang oder fälschlich überschriebener Datei. Deshalb sind mir die "historischen" Versionen wichtig, da ich tatsächlich solchen Fehler manchmal erst nach Wochen bemerkt habe.
Wird die Datei wirklich beim nächsten Backup endgültig gelöscht, kannst du nach einem Backup keine versehentlich gelöschten Dateien wiederherstellen. Viele Grüße Vej
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8525
|
Vej schrieb: Ist das sofortige Löschen (z.B. wegen den Anforderungen des Bundesdatenschutzgesetzes oder Telemediengesetzes) für dich dringend erforderlich, fällt einiges an Software weg. Dann kannst du aber auch diesen Fall nur sehr eingeschränkt absichern:
Dann sollte man parallel zwei (oder mehr) Sicherungsprofile anlegen (das geht z.T. auch mit der gleichen Software). Z.B. Sicherung der "normalen" Nutzerdaten mit 1 Snapshot pro Stunde. Speicherung aller Sicherungen des Tages, einer Sicherung pro Tag der letzen Woche ..., einer Sicherung pro Jahr für die letzen 10 Jahre. Für ein Verzeichnis mit z.B. sensiblen Kundendaten ebenfalls 1 Snapshot pro Stunde aber Löschung aller Daten nach beispielsweise 10 Tagen.
|
michahe
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 824
|
Hallo und ganz herzlichen Dank an Seebar , Vej und ThomasDo. Vej schrieb:> michahe schrieb: Die Unterscheidung macht Sinn, wenn die Sicherungsziele z.B. der Komplettsicherung und einer nachfolgenden Inkrementellen Sicherung unterschiedlich sind. Ist das Ziel (wie bei mir derzeit) identisch, habe ich im Ergebnis immer ein vollkommenes Abbild der gewählten Verzeichnisse vom aktuellen Arbeits-PC.
Nein! Die Sicherungen werden vom gewählten Backupprogramm so angelegt, dass auch Sicherungsstände in der Vergangenheit erreichbar sind. Du hast ja bei Inkrementeller Sicherung immer auch eine Vollsicherung auf der deine letzten Inkrementellen Sicherungen aufbauen und kannst dann die Daten zum Zeitpunkt der Vollsicherung, oder einer älteren Inkrementellen Sicherung wiederherstellen.
Also ein konkretes Beispiel: Im lokalen Netzwerk habe ich eine Platte, auf der Backups gespeichert werden sollen. Dort lege ich für den Arbeitslaptop ein Verzeichnis für die Vollsicherung und Ergänzungssicherungen (differentiell oder inkrementell) an:
//10.11.YYY.XXX/Harddisk/Arbeitslaptop/VollSichA/
//10.11.YYY.XXX/Harddisk/Arbeitslaptop/ErgänzSichA/
Die Verzeichnisse sind leer. Dazu auf dem Arbeitslaptop ein Test-Verzeichnis für Quelldateien: '/mnt/Daten/zzzBackupTest'. Hier erzeuge ich einige Testdateien 1.txt, 2.txt., 3.txt. Dann auf dem Arbeitslaptop mein allererster LINUX-Backup-Befehl:
rsync --numeric-ids --stats --progress --delete -avze ssh /mnt/Daten/zzzBackupTest/ root@10.11.YYY.XXX:/Harddisk/Arbeitslaptop/VollSichA
Erster Aufruf rsync: Alle vorhandenen Quelldateien werden ins Backup-Ziel kopiert. Im Quellverzeichnis wird 3.txt gelöscht und 4.txt erzeugt. Zweiter Aufruf rsync: 4.txt wird ins Backup-Ziel kopiert, 3.txt dort gelöscht. 1.txt und 2.txt werden verglichen, aber nicht kopiert.
Genau dieses Verhalten meinte ich oben mit michahe schrieb:
Was ist mit am aktuellen Arbeits-PC gelöschten Dateien? Meine bisherige WINDOWS-Backup-Software löscht diese im Backup und das ist auch von mir gewollt. Ist das Ziel (wie bei mir derzeit) identisch, habe ich im Ergebnis immer ein vollkommenes Abbild der gewählten Verzeichnisse vom aktuellen Arbeits-PC.
rsync macht genau das: Gelöschte Quelldateien werden (wie gewünscht) im Backup gelöscht, 'VollSichA' ist nach jedem rsync-Aufruf (wie gewünscht) ein identisches Abbild zur Quelle. Und die Sicherungsdateien schauen genauso aus, wie die Quelldateien (kein .tar etc., keine Reduktion auf Datenblock-Ebene ("chunks"). Jetzt würde ich gerne (wie) mit rsync ein inkrementelles bzw. differentielles Backup (Unterschiede gegen VollbackupA) in das Verzeichnis 'ErgänzungssicherungA' erzeugen; der Befehl dazu fehlt mir noch ... Noch zum Thema Löschen:
Vej schrieb: Bei den meisten Programmen müsstest du darauf warten, dass die Vollsicherung mit diesen Dateien gelöscht wird. Ist das sofortige Löschen (z.B. wegen den Anforderungen des Bundesdatenschutzgesetzes oder Telemediengesetzes) für dich dringend erforderlich, fällt einiges an Software weg.
Es gibt hier keine Anforderungen der Bundesdatenschutz- oder Telemediengesetze! Vej schrieb: michahe schrieb:
Allerdings habe ich einige Male Dateien aus dem Backup genutzt, nach versehentlichem Löschvorgang oder fälschlich überschriebener Datei. Deshalb sind mir die "historischen" Versionen wichtig, da ich tatsächlich solchen Fehler manchmal erst nach Wochen bemerkt habe.
Wird die Datei wirklich beim nächsten Backup endgültig gelöscht, kannst du nach einem Backup keine versehentlich gelöschten Dateien wiederherstellen.
Klar, es kommt aber doch auf das Backup-Ziel an:
Variante 1: VollbackupA am Sonntag, 23.10.2016 wie oben skizziert. Inkrementelles Backup gegen VollbackupA am 24.10.2016 nach '//10.11.YYY.XXX/Harddisk/Arbeitslaptop/ErgänzSichA/20161024'. Inkrementelles Backup gegen ErgänzSichA/20161024 am 25.10.2016 nach '//10.11.YYY.XXX/Harddisk/Arbeitslaptop/ErgänzSichA/20161025' und ebenso an allen folgenden Tagen bis Samstag, 29.10. Vollbackup A am Sonntag, 30.10.2016 wie oben skizziert und weiter mit Inkrementellen Backups. Ergebnis: Ein wöchentlich aktualisiertes Abbild des Arbeitslaptop und tägliche Abbilder der bearbeiteten Dateien.
Variante 2: VollbackupA am Sonntag, 23.10.2016 wie oben skizziert. Differentielles Backup gegen VollbackupA am 24.10.2016 nach '//10.11.YYY.XXX/Harddisk/Arbeitslaptop/ErgänzSichA/20161024'. Differentielles Backup gegen VollbackupA am 25.10.2016 nach '//10.11.YYY.XXX/Harddisk/Arbeitslaptop/ErgänzSichA/20161025' und ebenso an allen folgenden Tagen bis Samstag, 29.10. Ergebnis: Ein wöchentlich aktualisiertes Abbild des Arbeitslaptop und tägliche Abbilder der bearbeiteten Dateien.
Unterschiede: Variante 1 (Inkrementell): Nachteil: Im Falle eines Plattencrashs müssten das Vollbackup und alle späteren Inkrementellen Backups eingespielt werden. Vorteil: Eine nur am Sonntag nach dem Backup geänderte, große Datei wird nur einmal am Montag inkrementell gespeichert.
Variante 2 (Differentiell): Nachteil: Eine nur am Sonntag nach dem Backup geänderte, große Datei wird sechsmal differentiell gespeichert. Da kam der Gedanke mit dem Löschen: Die Routine DifferentiellesBackup erkennt am Montag die Änderung und sichert; am Dienstag erkennt sie sowohl die Änderung als auch, dass die Quelldatei immer noch identisch mit der Sicherungsdatei vom Montag ist. Also könnte sie die Backup-Datei im Sicherungsziel verschieben, so dass sie nur einmal vorhanden ist. Verschieben hätte gegenüber Kopieren / Löschen zudem den Vorteil, dass Netzwerktraffic (Zeit) gespart wird.
Mit welcher rsync-Anleitung oder welcher Backup-Software wollte ich weiter lernen?
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8525
|
Da Du ja von schnellen und komfortablen Lösungen mit "chunks" nichts hälst und anscheinend "richtige" Dateien willst, solltest Du Datensicherung noch einmal genau anschauen. In Frage kämen z.B. ein rsync-Skript, Back In Time, rdiff oder rsnapshot.
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3391
|
Hallo michahe. Danke für das Beispiel. Damit können wir uns besser austauschen. michahe schrieb: Jetzt würde ich gerne (wie) mit rsync ein inkrementelles bzw. differentielles Backup (Unterschiede gegen VollbackupA) in das Verzeichnis 'ErgänzungssicherungA' erzeugen; der Befehl dazu fehlt mir noch ...
Da du aber VollbackupA immer aktuell halten möchtest, müsste das dann ja irgendwie Rückwärts laufen! Es wird wohl schwer werden, dafür eine vorhandene Lösung zu finden, weil das nämlich leider ziemlich ineffizient ist. Ich baue dazu mal dein Beispiel aus: Die Dateien 1.txt und 2. txt werden erstellt. Die Sicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt ErgänzSichA: leer Die Datei 3.txt wird erstellt. Die Sicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt, 3.txt ErgänzSichA: entferne 3.txt Die Datei 3.txt wird gelöscht, 4. txt wird erstellt Die Sicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt, 4.txt ErgänzSichA: 3.txt, entferne 4.txt Die Datei 4.txt wird stark verändert. Die Sicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt, 4.txt ErgänzSichA: Veränderungen von 4.txt rückgängig machen
Das ist dein gewünschtes Verhalten oder? Das bedeutet dann aber, dass du die Änderungen immer zweimal kopieren musst. Einmal in VollSichA und einmal in ErgänzSichA.
Um das zu vermeiden geht man normalerweise den umgekehrten Weg. Die Vollsicherung veraltet schleichend, aber die Inkrementellen Sicherungen bauen darauf auf: Die Dateien 1.txt und 2. txt werden erstellt. Die Sicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt ErgänzSichA: leer Die Datei 3.txt wird erstellt. Die Sicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt ErgänzSichA: 3.txt Die Datei 3.txt wird gelöscht, 4. txt wird erstellt Die Sicherung wird angestoßen. Aktueller Status VollSichB: 1.txt, 2.txt, 4.txt ErgänzSichB: leer VollSichA: 1.txt, 2.txt ErgänzSichA: 3.txt Die Datei 4.txt wird stark verändert. Die Sicherung wird angestoßen. Aktueller Status VollSichB: 1.txt, 2.txt, 4.txt (ohne die Änderungen) ErgänzSichB: 4.txt (mit den Änderungen) VollSichA: 1.txt, 2.txt ErgänzSichA: 3.txt
Wird der Speicher knapp, kann man dann die älteste Vollsicherung und die dazugehörige inkrementelle Sicherung löschen. In der Regel legt man natürlich auch mehr als eine differenzielle Sicherung zwischen zwei Vollsicherungen an. Das ist dann auch das Verhalten, was die von Thomas_Do genannten Programme bieten (und das du selbst später unter Inkrementelle Sicherung skizziert hast). Noch zum Thema Löschen:
... Unterschiede: Variante 1 (Inkrementell): Nachteil: Im Falle eines Plattencrashs müssten das Vollbackup und alle späteren Inkrementellen Backups eingespielt werden. Vorteil: Eine nur am Sonntag nach dem Backup geänderte, große Datei wird nur einmal am Montag inkrementell gespeichert.
Variante 2 (Differentiell): Nachteil: Eine nur am Sonntag nach dem Backup geänderte, große Datei wird sechsmal differentiell gespeichert.
Bis hierhin, völlige Zustimmung.
Da kam der Gedanke mit dem Löschen: Die Routine DifferentiellesBackup erkennt am Montag die Änderung und sichert; am Dienstag erkennt sie sowohl die Änderung als auch, dass die Quelldatei immer noch identisch mit der Sicherungsdatei vom Montag ist. Also könnte sie die Backup-Datei im Sicherungsziel verschieben, so dass sie nur einmal vorhanden ist.
Ja, das könnte sie tun (wenn du eine Backupdatei pro Datei hast). Allerdings müsstest du dann wieder irgendwo hinterlegen, dass verschoben wurde. Willst du nämlich am Freitag alle Dateien auf den Stand vom Dienstag wiederherstellen, läge deine Datei ja schon beim Donnerstag. Du müsstest also in diesem Fall in einer Liste nachschauen, dass zweimal verschoben wurde. Um dieses Problem zu umgehen, sind schlaue Leute darauf gekommen vorhandene Dateien mittels Hardlinks zu verknüpfen anstatt sie zu verschieben. Das muss dann aber dein Sicherungsziel unterstützen. Viele Grüße Vej
|
michahe
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 824
|
Hallo Vej, danke für die ausführliche Antwort. Wahrscheinlich habe ich mich vorher nicht präzise genug ausgedrückt, Entschuldigung dafür.
Vej schrieb: Da du aber VollbackupA immer aktuell halten möchtest, müsste das dann ja irgendwie Rückwärts laufen! Es wird wohl schwer werden, dafür eine vorhandene Lösung zu finden, weil das nämlich leider ziemlich ineffizient ist.
Nein, das Vollbackup muss nur zum Zeitpunkt der Erstellung aktuell sein, also kein zweimaliges kopieren in VollSichA und in ErgänzSichA. Weiteres Missverständnis: Die Backups in ErgänzSichA bekommen je Anstoßen ein eigenes Verzeichnis mit Zeitstempel YYYMMDD. Das brauche ich ja, um die eine gewisse Historie zu haben und fälschlich gelöschte / überschriebene Files reanimieren zu können. Und noch eines: Die *SichA bzw. *SichB sind ähnliche Strukturen auf zwei Wechsel-Festplatten: Eine am Netzwerk, eine Feuer-gesichert gelagert; die beiden Platten tauschen in einem Wechsel (wöchentlich?) ihren Einsatzort. Damit zu Deinem zweiten Szenario, gelb markierter Text von mir ergänzt; Ergänzungssicherung inkrementell oder differentiell noch zu entscheiden (s.u.): Um das zu vermeiden geht man normalerweise den umgekehrten Weg. Die Vollsicherung veraltet schleichend, aber die Inkrementellen Sicherungen bauen darauf auf:
Die Dateien 1.txt und 2. txt werden erstellt. Die VollSicherung wird angestoßen. Aktueller Status VollSichA: 1.txt, 2.txt ErgänzSichA/20161023: leer Die Datei 3.txt wird erstellt. Die ErgänzungsSicherung wird angestoßen am 24.10.. Aktueller Status VollSichA: 1.txt, 2.txt ErgänzSichA/20161024: 3.txt Die Datei 3.txt wird gelöscht, 4. txt wird erstellt Die Sicherung wird angestoßen am 25.10.2016. Aktueller Status VollSichB: 1.txt, 2.txt, 4.txt ErgänzSichB: leer VollSichA: 1.txt, 2.txt ErgänzSichA: 3.txt Aktueller Status VollSichA: 1.txt, 2.txt ErgänzSichA/20161024: 3.txt ErgänzSichA/20161025: 4.txt
Das mit den Hardlinks verstehe ich auch so langsam ... Da kam der Gedanke mit dem Löschen: Die Routine DifferentiellesBackup erkennt am Montag die Änderung und sichert; am Dienstag erkennt sie sowohl die Änderung als auch, dass die Quelldatei immer noch identisch mit der Sicherungsdatei vom Montag ist. Also könnte sie die Backup-Datei im Sicherungsziel verschieben, so dass sie nur einmal vorhanden ist.
Ja, das könnte sie tun (wenn du eine Backupdatei pro Datei hast). Allerdings müsstest du dann wieder irgendwo hinterlegen, dass verschoben wurde. Willst du nämlich am Freitag alle Dateien auf den Stand vom Dienstag wiederherstellen, läge deine Datei ja schon beim Donnerstag. Du müsstest also in diesem Fall in einer Liste nachschauen, dass zweimal verschoben wurde. Um dieses Problem zu umgehen, sind schlaue Leute darauf gekommen vorhandene Dateien mittels Hardlinks zu verknüpfen anstatt sie zu verschieben.
habe ich jetzt begriffen und auch, dass rsync im Standard inkrementell arbeitet (Ergänzung im Wiki sinnvoll?); und auch, dass rsync sowohl auf dem Quell- als auch auf dem Backup-System laufen muss. Unsicher bin ich noch, ob ich die Ergänzungssicherungen differentiell gegen das Vollbackup oder inkrementell gegen die bis dahin jüngste Ergänzungssicherung laufen lasse. Was empfehlt Ihr?
|
michahe
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 824
|
Danke Thomas_Do, hast schon recht: Da Du ja von schnellen und komfortablen Lösungen mit "chunks" nichts hälst und anscheinend "richtige" Dateien willst, ...
Da eine realistische Überprüfung des Backups siehe oben 'Wenn du es komplett durchziehen willst geht es nicht ohne Gefahr: ...' kaum möglich ist und ich keine baugleiche Maschine Festplatte zum Ausprobieren habe, möcht ich erst einmal möglichst einfach sehen, was gesichert ist und was nicht. Wenn ich einmal ähnlich viel Erfahtung habe wie Du, versuche ich mich an komplexeren Lösungen. ... solltest Du Datensicherung noch einmal genau anschauen. In Frage kämen z.B. ein rsync-Skript, Back In Time, rdiff oder rsnapshot. Aktuell möchte ich mich rsync weitermachen und dann die Unterschiede zu rdiff und rsnapshot verstehen. Aber eine Frage noch: Warum hast Du luckyBackup nicht erwähnt? Das wäre meine Wahl für ein grafisches Backup-Programm gewesen.
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3391
|
Hallo michahe. michahe schrieb: Unsicher bin ich noch, ob ich die Ergänzungssicherungen differentiell gegen das Vollbackup oder inkrementell gegen die bis dahin jüngste Ergänzungssicherung laufen lasse. Was empfehlt Ihr?
Das ist Geschmackssache. Bei inkrementell dauert eine Komplettwiederherstellung länger, bei differentiell dafür die Sicherung. Ich persönlich nutze hier inkrementelle Sicherungen, weil ich im Schadensfall auch etwas länger warten kann (ist bisher noch gar nicht eingetreten). Dafür mag ich nicht so gerne den Rechner anlassen, nur weil die Sicherung noch nicht durch ist. Wenn dein Nutzungsverhalten genug Zeit zum Sichern (sprich Hardlinks anlegen) lässt, spricht nichts gegen differentiell. Ein wenig kommt es natürlich auch darauf an, womit du sichern willst. Wenn du irgendeine Software besonders benutzerfeundlich findest und die kann nur das eine oder das andere, dann würde ich das halt nehmen. Ich hoffe das hilft ein wenig beim Entscheiden. Viele Grüße Vej
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8525
|
michahe schrieb: Danke Thomas_Do, hast schon recht: Da Du ja von schnellen und komfortablen Lösungen mit "chunks" nichts hälst und anscheinend "richtige" Dateien willst, ...
Da eine realistische Überprüfung des Backups siehe oben 'Wenn du es komplett durchziehen willst geht es nicht ohne Gefahr: ...' kaum möglich ist und ich keine baugleiche Maschine Festplatte zum Ausprobieren habe, möcht ich erst einmal möglichst einfach sehen, was gesichert ist und was nicht. Wenn ich einmal ähnlich viel Erfahtung habe wie Du, versuche ich mich an komplexeren Lösungen.
Das Problem der Überprüfung, hat wenig mit der Sicherungsmethode zu tun. Du nimmst Dir eine Deiner Platten (s.o) und spielst die Sicherung zurück. Dann kannst Du z.B. mit diff die Dateien vergleichen (dauert nur recht lange). Bei einer rsync-Sicherung hast Du doch das gleiche Problem. In der Praxis beschränkt sich die Überprüfung oft nur auf Stichproben einzelner Dateien oder Verzeicnisse. Das kannst Du z.B. bei BorgBackup nach Mounten des Dateisystems genauso handhaben (ist eben wieder nur etwas langsanmer). Ich würde sowie zweigleisig gfahren: z.B. eine tägliche Spiegelung mit rsync (schneller Zugriff und Wiederherstellung) und zusätzlich häufige und inkrementelle Backups mit Borg über einen großen Zeitraum.
|
itoss
Anmeldungsdatum: 4. April 2014
Beiträge: 419
|
Meine Lösung : https://forum.ubuntuusers.de/topic/datensicherung-erste-fragen-und-ideen/#post-8615138 Inkrementelles Backup ist da nun nicht bei aber brauche ich für die paar GB Fotos und Dokumente auch nicht wirklich.
|