Robocopy spiegelt nicht korrekt
Hallo,
ich benutzte Robocopy um die Daten von einem Filerserver nachts auf einen zweiten Fileserver zu übertragen.
Ich hab den Befehl als *.cmd Datei erstellt und rufe das ganze als Taks nachts auf.
Der Befehl sieht so aus:
robocopy d: \192.168.0.80data.backup.Mo-Mi-Fr /MIR /XD d:SQL-Datenbank /Log:robo-log.txt
Das ganze läuft auch ohen Probleme, beim zweiten Lauf kommt aber dann das Problem.
Anstatt nur die Daten abzugleichen die sich geändert habe. Kopiert Robocopy fast alles Daten aus dem Quelverzeichniss noch mal auf das Ziel Verzeichnis.
Hier mal ein Auszug aus dem Logfile:
...
Older 574434 WL00002059.POM
Older 673338 WL00002059.SZN
Newer 1.2 m WL00002060.POM
Newer 946101 WL00002061.ANS
Older 1950 WL00002061.POM
Older 1.9 m WL00002061.SZN
Newer 1.0 m WL00002062.ANS
Newer 1950 WL00002062.POM
Older 3.2 m WL00002062.SZN
Older 287440 WL00002064.ANS
Newer 1950 WL00002064.POM
Newer 31726 WL00002064.SZN
Older 287608 WL00002069.ANS
Older 1950 WL00002069.POM
Older 34094 WL00002069.SZN
Newer 599434 WL00002073.ANS
...
Total------Copied--------Skipped--------Mismatch---------FAILED--------Extras
Dirs :------1170------------0------------1170------------------0----------------0---------------0
Files :-----0819------15601----------15218------------------0----------------0---------------0
Bytes :37.564 g--29.590 g---------7.973 g-----------------0----------------0---------------0
Times :-1:07:12----1:06:19---------------------------------------------0:00:00------0:00:53
Speed :7985092 Bytes/sec.
Speed :456.910 MegaBytes/min.
Ended : Wed Aug 15 14:04:28 2007
Das ganze würde mich ja nicht stören, da die Übertragung ja läuft und auch innerhalb der Zeit in der so und so niemand das Netz braucht abgeschlossen ist.
Das Problem ist, dass dieser zweite Fileserver an einen externen Standort verlegt werden soll und der Abgleich über einen VPN-Tunnel erfolgen soll, und dafür sind es dann doch zuviele Daten.
Hat jemand eine Idee woher das Problem kommt und wie es abgestellt werden kann?
Mfg Huhjukel
ich benutzte Robocopy um die Daten von einem Filerserver nachts auf einen zweiten Fileserver zu übertragen.
Ich hab den Befehl als *.cmd Datei erstellt und rufe das ganze als Taks nachts auf.
Der Befehl sieht so aus:
robocopy d: \192.168.0.80data.backup.Mo-Mi-Fr /MIR /XD d:SQL-Datenbank /Log:robo-log.txt
Das ganze läuft auch ohen Probleme, beim zweiten Lauf kommt aber dann das Problem.
Anstatt nur die Daten abzugleichen die sich geändert habe. Kopiert Robocopy fast alles Daten aus dem Quelverzeichniss noch mal auf das Ziel Verzeichnis.
Hier mal ein Auszug aus dem Logfile:
...
Older 574434 WL00002059.POM
Older 673338 WL00002059.SZN
Newer 1.2 m WL00002060.POM
Newer 946101 WL00002061.ANS
Older 1950 WL00002061.POM
Older 1.9 m WL00002061.SZN
Newer 1.0 m WL00002062.ANS
Newer 1950 WL00002062.POM
Older 3.2 m WL00002062.SZN
Older 287440 WL00002064.ANS
Newer 1950 WL00002064.POM
Newer 31726 WL00002064.SZN
Older 287608 WL00002069.ANS
Older 1950 WL00002069.POM
Older 34094 WL00002069.SZN
Newer 599434 WL00002073.ANS
...
Total------Copied--------Skipped--------Mismatch---------FAILED--------Extras
Dirs :------1170------------0------------1170------------------0----------------0---------------0
Files :-----0819------15601----------15218------------------0----------------0---------------0
Bytes :37.564 g--29.590 g---------7.973 g-----------------0----------------0---------------0
Times :-1:07:12----1:06:19---------------------------------------------0:00:00------0:00:53
Speed :7985092 Bytes/sec.
Speed :456.910 MegaBytes/min.
Ended : Wed Aug 15 14:04:28 2007
Das ganze würde mich ja nicht stören, da die Übertragung ja läuft und auch innerhalb der Zeit in der so und so niemand das Netz braucht abgeschlossen ist.
Das Problem ist, dass dieser zweite Fileserver an einen externen Standort verlegt werden soll und der Abgleich über einen VPN-Tunnel erfolgen soll, und dafür sind es dann doch zuviele Daten.
Hat jemand eine Idee woher das Problem kommt und wie es abgestellt werden kann?
Mfg Huhjukel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 66416
Url: https://administrator.de/contentid/66416
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
6 Kommentare
Neuester Kommentar
Meine Vermutung geht einfach in die Richtung, dass robocopy mit dem Timestamps durcheinander kommt. Das ist allerdings nur eine Vermutung, an der ich zuerst arbeiten würde.
Zum Vergleich können man ja mal versuchen, die Daten lokal auf einen anderen Pfad der Festplatte zu spiegeln. So würde ich mich da rantasten.
Zum Vergleich können man ja mal versuchen, die Daten lokal auf einen anderen Pfad der Festplatte zu spiegeln. So würde ich mich da rantasten.
Moin Huhjukel,
ich denke, Dynadrate liegt genau richtig mit "robocopy kommt mit den Timestamps durcheinander".
Das Problem wird sein, dass die "Zeiten" auf Windowsrechnern bei den Sekunden in 2-Sek-Schritten gespeichert werden, unter *nix aber in 1-Sekunden-Schritten.
Dafür gibt es auch einen Workaround: Lies mal bei RoboCopy die Hilfe zu dem Parameter /FFT:
Grüße
Biber
ich denke, Dynadrate liegt genau richtig mit "robocopy kommt mit den Timestamps durcheinander".
Das Problem wird sein, dass die "Zeiten" auf Windowsrechnern bei den Sekunden in 2-Sek-Schritten gespeichert werden, unter *nix aber in 1-Sekunden-Schritten.
Dafür gibt es auch einen Workaround: Lies mal bei RoboCopy die Hilfe zu dem Parameter /FFT:
Assume FAT File Times (2-second granularity). Useful for copying to third-party systems that declare a volume to be NTFS but only implement file times with a 2-second granularity.
Grüße
Biber
Moin Huhjukel,
das ist ja jetzt mehr ein Ratespiel....aber weil ich ja früher auch gerne M$-Betriebssysteme gepimpt habe:
Die Windows-Dateiattribute sind so....na, ich sag mal fehlertolerant, dass Du denen auch z.B. einen Sekunden-Wert von 62 Sekunden verpassen kannst.
Habe sowohl ich wie auch einige Utilities gerne gemacht, um Datei zu kennzeichnen bzw. schnell auf Originalzustand zu prüfen.
Falls Du gar nichts Auffälliges bei dieser Datei feststellst, verpass ihr doch mit einem beliebigen"Touch"-Utility einen neuen Timestamp (meinetwegen wieder den 13.3.2004 00:00) und versuche es dann noch mal.
Grüße
Biber
P.S. Ach, blödes Rumgeeiere...das ist nicht fehlertolerant, sondern einfach Shice programmiert...
das ist ja jetzt mehr ein Ratespiel....aber weil ich ja früher auch gerne M$-Betriebssysteme gepimpt habe:
Die Windows-Dateiattribute sind so....na, ich sag mal fehlertolerant, dass Du denen auch z.B. einen Sekunden-Wert von 62 Sekunden verpassen kannst.
Habe sowohl ich wie auch einige Utilities gerne gemacht, um Datei zu kennzeichnen bzw. schnell auf Originalzustand zu prüfen.
Falls Du gar nichts Auffälliges bei dieser Datei feststellst, verpass ihr doch mit einem beliebigen"Touch"-Utility einen neuen Timestamp (meinetwegen wieder den 13.3.2004 00:00) und versuche es dann noch mal.
Grüße
Biber
P.S. Ach, blödes Rumgeeiere...das ist nicht fehlertolerant, sondern einfach Shice programmiert...