5
Backup-Archivbit-Problem (umbenannte oder verschobene Verzeichnisse)
Hallo,
bei differenziellen und inkrementellen Backups gibt es das folgende Problem:
Wenn ein Verzeichnis umbenannt und/oder verschoben wird, werden von Windows (anders als beim Umbenenne/Verschieben von einzelnen Dateien) keine Archivbits gesetzt, weder für die in dem Verzeichnis enthaltenen Dateien, noch für das Verzeichnis selbst. 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 1
Getestet auf Windows XP, Server 2003 und 2008 R2.
PS 2
Bitte keine Antworten, die mir den Einsatz einer anderen Backup-Software empfehlen - bei diesem Kunden hätte sie eventuell nur dann eine Chance, wenn sie (fast) kostenlos und sehr leicht zu bedienen wäre. Auch Zeitstempel gestützte Backups bzw. Synchronisierung sind aus bestimmten Gründen nicht möglich.
PS 3
Mir ist klar, dass beim Verschieben innerhalb einer Partition, nichts wirklich verschoben wird, sondern nur so zu sagen umgehängt.
bei differenziellen und inkrementellen Backups gibt es das folgende Problem:
Wenn ein Verzeichnis umbenannt und/oder verschoben wird, werden von Windows (anders als beim Umbenenne/Verschieben von einzelnen Dateien) keine Archivbits gesetzt, weder für die in dem Verzeichnis enthaltenen Dateien, noch für das Verzeichnis selbst. 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 1
Getestet auf Windows XP, Server 2003 und 2008 R2.
PS 2
Bitte keine Antworten, die mir den Einsatz einer anderen Backup-Software empfehlen - bei diesem Kunden hätte sie eventuell nur dann eine Chance, wenn sie (fast) kostenlos und sehr leicht zu bedienen wäre. Auch Zeitstempel gestützte Backups bzw. Synchronisierung sind aus bestimmten Gründen nicht möglich.
PS 3
Mir ist klar, dass beim Verschieben innerhalb einer Partition, nichts wirklich verschoben wird, sondern nur so zu sagen umgehängt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 165403
Url: https://administrator.de/contentid/165403
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
5 Kommentare
Neuester Kommentar
Hi,
Wenn dir das klar ist, weißt du vielleicht auch, warum das so ist: Weil nämlich beim Anlegen eines Verzeichnisses' auch kein Archivbit auf NTFS-Partitionen gesetzt wird.
Bei Dateien wird das Archivbit nur bei Neuanlage oder Veränderung gesetzt, und da erfolgt ja nichts Entsprechendes beim Verschieben: Der Dateiinhalt ist ja unverändert.
Dir wird wohl keine andere Lösung übrig bleiben, als zusätzliche Verwendung von Konsolenbefehlen zu nutzen oder auf einen anderen Dateimanager als den Explorer auszuweichen.
Das Thema wurde hier schon mal diskutiert.
Gruß
Zitat von @Sekaczek:
Mir ist klar, dass beim Verschieben innerhalb einer Partition, nichts wirklich verschoben wird, sondern nur so zu sagen
umgehängt.
Mir ist klar, dass beim Verschieben innerhalb einer Partition, nichts wirklich verschoben wird, sondern nur so zu sagen
umgehängt.
Wenn dir das klar ist, weißt du vielleicht auch, warum das so ist: Weil nämlich beim Anlegen eines Verzeichnisses' auch kein Archivbit auf NTFS-Partitionen gesetzt wird.
Bei Dateien wird das Archivbit nur bei Neuanlage oder Veränderung gesetzt, und da erfolgt ja nichts Entsprechendes beim Verschieben: Der Dateiinhalt ist ja unverändert.
Dir wird wohl keine andere Lösung übrig bleiben, als zusätzliche Verwendung von Konsolenbefehlen zu nutzen oder auf einen anderen Dateimanager als den Explorer auszuweichen.
Das Thema wurde hier schon mal diskutiert.
Gruß
Zitat von @99045:
Hi,
> Zitat von @Sekaczek:
> Mir ist klar, dass beim Verschieben innerhalb einer Partition, nichts wirklich verschoben wird, sondern nur so zu sagen
umgehängt.
Wenn dir das klar ist, weißt du vielleicht auch, warum das so ist: Weil nämlich beim Anlegen eines
Verzeichnisses' auch kein Archivbit auf NTFS-Partitionen gesetzt wird.
Dir wird wohl keine anderes Lösung übrig bleiben, als zusätzliche Verwendung von Konsolenbefehlen zu nutzen oder
auf einen anderen Dateimanager als den Explorer auszuweichen.
Das Thema wurde hier schon mal diskutiert.
Gruß
Hi,
> Zitat von @Sekaczek:
> Mir ist klar, dass beim Verschieben innerhalb einer Partition, nichts wirklich verschoben wird, sondern nur so zu sagen
umgehängt.
Wenn dir das klar ist, weißt du vielleicht auch, warum das so ist: Weil nämlich beim Anlegen eines
Verzeichnisses' auch kein Archivbit auf NTFS-Partitionen gesetzt wird.
Dir wird wohl keine anderes Lösung übrig bleiben, als zusätzliche Verwendung von Konsolenbefehlen zu nutzen oder
auf einen anderen Dateimanager als den Explorer auszuweichen.
Das Thema wurde hier schon mal diskutiert.
Gruß
Danke sehr für Deine sehr nützliche Antwort.
Jetzt ist mir alles klar: Die Archivbits werden nicht gesetzt, weil sie nicht gesetzt werden. Hätte ich nicht gedacht. Wie lautete nochmal meine Frage?
Zur Info: mir ist bekannt, dass es zum Beispiel den Befehl attrib gibt, und auch wie man es verwendet, sowie dass man einen Shell-Eintrag mit Command "attrib ... +A ..." in der Registry erstellen kann, damit man bequem per Kontextmenü die Archivbits setzen kann. Das Problem ist, dass die User noch bequemer sind und außerdem auch vergesslich, und es nicht immer verwenden werden.
Wie dick muss man eigentlich eine Frage unterstreichen, damit man Antworten auf diese Frage erhält, auch wenn sie dann lauten sollten: "Nein, es gibt keine Möglichkeit" oder "Ich kenne leider keine..." oder auch "Ich bin nicht sicher, glaube aber, dass es nicht geht".
Also noch mal meine FRAGE:
Ist jemandem von Euch bekannt, ob (wie) man Windows beibringen kann, beim umbenennen und/oder Verschieben von Verzeichnissen innerhalb einer Partition die Archivbits der Dateien innerhalb der umbenannten/verschobenen Verzeichnisse zu setzen, wie es auch beim Umbenennen oder Verschieben von Dateien tut?
Ach, und fett formatieren kann ich auch
Gruß und nichts für ungut
Sekaczek
Man muss nur so pampig auf einen Kommentar antworten wie du, damit man überhaupt keine Antwort mehr bekommt.
EOD
EOD
Zitat von @99045:
Man muss nur so pampig auf einen Kommentar antworten wie du, damit man überhaupt keine Antwort mehr bekommt.
EOD
Man muss nur so pampig auf einen Kommentar antworten wie du, damit man überhaupt keine Antwort mehr bekommt.
EOD
Entschuldige mal, aber Deine Antwort hatte auch eine gewisse Note Sarkasmus oder zumindest Spott und
1. es war keine Antwort auf meine Frage 2. im ersten Satz klugsch...risch 3. und ein Versuch irgendeine Frage mit der Frage selbst zu beantworten.
Es gibt nur noch eine Steigerung: Du hättest auch so antworten können: "Schon mal danach gegoogelt?"
Ich kann solche Antworten echt nicht leiden - Sie kosten nur Zeit und bringen gar nichts. Man bekommt eine E-Mail, freut sich auf eine logische Antwort, startet den Browser, such das Lesezeichen aus und dann sieht man so was. Da habe ich einfach rot gesehen . . .
Hallo,
soll ich das so verstehen, dass niemand sonst eine Antwort auf meine Frage hat?
Gruß
Sekaczek
soll ich das so verstehen, dass niemand sonst eine Antwort auf meine Frage hat?
Gruß
Sekaczek
