Robocopy Multithreading
Hi,
mir ist soeben aufgefallen:
Windows Server 2008 R2
Ein Ordner eines lokales Laufwerks mit vielen Ordnern (> 4 Millionen) und viele kleine Dateien (ca. 600.000) soll auf ein anderes lokales Laufwerk kopiert werden.
Der Server muss rund um die Uhr in Betrieb bleiben. Die Umschaltung der Software auf das neue Laufwerk kann nur in einem eingekündigten Wartungsfenster erfolgen.
Die Idee:
Die Differenz-Kopien dieses Ordnern dauern 8-9 Stunden(!), obwohl sich dort nur ca. 100 Dateien ändern. Das sind dann ein paar Megabyte.
Das Gros der Zeit geht wahrscheinlich beim Suchen nach den Änderungen drauf.
Diese extrem lange Dauer sprengt das Wartungsfenster, welches wir i.A. dafür bekommen (ca. 2-4 h max.)
Ich habe mit verschiedenen Werten für den /MT -Parameter experimentiert. Keine Änderung.
Und da ist mir aufgefallen:
Ich hatte bisher immer angenommen, dass der /MT Parameter tatsächlich steuert, in wieviel Threads der Prozess die Such- und Kopier-Vorgänge laufen lässt. Defacto ist es aber so, dass - egal was ich einstelle - im Taskmanager für den Robocopy-Prozess angezeigt wird, dass dieser immer nur in 2-3 Threads läuft.
Wo ist mein Denkfehler?
Bsp. für Kommando:
Randinformationen:
AV-Scanner deaktiviert
Quell- und Ziel-LUN liegen auf einem SAN, welches mit 4-GB-FC angeschlossen ist.
SAN langweilt sich. Quell- und Ziel-LUNs liegen auf verschiedenen RAIDs. Antwortzeiten <5 ms. IOpS bei max. 1000. Das SAN kann aber > 10.000 je Controller und Aggregat (RAID).
E.
mir ist soeben aufgefallen:
Windows Server 2008 R2
Ein Ordner eines lokales Laufwerks mit vielen Ordnern (> 4 Millionen) und viele kleine Dateien (ca. 600.000) soll auf ein anderes lokales Laufwerk kopiert werden.
Der Server muss rund um die Uhr in Betrieb bleiben. Die Umschaltung der Software auf das neue Laufwerk kann nur in einem eingekündigten Wartungsfenster erfolgen.
Die Idee:
- Initial-Kopie erstellen mit Robocopy
- anschließend wiederkehrend Differenz-Kopien erstellen, ebenfalls mit Robocopy
- zur Wartung die Software aus
- letzte Differenz-Kopie
- Software auf neues Ziel anpassen
Die Differenz-Kopien dieses Ordnern dauern 8-9 Stunden(!), obwohl sich dort nur ca. 100 Dateien ändern. Das sind dann ein paar Megabyte.
Das Gros der Zeit geht wahrscheinlich beim Suchen nach den Änderungen drauf.
Diese extrem lange Dauer sprengt das Wartungsfenster, welches wir i.A. dafür bekommen (ca. 2-4 h max.)
Ich habe mit verschiedenen Werten für den /MT -Parameter experimentiert. Keine Änderung.
Und da ist mir aufgefallen:
Ich hatte bisher immer angenommen, dass der /MT Parameter tatsächlich steuert, in wieviel Threads der Prozess die Such- und Kopier-Vorgänge laufen lässt. Defacto ist es aber so, dass - egal was ich einstelle - im Taskmanager für den Robocopy-Prozess angezeigt wird, dass dieser immer nur in 2-3 Threads läuft.
Wo ist mein Denkfehler?
Bsp. für Kommando:
robocopy D:\Quelle\3 F:\Ziel\3 /MIR /B /COPY:DAT /R:0 /W:0 /NP /MT:64 /NFL /NDL /LOG:E:\Robocopy\Logs\%date%\Robocopy_Diff_D_Quelle_3_%date%.log
Randinformationen:
AV-Scanner deaktiviert
Quell- und Ziel-LUN liegen auf einem SAN, welches mit 4-GB-FC angeschlossen ist.
SAN langweilt sich. Quell- und Ziel-LUNs liegen auf verschiedenen RAIDs. Antwortzeiten <5 ms. IOpS bei max. 1000. Das SAN kann aber > 10.000 je Controller und Aggregat (RAID).
E.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 558022
Url: https://administrator.de/contentid/558022
Ausgedruckt am: 14.11.2024 um 11:11 Uhr
22 Kommentare
Neuester Kommentar
Moin,
Mit Robocopy kannst Du das vergessen.
Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.
Tools wie Robocopy oder rsync brauchen zu lange um jede einzelne Datei anzuschauen, selbst wenn sie nicht kopiert wird. Das Problem sind die Filesystemstrukturen von NTFS.
lks
Mit Robocopy kannst Du das vergessen.
Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.
Tools wie Robocopy oder rsync brauchen zu lange um jede einzelne Datei anzuschauen, selbst wenn sie nicht kopiert wird. Das Problem sind die Filesystemstrukturen von NTFS.
lks
Hi
ich denke nicht das man hier mit Robocopy weit kommt. Das muss ja immer alle Ordner und Dateien angucken.
Wenn es LUNs sind, warum hängst du sie nicht einfach um?
Wenn das keine Option ist, würde ich hier vielleicht probieren einen Filesystemwatcher zu starten und einfach alles was auf dem Original geschrieben wird auch auf B kopieren.
Evtl. könnte man ja mit Windows Replication arbeiten, also das ganze per DFSR erledigen lassen. Aber ich habe keine Ahnung wie das mit solchen Mengen an Ordnern zurecht kommt.
ich denke nicht das man hier mit Robocopy weit kommt. Das muss ja immer alle Ordner und Dateien angucken.
Wenn es LUNs sind, warum hängst du sie nicht einfach um?
Wenn das keine Option ist, würde ich hier vielleicht probieren einen Filesystemwatcher zu starten und einfach alles was auf dem Original geschrieben wird auch auf B kopieren.
Evtl. könnte man ja mit Windows Replication arbeiten, also das ganze per DFSR erledigen lassen. Aber ich habe keine Ahnung wie das mit solchen Mengen an Ordnern zurecht kommt.
'n Abend emeriks,
Meines Wissens nach ist dr parameter /MT abhängig von der Anzahl der Cores.
Ausserdem hast Du mal mit den Parameter /ZB bzw. /Z oder /B versucht?
Welche Robocopy Version wird verwendet?
Es gab eine Robocopy Version, welche mit einer GUI ausgeliefert wurde, welche fehlerhaft war.
Der Differential Copy sollte nicht so lange dauern. Ich habe 2010 einen Fileserver mit der damaligen Robocopy Version von W2K3 R2 migriert.
Der initial Copy dauerte lange, dafür war der Differential Copy recht fix.
Gruss Penny.
Zitat von @emeriks:
Die Idee:
Die Differenz-Kopien dieses Ordnern dauern 8-9 Stunden(!), obwohl sich dort nur ca. 100 Dateien ändern. Das sind dann ein paar Megabyte.
Das Gros der Zeit geht wahrscheinlich beim Suchen nach den Änderungen drauf.
Diese extrem lange Dauer sprengt das Wartungsfenster, welches wir i.A. dafür bekommen (ca. 2-4 h max.)
Ich habe mit verschiedenen Werten für den /MT -Parameter experimentiert. Keine Änderung.
Und da ist mir aufgefallen:
Ich hatte bisher immer angenommen, dass der /MT Parameter tatsächlich steuert, in wieviel Threads der Prozess die Such- und Kopier-Vorgänge laufen lässt. Defacto ist es aber so, dass - egal was ich einstelle - im Taskmanager für den Robocopy-Prozess angezeigt wird, dass dieser immer nur in 2-3 Threads läuft.
Wo ist mein Denkfehler?
Bsp. für Kommando:
Wieviel Merne hat der Rechner auf dem Robocopy ausgeführt wird?Die Idee:
- Initial-Kopie erstellen mit Robocopy
- anschließend wiederkehrend Differenz-Kopien erstellen, ebenfalls mit Robocopy
- zur Wartung die Software aus
- letzte Differenz-Kopie
- Software auf neues Ziel anpassen
Die Differenz-Kopien dieses Ordnern dauern 8-9 Stunden(!), obwohl sich dort nur ca. 100 Dateien ändern. Das sind dann ein paar Megabyte.
Das Gros der Zeit geht wahrscheinlich beim Suchen nach den Änderungen drauf.
Diese extrem lange Dauer sprengt das Wartungsfenster, welches wir i.A. dafür bekommen (ca. 2-4 h max.)
Ich habe mit verschiedenen Werten für den /MT -Parameter experimentiert. Keine Änderung.
Und da ist mir aufgefallen:
Ich hatte bisher immer angenommen, dass der /MT Parameter tatsächlich steuert, in wieviel Threads der Prozess die Such- und Kopier-Vorgänge laufen lässt. Defacto ist es aber so, dass - egal was ich einstelle - im Taskmanager für den Robocopy-Prozess angezeigt wird, dass dieser immer nur in 2-3 Threads läuft.
Wo ist mein Denkfehler?
Bsp. für Kommando:
> robocopy D:\Quelle\3 F:\Ziel\3 /MIR /B /COPY:DAT /R:0 /W:0 /NP /MT:64 /NFL /NDL /LOG:E:\Robocopy\Logs\%date%\Robocopy_Diff_D_Quelle_3_%date%.log
>
Meines Wissens nach ist dr parameter /MT abhängig von der Anzahl der Cores.
Ausserdem hast Du mal mit den Parameter /ZB bzw. /Z oder /B versucht?
Welche Robocopy Version wird verwendet?
Es gab eine Robocopy Version, welche mit einer GUI ausgeliefert wurde, welche fehlerhaft war.
Der Differential Copy sollte nicht so lange dauern. Ich habe 2010 einen Fileserver mit der damaligen Robocopy Version von W2K3 R2 migriert.
Der initial Copy dauerte lange, dafür war der Differential Copy recht fix.
Gruss Penny.
Moin,
Öffentlicher Dienst?
Ich würde das ganz anders machen:
Ein DFS,das mit dem neuen Server repliziert, einrichten und dreimal hingucken, ob da auch wirklich das richtige primäre Mitglied steht. Dann die erste Replikation abwarten. Das dürfte einige Zeit dauern.
Theoretisch müsstest Du dann sogar ganz ohne großartiges Wartungsfenster auskommen, da ja die Daten im DFS immer synchron sind. Software auf dem alten Server ab- und auf dem neuen anschalten. Fertig.
Oder habe ich einen Denkfehler? Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht.
Liebe Grüße
Erik
Öffentlicher Dienst?
Ich würde das ganz anders machen:
Ein DFS,das mit dem neuen Server repliziert, einrichten und dreimal hingucken, ob da auch wirklich das richtige primäre Mitglied steht. Dann die erste Replikation abwarten. Das dürfte einige Zeit dauern.
Theoretisch müsstest Du dann sogar ganz ohne großartiges Wartungsfenster auskommen, da ja die Daten im DFS immer synchron sind. Software auf dem alten Server ab- und auf dem neuen anschalten. Fertig.
Wo ist mein Denkfehler?
Oder habe ich einen Denkfehler? Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht.
Liebe Grüße
Erik
Zitat von @emeriks:
Aber diese Idee ist nicht mal doof. Wenn schon solch ein langes Fenster, dann könnten wir die LUN auch gleich auf Blockebene 1:1 klonen.
Zitat von @Lochkartenstanzer:
Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.
Das geht nur offline. Und bei 3 TB insgesamt wird das auch 8-9 h dauern. Wenn nicht gar länger.Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.
Aber diese Idee ist nicht mal doof. Wenn schon solch ein langes Fenster, dann könnten wir die LUN auch gleich auf Blockebene 1:1 klonen.
Von welchen Datenmengen reden wir denn überhaupt?
Wenn Du sagst
Quell- und Ziel-LUN liegen auf einem SAN, welches mit 4-GB-FC angeschlossen ist.
SAN langweilt sich. Quell- und Ziel-LUNs liegen auf verschiedenen RAIDs. Antwortzeiten <5 ms. IOpS bei max. 1000. Das SAN kann aber > 10.000 je Controller und Aggregat (RAID).
SAN langweilt sich. Quell- und Ziel-LUNs liegen auf verschiedenen RAIDs. Antwortzeiten <5 ms. IOpS bei max. 1000. Das SAN kann aber > 10.000 je Controller und Aggregat (RAID).
Dann sollte eine Kopie mit ntfsclone, das nur die vom filesystem "benutzen" in sehr kurzer Zeit druch sein.
Bei der obigen Konfiguration würde ich für 4T "Blockdaten" ca 2,5h bis 3h erwarten.
lks
PS: 10.000 IOPS hört sich zwar viel an, aber sehr kleinen Dateien sind das bei 4k Blockgröße "nur" 40MB/s was immer noch mindestens Faktor 10 unter dem theoretisch möglichen Höchstwert liegt.
Zitat von @emeriks:
Zitat von @Lochkartenstanzer:
Von welchen Datenmengen reden wir denn überhaupt?
Von welchen Datenmengen reden wir denn überhaupt?
... Und bei 3 TB insgesamt ....
Ups, habe ich übersehen, obwohl ich es oben sogar selbst zitiert habe.
Also bei Blockkopie etwas weniger als zwei Stunden., wenn man ein intelligentes Imageing-Programm wie ntfsclone nutzt.
lks
Moin,
Jo, das erklärt es unmittelbar.
Nee, Krankenhaus.
Knapp daneben. Ich habe im öffentlichen Dienst letzt noch einen XP-Rechner gesehen. Huh!
Das kenne ich. Wir haben das gleiche Problem mit XEN-Maschinen, die auf einen neuen Server umgezogen werden sollen. Das ist gerade am WE gescheitert. 60 Stunden sollte das dauern. Also nächstes WE am Freitag anfangen und hoffen, dass es bis Sonntag nachmittag durch ist.
Liebe Grüße
Erik
Zitat von @emeriks:
Aber siehe meine anderen Kommentare an @SeaStorm und @Penny.Cilin
Zitat von @erikro:
Ein DFS,das mit dem neuen Server repliziert, ....
Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht.
He, he.Ein DFS,das mit dem neuen Server repliziert, ....
Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht.
Aber siehe meine anderen Kommentare an @SeaStorm und @Penny.Cilin
Jo, das erklärt es unmittelbar.
Windows Server 2008 R2
Öffentlicher Dienst? Knapp daneben. Ich habe im öffentlichen Dienst letzt noch einen XP-Rechner gesehen. Huh!
Der Server wird demnächst ersetzt. Zuvor muss die VM die Hardware wechseln. Im konkreten Fall geht nur eine Replikation der VM über LAN. Aber dafür müssen wir zuerst die RAW-LUN los werden.
Das kenne ich. Wir haben das gleiche Problem mit XEN-Maschinen, die auf einen neuen Server umgezogen werden sollen. Das ist gerade am WE gescheitert. 60 Stunden sollte das dauern. Also nächstes WE am Freitag anfangen und hoffen, dass es bis Sonntag nachmittag durch ist.
Liebe Grüße
Erik
Zitat von @emeriks:
Ich habe jetzt ein altes 32bit-Tool von EMC ausgegraben: EMCopy 4.17
Das arbeitet bei meinem Test tatsächlich in 68 Threads, die CPU-Last des Prozess geht ordentlich hoch.
Mal sehen, wie lange dieses für den Abgleich benötigt.
Du weißt, dapß es EMCopy auch als x64 Version gibt?Ich habe jetzt ein altes 32bit-Tool von EMC ausgegraben: EMCopy 4.17
Das arbeitet bei meinem Test tatsächlich in 68 Threads, die CPU-Last des Prozess geht ordentlich hoch.
Mal sehen, wie lange dieses für den Abgleich benötigt.
Hallo,
bei unserem Backup ist mir aufgefallen, dass das Einlesen bei einem zweiten Durchlauf deutlich schneller geht; ähnlich wie bei Windows die Abfrage von Ordner- oder Laufwerkseigenschaften.
Möglicerweise kannst Du noch etwas Zeit gewinnen, wenn wenn der vorletzte Durchlauf zeitlich nicht zu weit vom finalen Durchlauf entfernt ist.
Gruß
bei unserem Backup ist mir aufgefallen, dass das Einlesen bei einem zweiten Durchlauf deutlich schneller geht; ähnlich wie bei Windows die Abfrage von Ordner- oder Laufwerkseigenschaften.
Möglicerweise kannst Du noch etwas Zeit gewinnen, wenn wenn der vorletzte Durchlauf zeitlich nicht zu weit vom finalen Durchlauf entfernt ist.
Gruß