28
Robocopy - diffrentielles Backup
Hallo,
nach kleineren Anfangsschwiergkeiten habe ich das Backup vom Laptop auf eine externe Festplatte hinbekommen
Nun möchte ich Daten von meinem NAS ebenfalls auf die externe Festplatte sichern. Wie beim Backup des Laptops möchte ich auch hier zwischen einem kompletten Backup und einem diffrentiellen Backup unterscheiden.
Ich habe das beim Laptop funktionierende Skript an das NAS angepasst, es kopiert beim diffrentiellen Backup des NAS nur die leere Ordnerstruktur.
Lasse ich den Schalter "/A" weg, kopiert er alle Daten.
Irgendwo habe ich wohl einen Denkfehler, oder? ;)
Danke und Grüße
Uli
nach kleineren Anfangsschwiergkeiten habe ich das Backup vom Laptop auf eine externe Festplatte hinbekommen
Nun möchte ich Daten von meinem NAS ebenfalls auf die externe Festplatte sichern. Wie beim Backup des Laptops möchte ich auch hier zwischen einem kompletten Backup und einem diffrentiellen Backup unterscheiden.
Ich habe das beim Laptop funktionierende Skript an das NAS angepasst, es kopiert beim diffrentiellen Backup des NAS nur die leere Ordnerstruktur.
:: -------------------------------- Variablen setzen ---------------------------------
setlocal
set quelle=\\NAS\Volume_1\Dateien
set ziel=X:\backup\nas\diff\daten
:: --------------------- Starten von Robocopy ----------------------
@Echo off
robocopy.exe "%quelle%" "%Ziel%" /A /XJ /MIR /MT:8 >> "x:\backup\nas\nas-log-diff.txt"
cd "%ziel%"
if exist desktop.ini attrib -H -R desktop.ini
if exist desktop.ini del desktop.ini
pauseLasse ich den Schalter "/A" weg, kopiert er alle Daten.
Irgendwo habe ich wohl einen Denkfehler, oder? ;)
Danke und Grüße
Uli
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: 165442
Url: https://administrator.de/contentid/165442
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
28 Kommentare
Neuester Kommentar
Hi Uli
als erstes fällt mir das auf:
Was keinen Sinn macht, denn zuerst änderst du die Attribute, und danach löscht du die Datei
2. du willst ein diffrentielles Backup vom NAS? Dafür braust du ja zuerst ein Voll Backup...
also lass doch einfach ein
laufen, dann macht er beim ersten Mal ein Vollbackup und danach synchronisiert er die Dateien einfach
Grüsse
Switcher
als erstes fällt mir das auf:
if exist desktop.ini attrib -H -R desktop.ini
if exist desktop.ini del desktop.ini2. du willst ein diffrentielles Backup vom NAS? Dafür braust du ja zuerst ein Voll Backup...
also lass doch einfach ein
robocopy "%quelle%" "%Ziel%" /mir Grüsse
Switcher
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
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
Danke Switcher,
werde ich so versuchen.
Die beiden Zeilen zur desktop.ini habe ich vergessen aus dem Skript zu löschen. Sie waren für das Backup meines Desktops erforderlich. Ohne das Löschen der desktop.ini, hat das Verzeichnis in der Datensicherung nicht den vorgegebenen Namen übernommen und wurde immer als "desktop" angezeigt. Und das Löschen ging nur mit geänderten Attributen.
Grüße
Uli
werde ich so versuchen.
Die beiden Zeilen zur desktop.ini habe ich vergessen aus dem Skript zu löschen. Sie waren für das Backup meines Desktops erforderlich. Ohne das Löschen der desktop.ini, hat das Verzeichnis in der Datensicherung nicht den vorgegebenen Namen übernommen und wurde immer als "desktop" angezeigt. Und das Löschen ging nur mit geänderten Attributen.
Grüße
Uli
Auch dir vielen Dank Sekaczek.
Der Schlater "/MT" soll den Backup beschleunigen, erzeugt Multithreadkopien mit hier 8 Threads.
Mir war klar, dass "/MIR" die Dateien zwischen Ziel und Quelle nur synchronisiert. Ich erstelle aus diesem Grund ein wöchentliches Backup, das die Daten komplett und separat sichert.
Grüße
Uli
Der Schlater "/MT" soll den Backup beschleunigen, erzeugt Multithreadkopien mit hier 8 Threads.
Mir war klar, dass "/MIR" die Dateien zwischen Ziel und Quelle nur synchronisiert. Ich erstelle aus diesem Grund ein wöchentliches Backup, das die Daten komplett und separat sichert.
Grüße
Uli
Zitat von @90776:
2. du willst ein diffrentielles Backup vom NAS? Dafür braust du ja zuerst ein Voll Backup...
also lass doch einfach ein
laufen, dann macht er beim ersten Mal ein Vollbackup und danach synchronisiert er die Dateien einfach
Grüsse
Switcher
2. du willst ein diffrentielles Backup vom NAS? Dafür braust du ja zuerst ein Voll Backup...
also lass doch einfach ein
> robocopy "%quelle%" "%Ziel%" /mir
> Grüsse
Switcher
Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter "/A" versehen, keine neu eingefügten Dateien gesichert.
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
robocopy %Quelle% %Ziel% /S /PURGE /A-:HS /MIN:1 /R:5 /W:10 /XD "System Volume Information" "$Recycle.bin" /tee /LOG:"S:\Sicherung %Date%.txt" 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....
Nur ein Denkanstoß, da ich der Windows und Denkfreien Zone bin.
Gruß
ich würde das anders lösen....
- vollbackup
robocopy quelle ziel parameter
- diffbackup
robobcopy quelle ziel parameter /l>filelist.txt
schleifchen um xcopy quelle zieldiff pro treffer in filelist.txt
schleifchen um xcopy quelle zieldiff pro treffer in filelist.txt
Nur ein Denkanstoß, da ich der Windows und Denkfreien Zone bin.
Gruß
Bei mir klappt bei der Sicherung der Laptop-Verzeichnisse auch alles. Ich habe "nur" die Probleme bei der Sicherung des NAS. 
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
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
Zitat von @Barney:
> Zitat von @90776:
> 2. du willst ein diffrentielles Backup vom NAS? Dafür braust du ja zuerst ein Voll Backup...
> also lass doch einfach ein
>
> laufen, dann macht er beim ersten Mal ein Vollbackup und danach synchronisiert er die Dateien einfach
>
> Grüsse
> Switcher
Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter "/A"
versehen, keine neu eingefügten Dateien gesichert.
> Zitat von @90776:
> 2. du willst ein diffrentielles Backup vom NAS? Dafür braust du ja zuerst ein Voll Backup...
> also lass doch einfach ein
>
> > robocopy "%quelle%" "%Ziel%" /mir
> > >
> Grüsse
> Switcher
Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter "/A"
versehen, keine neu eingefügten Dateien gesichert.
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
Zitat von @90776:
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
also das ist mein Robocopy befehl
> robocopy %Quelle% %Ziel% /S /PURGE /A-:HS /MIN:1 /R:5 /W:10 /XD "System Volume Information" "$Recycle.bin"
> /tee /LOG:"S:\Sicherung %Date%.txt"
> 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
Sorry. kleine Korrektur /MIR = /E /PURGE (nicht /S /PURGE)
Gruß
Sekaczek
nicht sorry, eher danke...
war mir eben nicht ganz sicher
Grüsse
Zitat von @Sekaczek:
>
> Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter
"/A"
> versehen, keine neu eingefügten Dateien gesichert.
Es könnte eventuell ein der von mir zuvor angesprochenen Probleme mit Archivbits sein. Am besten mit /A oder /M nicht
arbeiten, sondern einfach anhand der Timestamps synchronisieren.
Auf welche weise hast Du die neuen Dateien eingefügt?
>
> Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter
"/A"
> versehen, keine neu eingefügten Dateien gesichert.
Es könnte eventuell ein der von mir zuvor angesprochenen Probleme mit Archivbits sein. Am besten mit /A oder /M nicht
arbeiten, sondern einfach anhand der Timestamps synchronisieren.
Auf welche weise hast Du die neuen Dateien eingefügt?
eine vorhandene Textdatei eines anderes Verzeichnisses mit copy & paste eingefügt.
Guten Morgen Sekaczek,
vielen Dank für die ausführliche und verständliche "Fortsetzung"! Ich denke, ich werde dann doch nur Vollbackups durchführen.
Grüße
Uli
vielen Dank für die ausführliche und verständliche "Fortsetzung"! Ich denke, ich werde dann doch nur Vollbackups durchführen.
Grüße
Uli
Zitat von @Barney:
> Zitat von @Sekaczek:
> >
> > Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter
> "/A"
> > versehen, keine neu eingefügten Dateien gesichert.
>
> Es könnte eventuell ein der von mir zuvor angesprochenen Probleme mit Archivbits sein. Am besten mit /A oder /M nicht
> arbeiten, sondern einfach anhand der Timestamps synchronisieren.
>
> Auf welche weise hast Du die neuen Dateien eingefügt?
>
eine vorhandene Textdatei eines anderes Verzeichnisses mit copy & paste eingefügt.
> Zitat von @Sekaczek:
> >
> > Das hat leider nicht geklappt. Das Vollbackup natürlich, dann aber hat das Skript, wieder mit dem Schalter
> "/A"
> > versehen, keine neu eingefügten Dateien gesichert.
>
> Es könnte eventuell ein der von mir zuvor angesprochenen Probleme mit Archivbits sein. Am besten mit /A oder /M nicht
> arbeiten, sondern einfach anhand der Timestamps synchronisieren.
>
> Auf welche weise hast Du die neuen Dateien eingefügt?
>
eine vorhandene Textdatei eines anderes Verzeichnisses mit copy & paste eingefügt.
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
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
Zitat von @Sekaczek:
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
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
Ich verwende ein NAS auf dem Linux läuft (Conceptronic CH3SNAS). So wie es aussieht, ist für keine der Dateien auf dem NAS das Archivbit gesetzt.
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
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
es gibt noch viel zu lernen ^^
Ich habe wie unter <url>http://de.wikipedia.org/wiki/Archivbit</url> beschrieben die Datei smb.conf
geändert. Das wird aber nicht alles erforderliche gewesen sein, oder? Nach einem Neustart des NAS ist das Archivbit bei einer "neuen" Datei immer noch nicht gesetzt.
Da ich mich hier auf absolut neuem Gebiet bewege, bitte ich um ein wenig Nachsicht
Grüße
Uli
Ich habe wie unter <url>http://de.wikipedia.org/wiki/Archivbit</url> beschrieben die Datei smb.conf
map archive = yes
map system = yes
map hidden = yes geändert. Das wird aber nicht alles erforderliche gewesen sein, oder? Nach einem Neustart des NAS ist das Archivbit bei einer "neuen" Datei immer noch nicht gesetzt.
Da ich mich hier auf absolut neuem Gebiet bewege, bitte ich um ein wenig Nachsicht
Grüße
Uli
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.
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 Sekaczek,
herzichen Dank für deine Unterstützung - das Backup klappt nun so wie ich es mir wünsche.
Ich habe in der smb.conf das Archivbit aktiviert
Nach einem kompletten backup setze ich die archivbits zurück und führe dann nur noch ein diffbackup (/A) durch. Alles wird in gesonderten Verzeichnissen (Datum, Uhrzeit) gespeichert, sodass ich das hübsch der Reihe nach zurückspielen könnte.
Grüße
Uli
herzichen Dank für deine Unterstützung - das Backup klappt nun so wie ich es mir wünsche.
Ich habe in der smb.conf das Archivbit aktiviert
map archive = yesNach einem kompletten backup setze ich die archivbits zurück und führe dann nur noch ein diffbackup (/A) durch. Alles wird in gesonderten Verzeichnissen (Datum, Uhrzeit) gespeichert, sodass ich das hübsch der Reihe nach zurückspielen könnte.
:: -------------------------------- Variablen setzen diffbackup ---------------------------------
setlocal
set "datum=%date:~-4%%date:~-7,2%%date:~-10,2%"
set "zeit=%time:~0,2%%time:~3,2%%time:~6,2%"
set "zeit=0%zeit: =%"
set "zeit=%zeit:~-6%"
set quelle=\\NAS\Volume_1\Daten
set ziel=X:\backup\nas\diff\"%datum%"\"%zeit%"_daten Grüße
Uli
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
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
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 Sekaczek,
sorry, dass ich mich bislang nicht gemeldet habe - hatte und habe noch meinen Kampf mit dem NAS (CH3SNAS) und Samba
zu 1)
Das hängt wohl mit dem Neustart des NAS zusammen. Mit diesem wird die ursprüngliche smb.conf wieder ins flash geschrieben, in welcher "map archive = no" gesetzt ist. Dies habe ich auch erst nach einem Neustart heute bemerkt.
Wenn ich jetzt die smb.conf auf dem NAS wieder auf "map archive = yes" ändere, sind die archiv-bits gesetzt. Sie bleiben es aber auch, wenn ich den Haken über die Dateieigenschaften bzw. mit "attrib -A /D /S" entferne. Somit klappt dann leider auch mein DiffBackup nicht.
Hängt das mit dem fehlenden Neustart des Samba zusammen? Wenn ja, eine mögliche Lösung die ich hier: http://wolf-u.li/2346/ubuntu-810-und-das-conceptronic-ch3snas-bzw-d-lin ... gefunden habe, bekomme ich nicht zum laufen
zu 2)
kann ich erst richtig beantworten, wenn ich die archivebits überhaupt wieder gelöscht bekomme.
zu 3)
Wenn alles läuft, will ich zumindest zwei Platten wechselseitig einsetzen.
Danke und Grüße
Uli
[edit]
den Samba habe ich zwischenzeitlich auch ohne Neustart des NAS hinbekommen ;) Damit bleibt auch meine smb.conf
erhalten. Nur ist dadurch mein altes Problem nicht gelöst. Archibits sind und bleiben gesetzt - egal was ich mache.
[/edit]
sorry, dass ich mich bislang nicht gemeldet habe - hatte und habe noch meinen Kampf mit dem NAS (CH3SNAS) und Samba
zu 1)
Das hängt wohl mit dem Neustart des NAS zusammen. Mit diesem wird die ursprüngliche smb.conf wieder ins flash geschrieben, in welcher "map archive = no" gesetzt ist. Dies habe ich auch erst nach einem Neustart heute bemerkt.
Wenn ich jetzt die smb.conf auf dem NAS wieder auf "map archive = yes" ändere, sind die archiv-bits gesetzt. Sie bleiben es aber auch, wenn ich den Haken über die Dateieigenschaften bzw. mit "attrib -A /D /S" entferne. Somit klappt dann leider auch mein DiffBackup nicht.
Hängt das mit dem fehlenden Neustart des Samba zusammen? Wenn ja, eine mögliche Lösung die ich hier: http://wolf-u.li/2346/ubuntu-810-und-das-conceptronic-ch3snas-bzw-d-lin ... gefunden habe, bekomme ich nicht zum laufen
zu 2)
kann ich erst richtig beantworten, wenn ich die archivebits überhaupt wieder gelöscht bekomme.
zu 3)
Wenn alles läuft, will ich zumindest zwei Platten wechselseitig einsetzen.
Danke und Grüße
Uli
[edit]
den Samba habe ich zwischenzeitlich auch ohne Neustart des NAS hinbekommen ;) Damit bleibt auch meine smb.conf
[ Volume_1 ]
comment =
path = /mnt/HD_a2
valid users =
read only = no
guest ok = yes
oplocks = no
map archive = yeserhalten. Nur ist dadurch mein altes Problem nicht gelöst. Archibits sind und bleiben gesetzt - egal was ich mache.
[/edit]
Zitat von @Barney:
sorry, dass ich mich bislang nicht gemeldet habe - hatte und habe noch meinen Kampf mit dem NAS (CH3SNAS) und Samba
Hallo Ulisorry, dass ich mich bislang nicht gemeldet habe - hatte und habe noch meinen Kampf mit dem NAS (CH3SNAS) und Samba
hatte in letzter Zeit auch viel zu tun und habe leider immer noch fast keine Zeit
Das hängt wohl mit dem Neustart des NAS zusammen. Mit diesem wird die ursprüngliche smb.conf wieder ins flash
geschrieben, in welcher "map archive = no" gesetzt ist. Dies habe ich auch erst nach einem Neustart heute bemerkt.
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 geschrieben, in welcher "map archive = no" gesetzt ist. Dies habe ich auch erst nach einem Neustart heute bemerkt.
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.
Wenn ich jetzt die smb.conf auf dem NAS wieder auf "map archive = yes" ändere, sind die archiv-bits gesetzt. Sie
bleiben es aber auch, wenn ich den Haken über die Dateieigenschaften bzw. mit "attrib -A /D /S" entferne.
bleiben es aber auch, wenn ich den Haken über die Dateieigenschaften bzw. mit "attrib -A /D /S" entferne.
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.
Wenn alles läuft, will ich zumindest zwei Platten wechselseitig einsetzen.
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.
den Samba habe ich zwischenzeitlich auch ohne Neustart des NAS hinbekommen ;) Damit bleibt auch meine smb.conf
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
wie läuft's? Funktioniert's jetzt? Oder hast Du es aufgegeben?
Gruß
Sekaczek
Hallo Sekaczek,
ich bin aktuell anderweitig ziemlich eingespannt. Bald kommt Urlaub und dann werde ich mich wieder dran machen. Ich melde mich hier auf jeden Fall!
Grüße
Uli
ich bin aktuell anderweitig ziemlich eingespannt. Bald kommt Urlaub und dann werde ich mich wieder dran machen. Ich melde mich hier auf jeden Fall!
Grüße
Uli
