barney
Goto Top

Robocopy - diffrentielles Backup

Hallo,

nach kleineren Anfangsschwiergkeiten habe ich das Backup vom Laptop auf eine externe Festplatte hinbekommen face-smile

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

pause

Lasse ich den Schalter "/A" weg, kopiert er alle Daten.

Irgendwo habe ich wohl einen Denkfehler, oder? ;)

Danke und Grüße
Uli

Content-ID: 165442

Url: https://administrator.de/forum/robocopy-diffrentielles-backup-165442.html

Ausgedruckt am: 23.12.2024 um 12:12 Uhr

90776
90776 30.04.2011 um 16:21:32 Uhr
Goto Top
Hi Uli

als erstes fällt mir das auf:

if exist desktop.ini attrib -H -R desktop.ini
if exist desktop.ini del desktop.ini
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
robocopy "%quelle%" "%Ziel%" /mir  
laufen, dann macht er beim ersten Mal ein Vollbackup und danach synchronisiert er die Dateien einfach

Grüsse
Switcher
Sekaczek
Sekaczek 30.04.2011 um 16:31:14 Uhr
Goto Top
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
Barney
Barney 30.04.2011 um 16:34:23 Uhr
Goto Top
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
Barney
Barney 30.04.2011 um 16:40:08 Uhr
Goto Top
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
Barney
Barney 30.04.2011 um 16:45:34 Uhr
Goto Top
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  
> 
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.
90776
90776 30.04.2011 um 16:59:24 Uhr
Goto Top
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
60730
60730 30.04.2011 um 17:01:26 Uhr
Goto Top
moin,

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

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

Gruß
Barney
Barney 30.04.2011 um 17:31:27 Uhr
Goto Top
Bei mir klappt bei der Sicherung der Laptop-Verzeichnisse auch alles. Ich habe "nur" die Probleme bei der Sicherung des NAS. face-sad
90776
90776 30.04.2011 um 18:03:48 Uhr
Goto Top
Versuch mal genau meinen Befehl zu benutzen
Sekaczek
Sekaczek 30.04.2011 um 18:09:37 Uhr
Goto Top
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
Sekaczek
Sekaczek 30.04.2011 um 18:26:32 Uhr
Goto Top
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
>
> > robocopy "%quelle%" "%Ziel%" /mir  
> > 
> 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.

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
Sekaczek
Sekaczek 30.04.2011 um 18:31:24 Uhr
Goto Top
Zitat von @90776:
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
90776
90776 30.04.2011 um 19:13:10 Uhr
Goto Top
Zitat von @Sekaczek:
Sorry. kleine Korrektur /MIR = /E /PURGE (nicht /S /PURGE)

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

Grüsse
Barney
Barney 01.05.2011 um 07:38:29 Uhr
Goto Top
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.
Barney
Barney 01.05.2011 um 07:42:21 Uhr
Goto Top
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
Sekaczek
Sekaczek 01.05.2011 um 09:28:16 Uhr
Goto Top
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.

Dann sollte Archivbit eigentlich gesetzt sein.

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

Gruß
Sekaczek
Sekaczek
Sekaczek 01.05.2011 um 09:45:47 Uhr
Goto Top
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
Barney
Barney 01.05.2011 um 10:12:23 Uhr
Goto Top
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

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.
Sekaczek
Sekaczek 01.05.2011 um 11:02:19 Uhr
Goto Top
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
Barney
Barney 01.05.2011 um 14:25:35 Uhr
Goto Top
es gibt noch viel zu lernen ^^

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 face-wink

Grüße
Uli
Sekaczek
Sekaczek 01.05.2011 um 17:45:37 Uhr
Goto Top
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 face-wink

Gruß
Sekaczek

PS
Gib mir Bescheid, wenn es funktioniert.
Barney
Barney 06.05.2011 um 11:03:53 Uhr
Goto Top
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

map archive = yes

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.

::        -------------------------------- 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
Sekaczek
Sekaczek 08.05.2011 um 19:01:57 Uhr
Goto Top
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
Sekaczek
Sekaczek 13.05.2011 um 18:25:01 Uhr
Goto Top
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
Barney
Barney 14.05.2011 um 10:02:06 Uhr
Goto Top
Hallo Sekaczek,

sorry, dass ich mich bislang nicht gemeldet habe - hatte und habe noch meinen Kampf mit dem NAS (CH3SNAS) und Samba face-sad

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 face-sad

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 = yes

erhalten. Nur ist dadurch mein altes Problem nicht gelöst. Archibits sind und bleiben gesetzt - egal was ich mache.
[/edit]
Sekaczek
Sekaczek 18.05.2011 um 17:25:02 Uhr
Goto Top
Zitat von @Barney:
sorry, dass ich mich bislang nicht gemeldet habe - hatte und habe noch meinen Kampf mit dem NAS (CH3SNAS) und Samba face-sad
Hallo Uli
hatte in letzter Zeit auch viel zu tun und habe leider immer noch fast keine Zeit face-sad

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 face-sad

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.

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 face-wink
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 face-wink
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 ]
Sekaczek
Sekaczek 10.06.2011 um 15:56:23 Uhr
Goto Top
Hallo Uli (Barney),

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

Gruß
Sekaczek
Barney
Barney 20.06.2011 um 11:45:21 Uhr
Goto Top
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