Robocopy - inkrementelle Sicherung
Hallo zusammen,
stehe etwas auf dem Schlauch.
Ich möchte mit Robocopy eine inkrementelle Sicherung durchführen.
Es geht darum, dass für einen speziellen Projekte-Ordner, in dem sehr langfristige, wichtige Projekte untergebracht sind, eine zusätzliche Sicherung gewünscht ist.
Bisher lief das so, dass der Ordner einfach jeden Tag gesichert wurde.
set datum=%date%
robocopy "D:\Daten\Projekte\Spezial" "\\srvbackup\Datensicherung\Backup.%datum%" /E
Am Ende jeden Monats wurden die Daten auf zwei Festplatten umkopiert und eingelagert und vom Backupserver gelöscht, damit das nicht ausufert. Für jeden Monat gibt es dann zwei Festplatten (falls eine kaputt gehen sollte) - ist so gewünscht. Sollte mal die Frage aufkommen, soll noch nach 8 Jahren geschaut werden können, wie das Projekt am 26. Oktober 2023 ausgesehen hat.
Hintergrund ist, dass bei diesen Daten nicht nur die End-Ergebnisse, sondern ggf. auch die Zwischenschritte benötigt werden. Die normale Sicherung ist für die letzten 3 Monate täglich, dann wöchentlich, monatlich, quartal. Eben keine 100%ige Abdeckung mehr.
Das war bisher auch kein Thema, weil dieser Spezial-Ordner grade mal 20 GB groß war. Bei 30 Tagen - 600 GB, Kinkerlitzchen. Jetzt sind zwei Projekte mit großen Bilddaten reingekommen - über 100 GB - Tendenz mehrwerdend, da wirds dann langsam Zeit sich was zu überlegen.
Grade die Bilder ändern sich fast nie, werden aber momentan noch immer in der Sicherung mitgeschleppt und auch so gibt es nicht jeden Tag Änderungen.
Ich hätte gerne, dass Robocopy nur die Daten kopiert, die verändert wurden.
Rein theoretisch müsste das mit "/m" funktionieren.
Die Syntax wäre dann:
set datum=%date%
robocopy "D:\Daten\Projekte\Aktuell" "\\srvbackup\Datensicherung\Backup.%datum%" /E /M
Stimmt meine Vermutung? Gibt es eine andere/bessere Lösung?
Ich möchte hier keinen Fehler machen.
stehe etwas auf dem Schlauch.
Ich möchte mit Robocopy eine inkrementelle Sicherung durchführen.
Es geht darum, dass für einen speziellen Projekte-Ordner, in dem sehr langfristige, wichtige Projekte untergebracht sind, eine zusätzliche Sicherung gewünscht ist.
Bisher lief das so, dass der Ordner einfach jeden Tag gesichert wurde.
set datum=%date%
robocopy "D:\Daten\Projekte\Spezial" "\\srvbackup\Datensicherung\Backup.%datum%" /E
Am Ende jeden Monats wurden die Daten auf zwei Festplatten umkopiert und eingelagert und vom Backupserver gelöscht, damit das nicht ausufert. Für jeden Monat gibt es dann zwei Festplatten (falls eine kaputt gehen sollte) - ist so gewünscht. Sollte mal die Frage aufkommen, soll noch nach 8 Jahren geschaut werden können, wie das Projekt am 26. Oktober 2023 ausgesehen hat.
Hintergrund ist, dass bei diesen Daten nicht nur die End-Ergebnisse, sondern ggf. auch die Zwischenschritte benötigt werden. Die normale Sicherung ist für die letzten 3 Monate täglich, dann wöchentlich, monatlich, quartal. Eben keine 100%ige Abdeckung mehr.
Das war bisher auch kein Thema, weil dieser Spezial-Ordner grade mal 20 GB groß war. Bei 30 Tagen - 600 GB, Kinkerlitzchen. Jetzt sind zwei Projekte mit großen Bilddaten reingekommen - über 100 GB - Tendenz mehrwerdend, da wirds dann langsam Zeit sich was zu überlegen.
Grade die Bilder ändern sich fast nie, werden aber momentan noch immer in der Sicherung mitgeschleppt und auch so gibt es nicht jeden Tag Änderungen.
Ich hätte gerne, dass Robocopy nur die Daten kopiert, die verändert wurden.
Rein theoretisch müsste das mit "/m" funktionieren.
Die Syntax wäre dann:
set datum=%date%
robocopy "D:\Daten\Projekte\Aktuell" "\\srvbackup\Datensicherung\Backup.%datum%" /E /M
Stimmt meine Vermutung? Gibt es eine andere/bessere Lösung?
Ich möchte hier keinen Fehler machen.
Please also mark the comments that contributed to the solution of the article
Content-ID: 22239244837
Url: https://administrator.de/contentid/22239244837
Printed on: September 12, 2024 at 11:09 o'clock
14 Comments
Latest comment
Moin
Nein. Das Archivattribut wird nur gesetzt, wenn Daten tatsächlich geändert wurden.
Wenn man zum Beispiel einen Ordner nur umbenennt, wird das Archivattribut nicht neu gesetzt - die Dateien wären in der Sicherung also nur unter dem alten Pfad zu finden.
Robocopy arbeit aber stets inkrementell. Dateien, die in Quelle und Ziel identisch sind, kopiert Robocopy nicht erneut.
Gruß Thomas
Nein. Das Archivattribut wird nur gesetzt, wenn Daten tatsächlich geändert wurden.
Wenn man zum Beispiel einen Ordner nur umbenennt, wird das Archivattribut nicht neu gesetzt - die Dateien wären in der Sicherung also nur unter dem alten Pfad zu finden.
Robocopy arbeit aber stets inkrementell. Dateien, die in Quelle und Ziel identisch sind, kopiert Robocopy nicht erneut.
Gruß Thomas
Doch, das ist so.
So wie du dir das vorstellst, geht das mit Robocopy leider nicht. Dafür benötigst du eine Software, die die inkrementellen Backups anhand des USN-Journals erstellen, damit wirklich alle Änderungen am Dateisystem in die Sicherung übernommen werden.
Gruß Thomas
Der kopiert ALLES. Der Backup-Ordner ist eine vollständige Kopie des Original-Ordners.
Natürlich ist der Backupordner eine vollständige Kopie des Originals, etwas anderes habe ich ja auch nicht behauptet. Aber es werden eben nur Dateien kopiert, die im Ziel älter oder nicht vorhanden sind. Wenn du morgen in einen anderen Zielordner sicherst, sind dort keine Dateien vorhanden - dann wird natürlich wieder alles gesichert.So wie du dir das vorstellst, geht das mit Robocopy leider nicht. Dafür benötigst du eine Software, die die inkrementellen Backups anhand des USN-Journals erstellen, damit wirklich alle Änderungen am Dateisystem in die Sicherung übernommen werden.
Gruß Thomas
Moin,
suchst du das /MIR (Mirror)?
Hier werden nur Änderungen kopiert. Allerdings löscht dies auch Daten am Ziel wenn diese an der Quelle gelöscht werden.
Ihr versucht hier über das Backup eine Archiv-Funktion abzubilden. Wenn Dateien nicht gelöscht werden dürfen, hat das nach meiner Meinung nichts mit Backup zu tun.
Unabhängig davon könnte euch evtl eine Dedupe Appliance helfen. Auch wenn die 100GB Datei dann zum 1000. mal gesichert wird, ändert das nichts an der Größe des Backup-Repositories.
Gruß und viel Erfolg
suchst du das /MIR (Mirror)?
Hier werden nur Änderungen kopiert. Allerdings löscht dies auch Daten am Ziel wenn diese an der Quelle gelöscht werden.
Ihr versucht hier über das Backup eine Archiv-Funktion abzubilden. Wenn Dateien nicht gelöscht werden dürfen, hat das nach meiner Meinung nichts mit Backup zu tun.
Unabhängig davon könnte euch evtl eine Dedupe Appliance helfen. Auch wenn die 100GB Datei dann zum 1000. mal gesichert wird, ändert das nichts an der Größe des Backup-Repositories.
Gruß und viel Erfolg
Hi,
wie @TK1987 sagt, Robocopy gibt das so von Hause aus nicht her was du vor hast.
Es kopiert nur Incrementell, aber wenn jedes mal ein neuer Zielordner angegeben wird ist der halt leer.
Somit ist bei Robocopy: Works as Designed
Gruß
wie @TK1987 sagt, Robocopy gibt das so von Hause aus nicht her was du vor hast.
Es kopiert nur Incrementell, aber wenn jedes mal ein neuer Zielordner angegeben wird ist der halt leer.
Somit ist bei Robocopy: Works as Designed
Gruß
Zitat von @kpunkt:
Man per Script mit attrib -a und mehreren Zielen rumspielen, aber das wird immer eine Bastelgeschichte bleiben.
Ich denke, da ist man u.U. mit einer Projektmanagement Software besser beraten.
Prinzipiell kann man schon mit Robocopy arbeiten. Es braucht dann halt nur ein etwas anderes Backupkonzept, als das, was sich der TO da derzeit vorgestellt hat.Man per Script mit attrib -a und mehreren Zielen rumspielen, aber das wird immer eine Bastelgeschichte bleiben.
Ich denke, da ist man u.U. mit einer Projektmanagement Software besser beraten.
Zum Beispiel alle paar Wochen einmal ein komplettes Abbild und ansonsten Festplatten für die einzelnen Wochentage, in denen Änderungen mit robocopy fortgeschrieben werden.
Zitat von @ElmerAcmeee:
Wenn Dateien nicht gelöscht werden dürfen, hat das nach meiner Meinung nichts mit Backup zu tun.
Das ist völlig falsch und höchstfahrlässig. Daten können auch versehentlich gelöscht/überschrieben/verschoben, durch ransomware verschlüsselt, oder einfach durch Schreibfehler unbrauchbar werden. Wenn das nicht sofort auffällt und man keine einzelnen Versionsstände mehr hat, sondern nur simple Spiegelungen, sind die Daten unwiederbringlich verloren.Wenn Dateien nicht gelöscht werden dürfen, hat das nach meiner Meinung nichts mit Backup zu tun.
Gruß Thomas
Hallo,
Oben ist die Rede von tagesgenauen Daten, 8 Jahre Rückwirkend.
Warum sollte man die gleichen Daten auf 2 Festplatten, 12x im Jahr, 8 Jahre lang exportieren?
In einem Archiv, DMS, oder wie auch immer man das Kind nennt, liegen diese Daten nur einmal drin. Nur wenn es nen neuen Stand gibt, ändert sich da was.
Selbstverständlich gehören diese Systeme in ein Backup! Da stimme ich dir voll zu! Ohne Backup kein Mitleid!
Und Redundant kann man auch hier beides machen.
Und wenn es doch bei einem Backupkonzept bleibt, würde ich hier eine Dedupe Appliance sehen.
Hard- oder Software mit externer Replikation.
Gruß und viel Erfolg
Quote from @TK1987:
Ich glaube wir meinen das gleiche. Bei einem Backup muss jemandem innerhalb der Retention Time auffallen, dass etwas gelöscht wurde. Wenn aber gewisse Datenbestände rein von der Anforderung her schon einsehbar sein müssen, dann geht das in Richtung Revisionierung und Archivierung.Zitat von @ElmerAcmeee:
Wenn Dateien nicht gelöscht werden dürfen, hat das nach meiner Meinung nichts mit Backup zu tun.
Das ist völlig falsch und höchstfahrlässig. Daten können auch versehentlich gelöscht/überschrieben/verschoben, durch ransomware verschlüsselt, oder einfach durch Schreibfehler unbrauchbar werden. Wenn das nicht sofort auffällt und man keine einzelnen Versionsstände mehr hat, sondern nur simple Spiegelungen, sind die Daten unwiederbringlich verloren.Wenn Dateien nicht gelöscht werden dürfen, hat das nach meiner Meinung nichts mit Backup zu tun.
Oben ist die Rede von tagesgenauen Daten, 8 Jahre Rückwirkend.
Warum sollte man die gleichen Daten auf 2 Festplatten, 12x im Jahr, 8 Jahre lang exportieren?
In einem Archiv, DMS, oder wie auch immer man das Kind nennt, liegen diese Daten nur einmal drin. Nur wenn es nen neuen Stand gibt, ändert sich da was.
Selbstverständlich gehören diese Systeme in ein Backup! Da stimme ich dir voll zu! Ohne Backup kein Mitleid!
Und Redundant kann man auch hier beides machen.
Und wenn es doch bei einem Backupkonzept bleibt, würde ich hier eine Dedupe Appliance sehen.
Hard- oder Software mit externer Replikation.
Gruß und viel Erfolg
Moin,
wenn das mit dem /m funktioniert, ist dir ja schon mal geholfen.
Ich würde dir trotzdem mal eine Dedupe Appliance, wie die DataDomain oder Quantum DXI nahe legen wollen.
Das könntest du mal parallel mit laufen lassen.
Einfach alle Backups als Kopie oder separatem Job auf diese Appliance legen. Da dein Backupsoftware ja weiß was sie gesichert hat, musst du auch nicht mehr nach der passenden Platte suchen.
Die virtuelle Version von Quantum ist bis 5TB kostenlos. Das dürfte bei dir schon für einige Jahre reichen und einiges an Kosten und Aufwand sparen.
Gruß und viel Erfolg
wenn das mit dem /m funktioniert, ist dir ja schon mal geholfen.
Ich würde dir trotzdem mal eine Dedupe Appliance, wie die DataDomain oder Quantum DXI nahe legen wollen.
Das könntest du mal parallel mit laufen lassen.
Einfach alle Backups als Kopie oder separatem Job auf diese Appliance legen. Da dein Backupsoftware ja weiß was sie gesichert hat, musst du auch nicht mehr nach der passenden Platte suchen.
Die virtuelle Version von Quantum ist bis 5TB kostenlos. Das dürfte bei dir schon für einige Jahre reichen und einiges an Kosten und Aufwand sparen.
Gruß und viel Erfolg
Moin,
Wenn jemand irgendwo ein Verzeichnis umbenennt, werden fortan nur noch die geänderten Dateien am neuen Ort gesichert. Alle unveränderten Dateien sind nur unter dem alten Verzeichnis in der Sicherung vom Monatsersten. Falls nun die Festplatte hinüber ist, hast du in der Sicherung keinen vollständigen Ordner mehr, in dem du alle aktuellen Dateien findest - sondern musst die Daten aus 2 (oder mehr) Ordnern zusammenkopieren - dafür musst du jedoch erst einmal wissen, welcher Ordner worin umbenannt wurde.
Falls dies dann auch noch mehrfach auf unterschiedlich tiefen Ebenen im Verzeichnisbaum passiert ist, wird eine Rekonstruktion äußerst schwierig.
Gruß Thomas
Zitat von @mpanzi:
Ich lasse am Monatsersten eine Vollsicherung laufen und den Rest des Monats mit dem "/m".
dir muss halt nur klar sein, dass du dieser Sicherung dann nicht mehr 100%ig vertrauen kannst.Ich lasse am Monatsersten eine Vollsicherung laufen und den Rest des Monats mit dem "/m".
Wenn jemand irgendwo ein Verzeichnis umbenennt, werden fortan nur noch die geänderten Dateien am neuen Ort gesichert. Alle unveränderten Dateien sind nur unter dem alten Verzeichnis in der Sicherung vom Monatsersten. Falls nun die Festplatte hinüber ist, hast du in der Sicherung keinen vollständigen Ordner mehr, in dem du alle aktuellen Dateien findest - sondern musst die Daten aus 2 (oder mehr) Ordnern zusammenkopieren - dafür musst du jedoch erst einmal wissen, welcher Ordner worin umbenannt wurde.
Falls dies dann auch noch mehrfach auf unterschiedlich tiefen Ebenen im Verzeichnisbaum passiert ist, wird eine Rekonstruktion äußerst schwierig.
Gruß Thomas