Robocopy - diffrentielles Backup

Hallo Uli,

zuerst mal Vorsicht, mit dem Schalter /MIR macht Robocopy keine richtigen Backups, sondern synchronisiert Ziel mit Quelle. Das heißt: Verzeichnisse und Dateien, die in der Quelle nicht mehr vorhanden sind, also verschoben, umbenannt oder gelöscht wurden, werden auch im Ziel gelöscht.

Was macht der Schalter /MT - Irgendwie kann ich es in Robocopy-Hilfe nicht finden?

Wenn Du denn Schalter /A weglest und den Schalter /MIR verwendest, sollte RC eigentlich nur die Verzeichnisse und Dateien kopieren, die in Quelle und Ziel unterschiedlich sind, dazu kommt noch das oben erwähnte Löschen.

Gruß
Sekaczek

PS:
Fortsetzung folgt

also das ist mein Robocopy befehl


Erklärung:
/S /PURGE = /MIR
/A-:HS = Atribute Versteckt und System entfernen
/MIN:1 = Mindestdateigrösse 1 Byte
/R:5 /W:10 = Wartezeit bei Fehlern und Wiederholungen
/XD "System Volume Information" "$Recycle.bin" = auszuschliessende Systemordner
/tee /LOG:"S:\Sicherung %Date%.txt" = Log Datei und Display Text

Bei mir funktioniert alles perfekt

Grüsse

moin,

ich würde das anders lösen....

• vollbackup

• diffbackup

Nur ein Denkanstoß, da ich der Windows und Denkfreien Zone bin.

Gruß

Versuch mal genau meinen Befehl zu benutzen

Fortsetzung:

Wenn Du korrekte differentielle Backups machen möchtest, solltest Du zuerst einen Vollbackup ohne Beachtung der Archivbits machen, dann die Archivbits in der Quelle mit "attrib" zurücksetzen und (bis zum nächsten Vollbackup) mit dem Schalter /A differentielle Backups erstellen.

Für korrekte differentielle Backups müsstest Du allerdings das Ziel bei jedem differentiellen Backup immer ändern.

Anhand Deines Skriptes nehme ich jedoch an, dass Du immer in das selbe Ziel kopieren willst. In diesem Fall wirst Du mit dem Schalter /MIR wegen dem Löschen keine differentiellen Backups erreichen, sondern eine Synchronisierung von Ziel und Quelle. Bei Backups wird grundsätzlich nichts gelöscht.

Privat mache ich es übrigens auch so - d.h. immer gleiches Ziel und die Schalter /E /PURGE , was dem Schalter /MIR entspricht. Das kann man aber nur dann so machen, wenn man verantworten kann, was auf der Quellen-Seite passiert, also praktisch nur privat, sonst werden zum Beispiel von einem Mitarbeiter versehentlich gelöschte Dateien bei einem nachfolgenden differentiellem Backup auch im Ziel gelöscht = Original und Backup ist dann verloren.

Bei einer Synchronisierung solltest Du die Archivbits auf der Quellen-Seite nicht beachten, d.h. die Schalter /A oder /M nicht verwenden, dies kann in bestimmten Situationen dazu führen, dass Du nicht alle Dateien gesichert hast, und wenn Wiederherstellung nötig wird, sogar zum partiellen Datenverlust.

Auch bei differentiellen Backups können diese beiden Schalter Probleme verursachen - wie zum Beispiel Dateien im falschen Verzeichnis oder eventuell sogar Datenverlust.

Wenn Man die beiden Schalter nicht verwendet, kopiert RC (ohne zusätzliche Schalter) Dateien ins Ziel, die in der Quelle neuer oder auch älter sind und natürlich auch solche die noch im Ziel nicht vorhanden sind. Dies kann aber eventuell, auch zu kleinen Problemchen führen, wenn man die automatische Sommerzeit-Umstellung aktiviert und gleichzeitig Dateien auf unterschiedlichen Dateisystemen bearbeitet und zwischen diesen Systemen verschiebt oder kopiert - zum Beispiel NTFS und USB-Stick mit FAT32. Bei mir gibt es beides nicht mehr - keine automatische Zeit-Umstellung und auch USB-Datenträger werden in NTFS formatiert.

