22
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%.logRandinformationen:
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.
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: 558022
Url: https://administrator.de/forum/robocopy-multithreading-558022.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
22 Kommentare
Neuester Kommentar
vielleicht die Kombination der Optionen... lt Robocopy Optionsliste bietet sich da /A-:A an was das Archiv-Flag an der Quelle zurücksetzt, dann würde /B auch Sinn machen. Eventuell überstimmt das /MIR das dann.
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 @GrueneSosseMitSpeck:
/A-:A an was das Archiv-Flag an der Quelle zurücksetzt,
dann würde /B auch Sinn machen.
/B ist dabei. Oder meinst Du das in Kombination mit /A ? Falls ja, wo soll da ein Zusammenhang bestehen?/A-:A an was das Archiv-Flag an der Quelle zurücksetzt,
dann würde /B auch Sinn machen.
/A bedeutet ja nicht, dass er nicht auch das Ziel überprüft, was er löschen muss, wegen /MIR.
Zitat von @SeaStorm:
ich denke nicht das man hier mit Robocopy weit kommt. Das muss ja immer alle Ordner und Dateien angucken.
Ja, darum geht es ja.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?
Ich kann die LUN nicht umhängen, weil wir aus einer RAW-LUN unter VMware eine VMDK machen müssen.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.
Das habe ich sogar flugs programmiert. Nur fliegt das selbst als x64-Programm immer wieder um die Ohren. Ich vermute, wegen der immensen Struktur.Evtl. könnte man ja mit Windows Replication arbeiten, also das ganze per DFSR erledigen lassen.
Jain. Da war ich auch schon.Erstmal ist es eine Kopie auf dem selben Server. DFS-R geht bloß zwischen Servern. Aber ich könnte die neue LUN (VMDK) temporär an eine andere VM hängen. Allerdings fürchte ich, würde DFS-R bei dieser großen Ordneranzahl ne Ewigkeit brauchen, um überhaupt erstmal die Erstsynchronisation fertig zu bekommen.
Zitat von @Penny.Cilin:
Wieviel Merne hat der Rechner auf dem Robocopy ausgeführt wird?
Meines Wissens nach ist dr parameter /MT abhängig von der Anzahl der Cores.
VMware VM mit 6 vCPU und 24 GB RAMWieviel Merne hat der Rechner auf dem Robocopy ausgeführt wird?
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?
Was würde /Z hier ändern?Und ja, /B nutze ich bereits.
Welche Robocopy Version wird verwendet?
Original-Version vom Windows Server 2008 R2Das verrät /? nicht.
Laut Dateieigenschaften: 5.1.10.1027, vom 21.11.2010
Es gab eine Robocopy Version, welche mit einer GUI ausgeliefert wurde, welche fehlerhaft war.
Ich weiß bloß, dass es Drittanbieter gibt, welche GUIs dafür anbieten. Diese machen aber nichts anderes, als die Kommandozeilen zusammenzubauen.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.
So kenne ich das auch. Bei Millionen von Dateien und ein paar Tausend an Ordnern. Aber hier sind es Millionen von Ordnern.Der initial Copy dauerte lange, dafür war der Differential Copy recht fix.
Aber meine Frage war ja eigentlich der Zusammenhang zwischen Parameter /MT und der Anzahl Threads, in welchen der Prozess läuft.
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
Windows Server 2008 R2
Öffentlicher Dienst? 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.
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.
Hi Emeriks,
versuchs mal mit der einer RC Version ab Server2012R2 ( 6.2.9200)- ich hatte das Problem auch schon. Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
versuchs mal mit der einer RC Version ab Server2012R2 ( 6.2.9200)- ich hatte das Problem auch schon. Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
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.
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.
Zitat von @livetosuffer:
versuchs mal mit der einer RC Version ab Server2012R2 ( 6.2.9200)- ich hatte das Problem auch schon. Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
Die Versionen von Windows Server 2012 R2 und 2016 laufen nicht unter 2008 R2. Jedenfalls bekomme ich da gemeldet, dass das keine gültige Win32-Anwendung wäre.versuchs mal mit der einer RC Version ab Server2012R2 ( 6.2.9200)- ich hatte das Problem auch schon. Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
EMCopy scheint es zu richten! 
Ein erster Test hat für die Differenz ca. 40 min benötigt, dabei 250 Dateien mit insgesamt(!) 1 MB kopiert, und 950 Verzeichnisse erstellt.
Ein erster Test hat für die Differenz ca. 40 min benötigt, dabei 250 Dateien mit insgesamt(!) 1 MB kopiert, und 950 Verzeichnisse erstellt.
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 @Lochkartenstanzer:
Von welchen Datenmengen reden wir denn überhaupt?
Von welchen Datenmengen reden wir denn überhaupt?
... Und bei 3 TB insgesamt ....
Zitat von @livetosuffer:
Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
Diese Aussage ist schon mal richtig!Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
Danke!
Habe soeben mal auf einem aktuellen Win2016 getestet, und da kann man sehrwohl im Taskmanager sehen, dass der Prozess bei /MT mit mehr als der in Parameter angegeben Threads läuft. Bei /MT:64 z.B. mit 68.
Danke an alle fürs Mitwirken! Ich hatte schon an mir selbst gezweifelt ...
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ß
Du weißt, dapß es EMCopy auch als x64 Version gibt?
Schon gefunden 
