7
Tägliche Differenzsicherung mit Robocopy: Archivbit oder Zeitstempel nehmen? Und wie erfolgt ein Restore?
Hallo in die Runde,
ich plane die Automatisierung eines bisher händisch durchgeführten Backups eines Windows 7 Groupshares. Kunde möchte auf verschiedene Sicherungspunkte zurückgreifen können.
Backupplan: Vollsicherung Groupshare („Share“) am Sonntag in Ordner „VollSo“, dann differentielle Sicherung an jedem Wochentag-Abend in die Ordner „DiffMo“ bis „DiffFr“.
Für Differenzsicherungen liefert z.B. Robocopy ja folgende Ansätze (bitte korrigiert mich):
a) Verwendung des Archivbits
(Vorbereitend würde ich mit "DIR Share /S /A-A" auf nicht gesetzte Archivbits prüfen bzw. diese mit "ATTRIB +A Share\*.* /S /D setzen)
Robocopy Share VollSo /M /E (Vollsicherung Sonntag + Entfernen aller Archivbits)
Robocopy Share DiffMo /A /E (Differenzsicherung Montag-Abend)
Robocopy Share DiffDi /A /E (Differenzsicherung Dienstag-Abend)
u.s.w.
Erste Frage, welche Funktion hat ein Archivbit bei Ordnern, wenn Robocopy /m bzw. /a einen Ordner (im Gegensatz zu Dateien) auch dann kopiert, wenn dessen Archivattribut gar nicht gesetzt ist?!
Was ist von der Sicherung unter Verwendung des Archivbits zu halten? Es ist hier und dort zu lesen, dass diese Art der Sicherung nicht sämtliche Dateitypen erfasst - kann das jemand anhand konkreter Beispiele bestätigen?
b) Verwendung von Zeitstempeln
Robocopy Share VollSo /E (Vollsicherung Sonntag)
Robocopy Share DiffMo /E /MAXAGE:1 (Differenzsicherung Montag-Abend)
Robocopy Share DiffDi /E /MAXAGE:2 (Differenzsicherung Dienstag-Abend)
u.s.w.
Was sagt die Community zu den beiden Robocopy-Ansätzen? Gibt es eine Best Practice für tägliche Differenz-Sicherungen per Robocopy?
Ganz wichtig noch: Der Notfallplan. Wie würde ich z.B. im Falle einer Entwendung des Fileservers in der Nacht zu Samstag aus den Sicherungsordnern VollSo + DiffFr (differentiell) bzw. VollSo + DiffMo + DiffDi + DiffMi + DiffDo + DiffFr (falls inkrementell gesichert wurde) den ursprünglichen Datenbestand möglichst originalgetreu auf einem neuen Share rekonstruieren können?
Danke vorab für jede Antwort!
ich plane die Automatisierung eines bisher händisch durchgeführten Backups eines Windows 7 Groupshares. Kunde möchte auf verschiedene Sicherungspunkte zurückgreifen können.
Backupplan: Vollsicherung Groupshare („Share“) am Sonntag in Ordner „VollSo“, dann differentielle Sicherung an jedem Wochentag-Abend in die Ordner „DiffMo“ bis „DiffFr“.
Für Differenzsicherungen liefert z.B. Robocopy ja folgende Ansätze (bitte korrigiert mich):
a) Verwendung des Archivbits
(Vorbereitend würde ich mit "DIR Share /S /A-A" auf nicht gesetzte Archivbits prüfen bzw. diese mit "ATTRIB +A Share\*.* /S /D setzen)
Robocopy Share VollSo /M /E (Vollsicherung Sonntag + Entfernen aller Archivbits)
Robocopy Share DiffMo /A /E (Differenzsicherung Montag-Abend)
Robocopy Share DiffDi /A /E (Differenzsicherung Dienstag-Abend)
u.s.w.
Erste Frage, welche Funktion hat ein Archivbit bei Ordnern, wenn Robocopy /m bzw. /a einen Ordner (im Gegensatz zu Dateien) auch dann kopiert, wenn dessen Archivattribut gar nicht gesetzt ist?!
Was ist von der Sicherung unter Verwendung des Archivbits zu halten? Es ist hier und dort zu lesen, dass diese Art der Sicherung nicht sämtliche Dateitypen erfasst - kann das jemand anhand konkreter Beispiele bestätigen?
b) Verwendung von Zeitstempeln
Robocopy Share VollSo /E (Vollsicherung Sonntag)
Robocopy Share DiffMo /E /MAXAGE:1 (Differenzsicherung Montag-Abend)
Robocopy Share DiffDi /E /MAXAGE:2 (Differenzsicherung Dienstag-Abend)
u.s.w.
Was sagt die Community zu den beiden Robocopy-Ansätzen? Gibt es eine Best Practice für tägliche Differenz-Sicherungen per Robocopy?
Ganz wichtig noch: Der Notfallplan. Wie würde ich z.B. im Falle einer Entwendung des Fileservers in der Nacht zu Samstag aus den Sicherungsordnern VollSo + DiffFr (differentiell) bzw. VollSo + DiffMo + DiffDi + DiffMi + DiffDo + DiffFr (falls inkrementell gesichert wurde) den ursprünglichen Datenbestand möglichst originalgetreu auf einem neuen Share rekonstruieren können?
Danke vorab für jede Antwort!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 251565
Url: https://administrator.de/contentid/251565
Printed on: April 23, 2024 at 21:04 o'clock
7 Comments
Latest comment
Hi,
Ich mag mich für meine Antwort gerade selbst nicht, denn du würdest gerne etwas Umsetzen, fragst nur nach dem WIE - und jetzt kommt so ne Antwort... Kann ich normal selbst nicht leiden.
Aber Ich finde, wenn der Kunde bereit ist, für die Skripterstellung zu bezahlen, und dann muss das auch noch angepasst werden, sollte sich je was ändern... ...dann sollte der Kunde auch bereit sein, in ne vernünftige SW zu investieren.
Ich steh ja auf Skripts fürs Backup - aber nicht, um ne gesamte Backuplösung zu ersetzen.
Das klingt sehr stark nach Backups richtung Externe Platten, und hat imho mit einer vernünftigen Beratung, warum der Kunde ein vernünftiges Backup braucht nicht mehr viel zu tun. Lieber etwas mehr überzeugungsarbeit leisten, und zur not vorrechnen, warum sich mittelfristig eine Professionelle SW Lösung lohnt.
Leider kann ich nicht mehr dazu raten, tut mir echt leid, ich möchte niemand vor den Kopf stoßen, aber ich habe schon mehr als einmal eine solche Lösung übernommen, und durfte den Scherbenhaufen beseitigen. Sei also nicht böse, ich hab nur schon viel schlechte Erfahrungen mit selbstgestrickten Skripten anderer gemacht.
Jetzt hab ich doch noch was:
Zur lösung an sich - du kannst auch via 7zip sichern - skripte dir was zurecht, was alle shares in nen zip archiv ballert - differenziell sicherste einfach alle files mit entsprechendem flag in das gleiche zipfile rein, nur geänderte files ersetzend.
Revisionssicher? dann kopierste vorher das alte zipfile weg. - Eine Lösung die NUR diff woanders hin schreibt ist mir nicht bekannt - robocopy kann imho keine liste mit zu kopierenden dateien erstellen, die du hinterher abarbeitest... vielleicht:
Alternative: cygwin mit rdiff und gzip
Greetz,
Kay
Ich mag mich für meine Antwort gerade selbst nicht, denn du würdest gerne etwas Umsetzen, fragst nur nach dem WIE - und jetzt kommt so ne Antwort... Kann ich normal selbst nicht leiden.
Aber Ich finde, wenn der Kunde bereit ist, für die Skripterstellung zu bezahlen, und dann muss das auch noch angepasst werden, sollte sich je was ändern... ...dann sollte der Kunde auch bereit sein, in ne vernünftige SW zu investieren.
Ich steh ja auf Skripts fürs Backup - aber nicht, um ne gesamte Backuplösung zu ersetzen.
Das klingt sehr stark nach Backups richtung Externe Platten, und hat imho mit einer vernünftigen Beratung, warum der Kunde ein vernünftiges Backup braucht nicht mehr viel zu tun. Lieber etwas mehr überzeugungsarbeit leisten, und zur not vorrechnen, warum sich mittelfristig eine Professionelle SW Lösung lohnt.
Leider kann ich nicht mehr dazu raten, tut mir echt leid, ich möchte niemand vor den Kopf stoßen, aber ich habe schon mehr als einmal eine solche Lösung übernommen, und durfte den Scherbenhaufen beseitigen. Sei also nicht böse, ich hab nur schon viel schlechte Erfahrungen mit selbstgestrickten Skripten anderer gemacht.
Jetzt hab ich doch noch was:
Zur lösung an sich - du kannst auch via 7zip sichern - skripte dir was zurecht, was alle shares in nen zip archiv ballert - differenziell sicherste einfach alle files mit entsprechendem flag in das gleiche zipfile rein, nur geänderte files ersetzend.
Revisionssicher? dann kopierste vorher das alte zipfile weg. - Eine Lösung die NUR diff woanders hin schreibt ist mir nicht bekannt - robocopy kann imho keine liste mit zu kopierenden dateien erstellen, die du hinterher abarbeitest... vielleicht:
Alternative: cygwin mit rdiff und gzip
Greetz,
Kay
Hallo robocop,
wenn du es Scripten willst mach es z.B. mit rsnyc das läuft zuverlässig. Hier gibt es ein VBS-Wrapper der rsnyc automatisiert:
http://www.heise.de/download/rsyncbackup.vbs.html
Rsync arbeitet dabei mit Hardlinks, so dass Snapshots nur minimalen Speicherplatz auf dem Laufwerk belegen. Jeder Snapshot enthält in sich gesehen immer den zum Backupzeitpunkt kompletten Inhalt, aber nur die seit dem letzten Backup geänderten Files belegen tatsächlich Speicherplatz, alles andere sind Hardlinks. So reicht es zum Restore einfach den Snapshot-Ordner zu kopieren und zurück zu spielen.
Das nur so als Vorschlag.
Eine richtige Backuplösung ist natürlich komfortabler da stimme ich absolut zu, aber eine zugeschnittene Lösung kann seinen Zweck auch erfüllen, solange man alle Desaster-Szenarios vorher durchspielt und den Restore beherrscht.
Dokumentation ist hier das A und O damit
für den Fall der Fälle kein Stress aufkommt.
Grüße Uwe
wenn du es Scripten willst mach es z.B. mit rsnyc das läuft zuverlässig. Hier gibt es ein VBS-Wrapper der rsnyc automatisiert:
http://www.heise.de/download/rsyncbackup.vbs.html
Rsync arbeitet dabei mit Hardlinks, so dass Snapshots nur minimalen Speicherplatz auf dem Laufwerk belegen. Jeder Snapshot enthält in sich gesehen immer den zum Backupzeitpunkt kompletten Inhalt, aber nur die seit dem letzten Backup geänderten Files belegen tatsächlich Speicherplatz, alles andere sind Hardlinks. So reicht es zum Restore einfach den Snapshot-Ordner zu kopieren und zurück zu spielen.
Das nur so als Vorschlag.
Eine richtige Backuplösung ist natürlich komfortabler da stimme ich absolut zu, aber eine zugeschnittene Lösung kann seinen Zweck auch erfüllen, solange man alle Desaster-Szenarios vorher durchspielt und den Restore beherrscht.
Dokumentation ist hier das A und O damit
für den Fall der Fälle kein Stress aufkommt.
Grüße Uwe
Hallo Kay und Uwe,
danke für eure Beiträge. Sicherlich gibt es haufenweise Tools, mit denen man Backups durchführen kann. Zunächst besitze ich jedoch noch den sportlichen Ehrgeiz, die Anforderung des Kunden "aus Bordmitteln" zu lösen - sofern die Verrenkungen hier nicht allzu groß werden.
Vielleicht meldet sich noch ein Robocopy-Freak (ich bin keiner, mir ist nur grad kein anderer Benutzername eingefallen
, der etwas zur Problemlösung beitragen kann.
Zwischenzeitlich teste ich noch einen weiteren Ansatz, nämlich die Funktion "Vorgängerversionen" in Windows 7 (= Betriebssystem des "Dateiserver"). Wenn ich täglich automatisiert einen Wiederherstellungspunkt auf der Datenpartition des Dateiservers setze (in Aufgabenplanung täglicher Powershell-Befehl "checkpoint-computer"), dann HAT der Kunde seine tägliche Version der Daten. Und mit Robocopy mache ich eine simple tägliche Vollsicherung in nur einen Sicherungsordner - was ein Restore extrem erleichtern würde.
Frage ist nur, inwieweit die täglichen Snapshots das Share aufblähen. Wie Uwe schreibt, ist der Platzverbrauch zumindest bei Rsync ja minimal ...
Grüße in die Runde
danke für eure Beiträge. Sicherlich gibt es haufenweise Tools, mit denen man Backups durchführen kann. Zunächst besitze ich jedoch noch den sportlichen Ehrgeiz, die Anforderung des Kunden "aus Bordmitteln" zu lösen - sofern die Verrenkungen hier nicht allzu groß werden.
Vielleicht meldet sich noch ein Robocopy-Freak (ich bin keiner, mir ist nur grad kein anderer Benutzername eingefallen
, der etwas zur Problemlösung beitragen kann.Zwischenzeitlich teste ich noch einen weiteren Ansatz, nämlich die Funktion "Vorgängerversionen" in Windows 7 (= Betriebssystem des "Dateiserver"). Wenn ich täglich automatisiert einen Wiederherstellungspunkt auf der Datenpartition des Dateiservers setze (in Aufgabenplanung täglicher Powershell-Befehl "checkpoint-computer"), dann HAT der Kunde seine tägliche Version der Daten. Und mit Robocopy mache ich eine simple tägliche Vollsicherung in nur einen Sicherungsordner - was ein Restore extrem erleichtern würde.
Frage ist nur, inwieweit die täglichen Snapshots das Share aufblähen. Wie Uwe schreibt, ist der Platzverbrauch zumindest bei Rsync ja minimal ...
Grüße in die Runde
Frage ist nur, inwieweit die täglichen Snapshots das Share aufblähen.
Das macht Windows über Schattenkopien, die sind ähnlich aufgebaut wie rsync, d.h. es belegen auch nur tatsächlich geänderte Dateien zusätzlichen Speicherplatz.Grüße Uwe
Erste Frage, welche Funktion hat ein Archivbit bei Ordnern, wenn Robocopy /m bzw. /a einen Ordner (im Gegensatz zu Dateien) auch dann kopiert, wenn dessen Archivattribut gar nicht gesetzt ist?!
Das Archiv-Bit ist ein Dateiattribut und wird nur bei Dateien gesetzt, nicht auf Ordnern. Das was Windows in den Ordnereigenschaften anzeigt besagt nur ob Dateien innerhalb dieses Ordners das Archivattribut besitzen oder nicht.Was ist von der Sicherung unter Verwendung des Archivbits zu halten?
Es gibt hier z.B. eine gefährliche Falle. Wenn man einen Ordner inkl. dessen kompletten Inhalt verschiebt, wird das Archivattribut nicht gesetzt !!Nachteil ist ebenfalls das das Backup-Programm in allen Ordnern Schreibrechte besitzen muss, damit das Archiv-Attribut zurückgesetzt werden kann.
Es ist hier und dort zu lesen, dass diese Art der Sicherung nicht sämtliche Dateitypen erfasst - kann das jemand anhand konkreter Beispiele bestätigen?
Es ist ein Attribut das das NTFS-Dateisystem automatisch von selbst setzt sobald die Datei durch einen Schreibzugriff verändert wird.Backups anhand des Archiv-Bits macht man heute eigentlich nicht mehr und ist nicht zu empfehlen.
Ganz wichtig noch: Der Notfallplan. Wie würde ich z.B. im Falle einer Entwendung des Fileservers in der Nacht zu Samstag aus den Sicherungsordnern VollSo + DiffFr (differentiell) bzw. VollSo + DiffMo + DiffDi + DiffMi + DiffDo + DiffFr (falls inkrementell gesichert wurde) den ursprünglichen Datenbestand möglichst originalgetreu auf einem neuen Share rekonstruieren können?
Vollbackup auf das Share zurückspielen und danach das gewünschte differenzielle bzw. alle inkrementellen Backups in das Share kopieren.Beispiel:
Vollbackup zurückspielen
robocopy "D:\Vollbackup" "\\Server\Share" * /MIR /COPYALL
robocopy "D:\Diffbackup\Fri" "\\Server\Share" * /E /COPYALL
Dateilöschungen sind hierbei nicht berücksichtigt. Aber das ist bei einem Backup normalerweise zu verschmerzen.
Bei Rsync hast du das Problem nicht, da hier immer in jedem Backup der aktuelle Stand aller Dateien wiedergeben wird inkl. gelöschter Dateien. Das ließe sich zwar auch mit Robocopy Scripten ist jedoch gerne Fehleranfällig.
Alles andere haben wir bereits in diesem Thread abgefackelt:
Robocopy - diffrentielles Backup
Viele Grüße Uwe
1
Vielen Dank, Uwe!
Die Rücksicherung via Robocopy aus der Voll- und den Differenz-Sicherungen ist offensichtlich einfacher als ich dachte.
Und die Archivbit-Sicherung werde ich nach deinen Hinweisen vorsichtshalber nicht weiter verfolgen.
Sind ähnliche Probleme auch beim /MAXAGE:n-Backup bekannt? Welche Tücken lauern dort?
Morgen werde ich beim Kunden erst einmal testweise die tägliche Windows-Snapshot-Sicherung in Kombination mit Robocopy täglich/voll in Betrieb nehmen. Damit dürften eigentlich sämtliche Kundenanforderungen erfüllt sein - ich werde übernächste Woche berichten ...
Schönen Sonntag noch!
Die Rücksicherung via Robocopy aus der Voll- und den Differenz-Sicherungen ist offensichtlich einfacher als ich dachte.
Und die Archivbit-Sicherung werde ich nach deinen Hinweisen vorsichtshalber nicht weiter verfolgen.
Sind ähnliche Probleme auch beim /MAXAGE:n-Backup bekannt? Welche Tücken lauern dort?
Morgen werde ich beim Kunden erst einmal testweise die tägliche Windows-Snapshot-Sicherung in Kombination mit Robocopy täglich/voll in Betrieb nehmen. Damit dürften eigentlich sämtliche Kundenanforderungen erfüllt sein - ich werde übernächste Woche berichten ...
Schönen Sonntag noch!
Hallo nochmal,
mit der täglichen Robocopy-Vollsicherung aufs NAS kombiniert mit einer täglichen "Vorgängerversionen"-Snapshot-Sicherung (+ einer wöchentlichen Vollsicherung auf USB-Festplatte zwecks Auslagerung) konnte ich die Kundenanforderungen relativ unkompliziert und nur aus Bordmitteln umsetzen, also alles prima!
Danke an alle + Grüße in die Runde
mit der täglichen Robocopy-Vollsicherung aufs NAS kombiniert mit einer täglichen "Vorgängerversionen"-Snapshot-Sicherung (+ einer wöchentlichen Vollsicherung auf USB-Festplatte zwecks Auslagerung) konnte ich die Kundenanforderungen relativ unkompliziert und nur aus Bordmitteln umsetzen, also alles prima!
Danke an alle + Grüße in die Runde