Privat verwende ich die folgenden Schalter für Synchronisierung:
/E /ZB /COPYALL /PURGE /XJ /R:10 /W:10 /X /LOG:file manchmal auch /TEE und /L, wenn ich nur die Unterschiede sehen will, ohne wirklich zu synchronisieren.

Gruß
Sekaczek

Es könnte eventuell ein der von mir zuvor angesprochenen Probleme mit Archivbits sein. (siehe ein früherer Kommentar von mir weiter unten)

Am besten mit /A oder /M nicht arbeiten, sondern einfach anhand der Timestamps der Dateien synchronisieren. (Beachte Anmerkungen unten)

====================
Anmerkungen:

Auch Timestamps können kleinere vermeidbare Probleme verursachen, wenn man mit unterschiedlichen Dateisystemen arbeitet und Dateien zwischen diesen Systemen verschiebt oder kopiert und die automatische Sommer-Zeitumstellung aktiviert.

Eine Synchronisierung (Robocopy mit dem Schalter /MIR oder mit /E /PURGE) reicht aber als eine Daten-Sicherung nur in einer kleinen privaten Umgebung mit wenigen (am besten nur einen) und verantwortlichen Benutzern, die wissen was sie tun und eventuelle Fehler beim Umgang mit Dateien auch merken, damit diese vor der nächsten Synchronisierung behoben werden.
Wenn Du eine Synchronisierung als Daten-Sicherung einsetzen möchtest, solltest Du aber auch robocopy immer zuerst mit der Option /L ausführen und zumindest die im Ziel zu löschenden Dateien auf Auffälligkeiten vor dem Start der Synchronisierung überprüfen.

In allen anderen Fällen ist eine Synchronisierung nicht die richtige Lösung, sondern je nach Menge der Daten, der Häufigkeit der Änderungen, und Leistungsfähigkeit des Backup-Ressourcen entweder Vollständige oder differentielle bzw. inkrementell Backups.
Dafür ist aber Robocopy eigentlich nicht geeignet, oder nur sehr sehr bedingt und mit etwas aufwendigeren Skripten.

Jetzt noch mal zurück zu dem Problem mit dem Schaltern /A oder /M bzw mit den Archivbits.

Zu den Problemen kommt es, entweder weil die Archivbits nicht immer dann gesetzt werden, wann sie eigentlich gesetzt werden müssten, oder weil sie gar nicht unterstützt werden.

Von den Problemen ist also nicht nur Robocopy, sondern auch alle anderen Tools betroffen, die Archivbits verwenden.

Fragen dazu:

- Auf welche weise hast Du die neuen Dateien eingefügt?

- Verwendest Du NAS oder NDAS?

- Welcher Filesystem/OS wird auf dem NAS eingesetzt?

- Hast Du überprüft, ob die Archivbits der neuen Dateien gesetzt sind?

Gruß
Sekaczek

Sorry. kleine Korrektur /MIR = /E /PURGE (nicht /S /PURGE)

Gruß
Sekaczek

nicht sorry, eher danke...
war mir eben nicht ganz sicher

Grüsse

Dann sollte Archivbit eigentlich gesetzt sein.

Siehe noch die weiteren Hinweise und Fragen in dem Beitrag oben.

Gruß
Sekaczek

Guten Morgen

Na ja, ich würde es nicht tun. Ich verwende privat eine Synchronisierung anhand der Timestamps der Dateien. Die Probleme mit Timestamps sind nicht so schwerwiegend, sehr selten und vermeidbar.

Auch die Probleme mit Archivbits sind es, aber dies ist unter Umständen viel problematischer.

Es kommt immer auf die Umgebung und auf die zu Verfügung stehenden Mittel an, für welchen Strategie und Software man sich entscheidet:

