14
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.
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-ID: 22239244837
Url: https://administrator.de/contentid/22239244837
Printed on: September 12, 2024 at 11:09 o'clock
14 Comments
Latest comment
Sollte so funktionieren. /M setzt das Archivbit in der Quelldatei zurück.
Teste einfach mal und lass dir ein Log anlegen. Dann siehst du genau was kopier wird und was nicht.
Teste einfach mal und lass dir ein Log anlegen. Dann siehst du genau was kopier wird und was nicht.
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
Zitat von @TK1987:
Robocopy arbeit aber stets inkrementell. Dateien, die in Quelle und Ziel identisch sind, kopiert Robocopy nicht erneut.
Gruß Thomas
Robocopy arbeit aber stets inkrementell. Dateien, die in Quelle und Ziel identisch sind, kopiert Robocopy nicht erneut.
Gruß Thomas
Das kann ich definitiv verneinen. Ich hab ja den Befehl aufgeschrieben, mit dem momentan die Dateien kopiert werden. Der kopiert ALLES. Der Backup-Ordner ist eine vollständige Kopie des Original-Ordners. Das ist ja mein Problem. Daher habe ich jetzt auf einem über 3 TB an Backup.
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ß
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.
Ich denke, da ist man u.U. mit einer Projektmanagement Software besser beraten.
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
Also hier mal ausführlich:
Die normale Datensicherung läuft über Veritas Backup Exec. Am Wochenende ne Vollsicherung und täglich eine inkrementelle. Und zwar einmal auf einen Backup-Server, auf dem sie ca. 90 Tage verbleiben, bis sie wieder überschrieben werden. Zum anderen auf einen externen Datenträger, der jede Woche ausgetauscht wird.
Auf den externen Datenträgern haben wir ca. 6 Monate die Daten rückwirkend. Monats- und Quartals-Sicherungen bleiben länger verfügbar, die anderen wöchentlichen Backups werden dann auch überschrieben.
Somit sind die aktuellen Datenbestände ziemlich gut gesichert.
Jetzt gibt es eben diesen einen kleinen Teil von Daten, die eben supergut gesichert werden sollen und es ist ausdrücklich gewünscht, dass die Daten "lesbar" sind. Hätte ja BackupExec auch mit erledigen können - ist nicht gewünscht. Also nicht in irgendwelchen Datenbanken, sondern in einer 1:1-Kopie und sie sollen auch komplett vom System abgekoppelt sein.
Es soll so sein, dass man eben nachschauen kann, welchen Stand hatte die Datei vor 7 Jahren am 20.10. Bis jetzt war es so, dass da eben tatsächlich jeden Tag die Datei gesichert wurde, was jetzt zu umfangreich wurde.
Mit dem /m-Parameter funktioniert es - sind ja erst ein paar Tage, sieht aber gut aus.
Man müsste sich dann die Festplatte vom Oktober vor 7 Jahren nehmen und die Daten anschauen. Ist am 20.10. nichts drin, muss man eben Tag für Tag zurück, bis max. zum 01.10 - an jedem Monats-Ersten wird nach wie vor eine Vollsicherung gemacht, so dass jede Sicherungs-Festplatte den kompletten Datensatz enthält.
Die normale Datensicherung läuft über Veritas Backup Exec. Am Wochenende ne Vollsicherung und täglich eine inkrementelle. Und zwar einmal auf einen Backup-Server, auf dem sie ca. 90 Tage verbleiben, bis sie wieder überschrieben werden. Zum anderen auf einen externen Datenträger, der jede Woche ausgetauscht wird.
Auf den externen Datenträgern haben wir ca. 6 Monate die Daten rückwirkend. Monats- und Quartals-Sicherungen bleiben länger verfügbar, die anderen wöchentlichen Backups werden dann auch überschrieben.
Somit sind die aktuellen Datenbestände ziemlich gut gesichert.
Jetzt gibt es eben diesen einen kleinen Teil von Daten, die eben supergut gesichert werden sollen und es ist ausdrücklich gewünscht, dass die Daten "lesbar" sind. Hätte ja BackupExec auch mit erledigen können - ist nicht gewünscht. Also nicht in irgendwelchen Datenbanken, sondern in einer 1:1-Kopie und sie sollen auch komplett vom System abgekoppelt sein.
Es soll so sein, dass man eben nachschauen kann, welchen Stand hatte die Datei vor 7 Jahren am 20.10. Bis jetzt war es so, dass da eben tatsächlich jeden Tag die Datei gesichert wurde, was jetzt zu umfangreich wurde.
Mit dem /m-Parameter funktioniert es - sind ja erst ein paar Tage, sieht aber gut aus.
Man müsste sich dann die Festplatte vom Oktober vor 7 Jahren nehmen und die Daten anschauen. Ist am 20.10. nichts drin, muss man eben Tag für Tag zurück, bis max. zum 01.10 - an jedem Monats-Ersten wird nach wie vor eine Vollsicherung gemacht, so dass jede Sicherungs-Festplatte den kompletten Datensatz enthält.
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
Wollte kurze Info geben:
Das funktioniert perfekt - besser als ich mir das vorgestellt habe.
Ich lasse am Monatsersten eine Vollsicherung laufen und den Rest des Monats mit dem "/m".
Es werden jeden Tag alle Verzeichnisse kopiert, aber ohne Inhalt, wenn der sich nicht verändert hat. War ursprünglich nicht so vorgesehen, ist aber in meinem Fall noch besser.
Das funktioniert perfekt - besser als ich mir das vorgestellt habe.
Ich lasse am Monatsersten eine Vollsicherung laufen und den Rest des Monats mit dem "/m".
Es werden jeden Tag alle Verzeichnisse kopiert, aber ohne Inhalt, wenn der sich nicht verändert hat. War ursprünglich nicht so vorgesehen, ist aber in meinem Fall noch besser.
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
Danke für die Info, aber das passiert nicht.
Die Ordner heissen immer ProjektXYZ - werden aus einer Vorlage heraus erstellt - inkl. kompletten Unterverzeichnissen. Es gibt genaue Definitionen wie die Ordner heißen. Da wird nix umbenannt.
Wenn die Projekte abgeschlossen sind, werden sie ins Archiv verschoben und es kommen neue dazu.
Aber einmal angelegte Ordner - sogar Dateien - werden niemals umbenannt.
Die Ordner heissen immer ProjektXYZ - werden aus einer Vorlage heraus erstellt - inkl. kompletten Unterverzeichnissen. Es gibt genaue Definitionen wie die Ordner heißen. Da wird nix umbenannt.
Wenn die Projekte abgeschlossen sind, werden sie ins Archiv verschoben und es kommen neue dazu.
Aber einmal angelegte Ordner - sogar Dateien - werden niemals umbenannt.
