Backup-Archivbit-Problem (umbenannte & verschobene Verzeichnisse)

[sekaczek 10]

Hallo,

 

bei differenziellen und inkrementellen Backups gibt es das folgende Problem:

 

Wenn ein Verzeichnis umbenannt und/oder verschoben wird, werden von Windows die Archivbits der darin enthaltenen Dateien nicht gesetzt. Die Dateien in solchem Verzeichnis werden deswegen bei einem darauf folgenden differenziellen oder inkrementellen Backup nicht gesichert.

 

Dadurch kann es zu schwer nachvollziehbaren (ja sogar zur kaum reparablen) Fehlern nach einer Wiederherstellung kommen.

 

Noch schlimmere Folgen (Daten-Verlust) wird es haben, wenn jemand anhand der Archivbits Verzeichnis-Synchronisierung durchführt, die so konfiguriert ist, dass die im Quell-Verzeichnis nicht mehr vorhandenen Daten auch im Ziel-Verzeichnis gelöscht werden.

 

FRAGE: Weiß jemand von Euch, ob (wie) man das Verhalten von Windows ändern kann.

================================================================

 

Gruß

Sekaczek

 

PS

Getestet auf Windows XP, Server 2003 und 2008 R2.

bearbeitet 29. April 2011 von sekaczek

[zahni 550]

Moderne Backup-programme ignorieren das Archivbit und verwenden das NTFS Change Journal . Prüfe mal, ob das Deine Backup Software nicht auch unterstützt. Ansonsten die das Verhalten beim Verschieben von Ordnern normal. Denn die Werden im Dateisystem nur umgehängt und nicht wirklich verschoben.

 

-zahni

[sekaczek 10]

Moderne Backup-programme ignorieren das Archivbit und verwenden das NTFS Change Journal . Prüfe mal, ob das Deine Backup Software nicht auch unterstützt. Ansonsten die das Verhalten beim Verschieben von Ordnern normal. Denn die Werden im Dateisystem nur umgehängt und nicht wirklich verschoben.

 

-zahni

 

Danke für Deine Antwort.

 

Es ist mir schon klar, dass das Verzeichnis nirgendwo physikalisch verschoben sondern nur "umgehängt" wird (solange alles innerhalb einer Partition passiert). Wichtig sind aber am Ende die Ergebnisse/Auswirkungen für den User und nicht das, wie es technisch realisiert ist.

 

Außerdem, ist das Verhalten beim Umbenennen/Verschieben von Verzeichnissen und Dateien inkonsistent: beim Umbenennen/Verschieben von Dateien innerhalb einer Partition, wird auch nichts tatsächlich verschoben, sondern nur "umgehängt". Trotzdem werden in diesem Fall die Archivbits gesetzt. Bei Verzeichnissen aber nicht, weder für die Dateien, noch für das Verzeichnis selbst.

 

Es geht um einen kleineren Kunden, bei dem ich das Netzwerk supporte. Er verwendet ein einfaches Backup-Programm und möchte auf kein anderes (teures) umsteigen.

 

Ich habe ihn Robocopy vorschlagen wollen, aber es würde auch nichts bringen. Robocopy verhält sich auch nicht anders, wenn man Archivbits verwendet. Außerdem möchte er ein Tool mit GUI haben.

 

Und auf Zeitstempel-Synchronisierung möchte er sich nicht verlassen, weil seine Mitarbeiter oft Dateien auf mit FAT32 formatierten Datenträger hin und her transportieren und bearbeiten, wodurch man wieder das Problem mit der Zeitumstellung hat.

 

Insgesamt ein "schwieriger Fall" :rolleyes: ;)

 

Wenn man sich auf die Mitarbeiter verlassen könnte, würde man als Notlösung in der Registry ein neues Shell-Eintrag mit "attrib +A . . ." erstellen, aber da gibt es keine Garantie, dass es immer verwendet wird.

 

Gruß

Sekaczek

bearbeitet 29. April 2011 von sekaczek

[sekaczek 10]

Hallo,

 

soll ich das so verstehen, dass niemand sonst eine Antwort auf meine Frage hat? :(

 

Gruß

Sekaczek

[GuentherH 61]

Hallo.

 

soll ich das so verstehen, dass niemand sonst eine Antwort auf meine Frage hat?

 

Es wurde dir hier und in einem anderen Forum bereits erklärt dass das Verhalten völlig normal ist.

 

Er verwendet ein einfaches Backup-Programm und möchte auf kein anderes (teures) umsteigen.

 

Und hier liegt der Knackpunkt. Der Kunde will eine Leistung, aber dafür kein Geld ausgeben. Beiden zusammen ist halt immer nicht möglich.

Hier hilft nur dem Kunden zu erklären, was mit ein einer preiswerten Lösung machbar ist, und wo mit dieser Lösung die Grenze ist.

 

LG Günther

[sekaczek 10]

Hallo Günther

 

na ja eine Erklärung wurde ich das nicht unbedingt nennen. Es wurde eher gesagt, dass die Bits nicht gesetzt werden, weil sie nicht gesetzt werden - siehe das andere Forum.

 

Außerdem, habe ich auch keine Erklärung gebraucht und um keine Erklärung gebeten, sondern nur gefragt, ob man das Verhalten mit z. B. einem, mir noch unbekannten, Registry-Key ändern kann.

 

Das Verhalten an sich ist mir schon länger bekannt, nur hat mich bis jetzt nicht gestört. Bis zu diesem Kunden eben. Ich fand es aber nie, dass das bezogen auf Dateien einerseits und auf Verzeichnisse andererseits unterschiedliche Verhalten normal ist. Entweder in beiden Fällen Bits setzen oder in beiden nicht - dies wäre normal. Warum es so nicht gemacht wurde, kann ich nur vermuten - wahrscheinlich hat man in der Vergangenheit Performance-Probleme bei Umbenennen von Verzeichnissen mit vielen Dateien vermeiden wollen.

 

Gruß

Sekaczek

[zahni 550]

Wie ich Dir schon geschrieben haben, werden bei bestimmten Verschiebeoperationen Die Verweise auf die Dateien und Verzeichnisse im Dateisystem nur verändert. Die Dateien behalten ihre ursprüngliche Position. Und damit auch ihre NTFS-Berechtigungen und Attribute. Das Archivbit stammt aus DOS-Zeiten und sollte heute schlicht ignoriert werden. Das NTFS Change Journal ist hier deutlich sicherer und kann auch mehrfache Änderungen protokollieren. Roboby ist kein Tool zur Sicherungs von Dateien bzw. stößt man u.U. auf Probleme. So wie Du...

 

-Zahni

[sekaczek 10]

Hallo Zahni,

 

und wie ich auch schon oben geschrieben habe: das Behalten der Position (also nur eine Veränderung der Verweise) ist keine logische Erklärung. Warum dann werden Archivbits bei Umbenennen und/oder Verschieben von Dateien gesetzt. Die Dateien ändern bei dieser Aktion auch ihre Position nicht und es werden auch nur Verweise angepasst. Trotzdem wird das Bit gesetzt.

 

Außerdem war das nicht meine Frage - siehe oben

 

Gruß

Sekaczek