Fehleranfälligkeit der zu sichernden Systeme
Wer mit den Daten arbeitet (zum Teil auch Fehleranfälligkeit)
Wie wichtig sind die Daten.
Datenmenge
Anteil / Häufigkeit der Änderungen
Gewünschte Komplexität der Wiederherstellung
usw.

Zu Bedenken ist auch, dass man mit keinem Backup eine vollkommene Sicherheit erreicht.
Es geht dabei nicht um Schadens-Vermeidung, sondern nur Schadens-Minimierung im Falle eines Falles.

Gruß
Sekaczek

Dann ist alles klar. Normalerweise werden von Linux-Systemen keine Archivbits unterstützt.

Bei Zugriffen von Windows-Systemen über Samba können jedoch Archivbits verwendet werden. Die Archivbits werden dabei in den erweiterten Attributen gespeichert bzw. auf die Executable-Bits des Linux-Systems gemapt. Dies erfordert aber entsprechende Konfiguration - Siehe zum Beispiel hier: http://lists.samba.org/archive/samba/2006-September/125314.html oder Suche nach Archivbit und Samba. (Nachtrag: Sorry, der Link ist falsch. Korrekte Links siehe weiter unten)

Es kann sein, dass Du in diesem Fall, die von mir zuvor erwähnten Probleme mit Archivbits nicht hast. Auf reinen Windows-Systemen ist es so, dass beim Umbenennen und/oder Verschieben von ganzen Verzeichnissen die Archivbits der Dateien innerhalb der Verzeichnisse nicht gesetzt werden. Es gibt auch (wenige) Windows-Programme die bei Datei-Zugriffen geänderte Dateien ohne Archivbit im Dateisystem erzeugen. Da in Deinem Fall das Linux-System die Kontrolle über die Dateien hat, könnte es evtl. auch anders sein - es kommt auf die jeweilige Implementierung in Linux-Samba an


Wenn Du fertig damit bist, kannst Du darüber berichten.

Gruß
Sekaczek

Hallo,

entschuldige diesen Link aus dem Beitrag zuvor, dort steht nichts über die Konfiguration - habe es davor gar nicht gelesen - nur den Titel.

Die maps system und hidden brauchst gar nicht, nur archive. Es muss aber im richtigen Abschnitt eingetragen werden. Im Allgemeinen solltest Du auch wissen, dass die Einträge auch Auswirkungen auf die Zugriffsrechte auf der Linux-Seite haben. Ok ist vielleicht bei einem NAS nicht so wichtig.

Im Prinzip sollte es auch ohne Einträge funktionieren, da die Standard-Einstellungen schon korrekt sein sollten. Man weiß es aber nie so genau bei einem proprietären System, wie der Hersteller dies gemacht hat. Deswegen, wenn es eben nicht funktioniert, mal ausprobieren und die entsprechenden Einträge setzen.

Bezüglich der Attribute-Bits sind auch die "creation masks" von Bedeutung, weil sie die gleichen Bits betreffen.

Näheres dazu kannst Du hier erfahren: http://oreilly.com/catalog/samba/chapter/book/ch05_03.html - ist ziemlich ausführlich.
Hier habe ich nur paar Beispiele gesehen http://www.vdr-wiki.de/wiki/index.php/Samba, aber nicht gelesen

Gruß
Sekaczek

PS
Gib mir Bescheid, wenn es funktioniert.

Hallo Uli (Barney),

freut mich, dass es endlich klappt.

1)
Weiß Du jetzt vielleicht, warum es anfangs (mit den Archivbits) nicht funktionierte, nachdem Du zum ersten mal die map-Optionen in smb.conf eingetragen hast?
Lag es an "create mask" oder war es etwas anderes, ein Versehen, etwas herstellerspezifisches, o. ä.? Wie auch immer, es wäre nett, wenn Du das noch kurz posten könntest.

