Hallo zusammen,
Ich nutze schon sehr lange Robocopy zum Erstellen von Backups von Daten und es hat immer wunderbar funktioniert.
Nun habe ich ein Synology NAS und ich wollte meine Daten per Robocopy auf das NAS bringen. Das klappt bei einem Durchgang. Bei einem weiteren Durchgang werden aber Dateien als geändert angesehen, die nicht geändert wurden und daher unnötigerweise doppelt kopiert. Und zwar nicht in Ausnahmefällen, sondern bei allen Dateien, sodass hunderte Gigabyte kopiert werden, obwohl ein Inkrement vielleicht nur 100 Megabyte groß ist.
So, bei den Robocopy Experten klingelt es schon. Aber leider Fehlanzeige, folgende übliche Lösungen haben mir nicht geholfen:
Interessant ist noch, dass im Log immer eine falsche Quelldateizeit eingetragen ist. Manchmal liegt die Zeit um eine, manchmal um zwei Stunden vor der Zeit, die im Eigenschaftenfenster der Datei angezeigt wird.
Noch interessanter ist dann, dass Dateien, die ich jetzt neu erstelle, einwandfrei funktionieren, auch ohne den genannten Switches und auch mit allen Blockgrößen UND obwohl auch hier im Log der Zeitstempel zwei Stunden vor dem liegt, der im Eigenschaftenfenster der Datei angezeigt wird.
Es klingt so dermaßen nach UTC und dann mal +1, mal +2 wegen Zeitzone und Sommer-/Winterzeit. Aber wie gesagt hat mir /dst nicht geholfen und ich habe bei PC und NAS die gleiche Zeitzone eingestellt und den gleichen Zeitsynchronisierungsserver.
Ich würde mich riesig freuen, wenn jemand schauen könnte, was das Log in Durchgang 1 und 2 ausspuckt, wenn er eine alte, mehrere MB große Datei von einer NTFS Platte mit 4096 Bit Blockgröße auf ein SMB Share per Robocopy kopiert.
Diesen Befehl verwende ich:
Dateien sind dann im Quell- und Zielordner gleich (wenn ich mit Eigenschaftsfenster schaue):
alt.zip mit Zeitstempel: 19:14:27
neu-groesser_als_block.txt mit Zeitstempel: 23:18:05
neu-kleiner_als_block.txt mit Zeitstempel: 23:03:35
Im Log hingegen:
Windows 8 Pro 64bit, NTFS Platte mit 4096 Bit Blockgröße, Synology DS413j mit DSM 4.2
Ich habe mir direkt nochmal die Eigenschaftsfenster der Dateien angeschaut und erschreckt folgendes festgestellt:
Das Änderungsdatum liegt VOR dem Erstelldatum.
Die Platten, von denen ich auf das NAS kopiere sind selber Backup Platten. Hier muss ein Robocopy Befehl früher Attribute falsch gesetzt haben.
Also z.B.: Datei erstellt auf PC 1.1., geändert auf PC 2.1., Robocopy gemacht am 3.1., danach: Erstelldatum 3.1., Änderungsdatum 2.1.
Was kann ich nun tun?
/fixtim Switch probieren?
Ich wollte eigentlich so viel wie möglich original belassen, da mir wichtig ist zu wissen wann Fotos erstellt oder bearbeitet wurden auf den PCs damals, von denen ich die Robodopy Backups auf die Platte gemacht habe. Wobei das jetzt mit den verdrehten Daten ja eh nicht mehr hinkommt
. Extrem ärgerlich!
Halt! Nochmal einen Schritt zurück.. es macht scheinbar nichts, wenn das Erstelldatum nach dem Änderungsdatum liegt. Wenn ich die Testdateien erst per Drag & Drop auf das NAS kopiere, ist überall das Erstelldatum der AKTUELLE Zeitstempel. Das Änderungsdatum liegt dann bei allen Dateien davor. Robocopy bemängelt anschließend immer noch nur die oben genannte eine Datei, obwohl ich nun keine Unterschiede feststellen kann.
P.S.: Und ich habe mal einen anderen Ordner probiert mit Dateien, wo das Änderungsdatum nach oder gleich dem Erstelldatum ist - gleiches Problem.
Also sind wir wieder beim Anfang. Nicht geänderte Dateien werden als geändert angesehen, die üblichen Robocopy Switche helfen nicht.
Ich nutze schon sehr lange Robocopy zum Erstellen von Backups von Daten und es hat immer wunderbar funktioniert.
Nun habe ich ein Synology NAS und ich wollte meine Daten per Robocopy auf das NAS bringen. Das klappt bei einem Durchgang. Bei einem weiteren Durchgang werden aber Dateien als geändert angesehen, die nicht geändert wurden und daher unnötigerweise doppelt kopiert. Und zwar nicht in Ausnahmefällen, sondern bei allen Dateien, sodass hunderte Gigabyte kopiert werden, obwohl ein Inkrement vielleicht nur 100 Megabyte groß ist.
So, bei den Robocopy Experten klingelt es schon. Aber leider Fehlanzeige, folgende übliche Lösungen haben mir nicht geholfen:
- /fft (FAT Zeit mit zugelassener 2 Sekunden Ungenauigkeit, weil SMB da wohl nicht so genau ist)
- /dst für Zeitverschiebungsbeachtung (NTFS vs. UNIX Geschichte)
- block size = 4096 in der /usr/syno/etc/smb.conf gesetzt, damit Blocksize gleich ist (normal ist 1024 auf NAS)
Interessant ist noch, dass im Log immer eine falsche Quelldateizeit eingetragen ist. Manchmal liegt die Zeit um eine, manchmal um zwei Stunden vor der Zeit, die im Eigenschaftenfenster der Datei angezeigt wird.
Noch interessanter ist dann, dass Dateien, die ich jetzt neu erstelle, einwandfrei funktionieren, auch ohne den genannten Switches und auch mit allen Blockgrößen UND obwohl auch hier im Log der Zeitstempel zwei Stunden vor dem liegt, der im Eigenschaftenfenster der Datei angezeigt wird.
Es klingt so dermaßen nach UTC und dann mal +1, mal +2 wegen Zeitzone und Sommer-/Winterzeit. Aber wie gesagt hat mir /dst nicht geholfen und ich habe bei PC und NAS die gleiche Zeitzone eingestellt und den gleichen Zeitsynchronisierungsserver.
Ich würde mich riesig freuen, wenn jemand schauen könnte, was das Log in Durchgang 1 und 2 ausspuckt, wenn er eine alte, mehrere MB große Datei von einer NTFS Platte mit 4096 Bit Blockgröße auf ein SMB Share per Robocopy kopiert.
Diesen Befehl verwende ich:
Code:
set s=C:\Beispiel
set t=D:\Beispiel
set log=C:\beispiel.txt
robocopy "%s%" "%t%" /z /copy:DAT /dcopy:T /mir /xd "$RECYCLE.BIN" "System Volume Information" "RECYCLER" /fft /dst /r:10 /w:10 /unilog:"%log%" /v /ts /npDateien sind dann im Quell- und Zielordner gleich (wenn ich mit Eigenschaftsfenster schaue):
alt.zip mit Zeitstempel: 19:14:27
neu-groesser_als_block.txt mit Zeitstempel: 23:18:05
neu-kleiner_als_block.txt mit Zeitstempel: 23:03:35
Im Log hingegen:
Code:
Geändert 1.9 m 2009/05/16 17:14:27 alt.zip
Gleich 5028 2013/05/08 21:18:05 neu-groesser_als_block.txt
Gleich 1 2013/05/08 21:03:35 neu-kleiner_als_block.txtWindows 8 Pro 64bit, NTFS Platte mit 4096 Bit Blockgröße, Synology DS413j mit DSM 4.2
Ergänzung ()
Ich habe mir direkt nochmal die Eigenschaftsfenster der Dateien angeschaut und erschreckt folgendes festgestellt:
Das Änderungsdatum liegt VOR dem Erstelldatum.
Die Platten, von denen ich auf das NAS kopiere sind selber Backup Platten. Hier muss ein Robocopy Befehl früher Attribute falsch gesetzt haben.
Also z.B.: Datei erstellt auf PC 1.1., geändert auf PC 2.1., Robocopy gemacht am 3.1., danach: Erstelldatum 3.1., Änderungsdatum 2.1.
Was kann ich nun tun?
/fixtim Switch probieren?
Ich wollte eigentlich so viel wie möglich original belassen, da mir wichtig ist zu wissen wann Fotos erstellt oder bearbeitet wurden auf den PCs damals, von denen ich die Robodopy Backups auf die Platte gemacht habe. Wobei das jetzt mit den verdrehten Daten ja eh nicht mehr hinkommt
. Extrem ärgerlich!
Ergänzung ()
Halt! Nochmal einen Schritt zurück.. es macht scheinbar nichts, wenn das Erstelldatum nach dem Änderungsdatum liegt. Wenn ich die Testdateien erst per Drag & Drop auf das NAS kopiere, ist überall das Erstelldatum der AKTUELLE Zeitstempel. Das Änderungsdatum liegt dann bei allen Dateien davor. Robocopy bemängelt anschließend immer noch nur die oben genannte eine Datei, obwohl ich nun keine Unterschiede feststellen kann.
Ergänzung ()
P.S.: Und ich habe mal einen anderen Ordner probiert mit Dateien, wo das Änderungsdatum nach oder gleich dem Erstelldatum ist - gleiches Problem.
Also sind wir wieder beim Anfang. Nicht geänderte Dateien werden als geändert angesehen, die üblichen Robocopy Switche helfen nicht.
Zuletzt bearbeitet:
- aber es muss doch auch normal möglich sein. Mein Problem muss doch einen Grund haben, der sich finden und beheben lässt. Da bin ich zu neugierig für einen Workaround, der mir auch noch meine Datensicherheitspläne durchkreuzt 
T) oder eine alte Robocopy Version verwenden, was es zu Server 2003 Zeiten noch als einzelnes Tool zum downloaden gab. Aber das erscheint mir auch seltsam, weil wie ich geschrieben habe unangetastete Dateien ja durchaus als gleich angesehen werden.