2)
Und noch eine Frage, wie verhält sich das NAS-Linux-System bezüglich Datei-Archiv-Attribute, wenn ein Verzeichnis umbenannt oder auf gleicher Partition verschoben wird? Werden die Archivbits der Dateien innerhalb des Verzeichnisses wieder gesetzt?

3)
Es gibt noch ein "kleines Problem". Ich hoffe, dass Du mein Hinweis darauf, dass man für jedes diff. Backup das Ziel ändern soll, richtig verstanden hast. Ich war dort vielleicht nicht besonders präzise.
Also, genauer ausgedrückt: Der (Die) Vollbackup(s) und die differentiellen Backups sollten normalerweise immer auf (pro Backup-Zyklus) unterschiedlichen Datenträgern gespeichert werden. Man setzt dabei ein so genanntes Generationen-Prinzip (Großvater-Vater-Sohn-Prinzip) ein - findest Du mit Sicherheit bei Google.

Wenn Du nur ein Datenträger verwendest, gibt es das Risiko, dass (zum Beispiel) bei einem Backup-Vorgang der Datenträger kaputt geht, wodurch alle früheren Voll- und Diff-Backups verloren wären.

Natürlich kannst Du dann sofort einen neuen Backup-Datenträger besorgen, und wieder neu mit einem Vollbackup anfangen, da es unwahrscheinlich ist, dass die Quell-Datenträger gleichzeitig kaputt gehen.
Aber der alte Voll-Backup und alten differentiellen Backups mit (eventuell fälschlicherweise) auf dem Quell-Datenträger gelöschten Dateien, sind unwiderruflich verloren. Dies bedeutet, einer der Vorteile dieser Backup-Art kann mit nur einem Backup-Datenträger nicht erreicht werden, bzw. nicht "garantiert" werden.

Es ist allein Deine (bzw. Deiner Firma) Entscheidung, ob das Risiko, das je nach Art des Backups-Datenträgers größer oder kleiner ist, akzeptabel ist.
Aber, wenn man es im Fall eines Backup-Datenträger-Defektes akzeptieren kann, dann kann man es wahrscheinlich auch immer akzeptieren, und anstatt sich für differentielle Backups, für eine einfache Synchronisierung entscheiden, mit der man zwar keine unterschiedlichen Backup-Versionen hat, aber dafür die kleinste Backup-Datenmenge, nur minimal mehr Zeit für die Sicherungen benötigt, und dank dem genauen Abbild der Quelle die schnellste Wiederherstellung (wie ein Vollbackup) ermöglicht.

Falls Du mehrere differentielle Backups auf Festplatte(n) erstellen möchtest, solltest Du mindestens zwei Datenträger abwechselnd verwenden. In einer privaten Umgebung würde ich es fast immer als vollkommen ausreichend betrachten - für meinen privaten Bereich wäre es sogar zu viel.
Geschäftlich sollte man aber nach einem vollständigen Backup-Szenario arbeiten - siehe Generationen-Prinzip.

Gruß
Sekaczek

Hallo Uli (Barney),

wäre schön, wenn Du noch eine abschließende Rückmeldung zu den drei Punkten im obigen Post geben könntest.

Gruß
Sekaczek

Hallo Uli
hatte in letzter Zeit auch viel zu tun und habe leider immer noch fast keine Zeit

Du meinst wohl aus dem Flash-Speicher in den Arbeitsspeicher bzw. auf die RAM-Disk.. Und ich dachte, es funktioniert jetzt alles bei Dir - schade

Starte nur den Samba-Server neu, anstatt den ganzen NAS.
Falls der User-Interface vom Deinem NAS diese Funktion nicht unterstützt, kannst Du es von Windows aus per PuTTY nach jedem NAS-Start manuell erledigen, oder besser noch mit Hilfe eines Linux-Scripts nach jedem NAS-Start alles nötige automatisch machen lassen.

BTW: Hast Du schon versucht, den Hersteller zu kontaktieren. Vielleicht gibt es auch bereits korrigierte Firmware für Deinen NAS? Dann könntest Du dein flash updaten.


Da gibt es zwei mögliche Problem-Stellen und paar mögliche Lösungen:

A) Erstens die folgenden Optionen
- create mask (create mode) - beschränkt die maximalen Rechte (AND-Operator) - ist Bit 3 in dieser Maske nicht gesetzt, kann man Archivbits nie setzen.
- directory mask (directory mode) - im Prinzip das gleiche wie oben, aber für Verzeichnisse.
- force create mode - erzwingt die minimalen Rechte (OR-Operator) - ist Bit 3 in dieser Maske gesetzt, bleiben Archivbits immer gesetzt.
- force directory mode - im Prinzip das gleiche wie oben, aber für Verzeichnisse.
Die Option 3 könnte die Ursache sein, dass bei Dir die Archivbits immer gesetzt sind.
An Deiner Stelle würde ich aber alle diese Optionen definieren, und mich nicht auf den Hersteller verlassen - sonst bist Du verlassen
Es sei dem, Du findest korrigierte Firmware für Deinen NAS.
Hinweise:
Die Werte für diese Optionen werden als Oktadezimal-Zahlen eingegeben, die man auf die Rechte r w x r w x r w x bitweise abbilden kann.
Das Recht owner-eXecute, also Bit 3 von links, wird bei Samba als Archiv-Bit verwendet.
Die Optionen beeinflussen alle Bits der Berechtigungen, nicht nur Archivbit.

B) Zweitens der Besitzer der Dateien.
Unter Linux / Unix / Samba kann NUR der Owner die Rechte ändern, und Archivbit wird ja von Samba auf die Rechte gemapt.
Dies solltest Du überprüfen und entsprechend anpassen.

C) Alternativ zum Punkt B könntest Du auch die Option "dos filemode = yes" setzen. Diese Option sollte das oben beschriebene Verhalten ändern.
Ich persönlich würde eher bevorzugen, dass die Owners passend festgelegt sind.

D) Nur ein Test - keine dauerhafte Lösung.
Zum Test könntest Du nach einem Voll-Backup versuchen, die Rechte (Archivbits) auf der Linux-Seite mit "chmod" zu ändern, und dann schauen. was Windows anzeigt.
Hab's nie versucht, aber es müsste funktionieren. Samba wird wohl nicht ständig alle Dateien im share überwachen - sondern wartet auf Anweisungen von draußen. Ggf. kannst Du den Samba-Server auch dafür stoppen.

Aber nicht vergessen
Falls Du die Platten bei jedem Differential-Backup tauschen möchtest, muss Du auf beiden Platten auch den gleichen Voll-Backup haben - sonst macht das keinen Sinn.
Falls Du bei jeder Voll-Backup-"Erneuerung" tauschen möchtest, wäre dies nicht notwendig. Allerdings müsstest Du dann auch ziemlich oft die Voll-Backups machen, damit Deine inaktive Backup-HDD auch relativ aktuelle Dateien erhält, falls die aktive Backup-HDD ausfallen sollte. Dies wäre eher für ein vollwertiges Backup-Szenario mit mehreren Datenträgern geeignet.

Ok - und wie? So wie ich oben beschrieben habe oder hast Du andere Methode gefunden?

Gruß
Sekaczek

PS: Melde Dich bitte, wenn es neue Erkenntnisse gibt - auch wenn alles endlich funktionieren sollte.

[ Edit 23.05.2011 15:00 ]
Zum Punkt D):
Man könnte es eventuell als eine NOT-Dauer-Lösung anwenden, falls das Setzen der Archivbits automatisch funktioniert, nur das Rücksetzten nicht.
Da die Archivbits bei differentiellen Backups nicht verändert werden, und sie auf Voll-Backups keine Auswirkung haben, müsste man nur immer nach einem Voll-Backup die Archivbits per PuTTY oder Start-Script mit "chmod" rücksetzen.
[ Edit-Ende ]

Hallo Uli (Barney),

wie läuft's? Funktioniert's jetzt? Oder hast Du es aufgegeben?

Gruß
Sekaczek