10
Xcopy / robocopy
Probleme mit kopieren von großen Datenmengen.
Hallo, wer kann mir helfen? Ich will eine Festplatte kopieren, auf der ca. 20 Millionen Tiff Dateien mit einer Gesamtgröße von ca. 300GB vorhanden sind. Es sind zwei identische Platten mit 400GB. Es beginnt zu kopieren und bei ca 40-50 GB hängt sich das Betriebssystem (WinXP Professional) auf. Sämtliche Versuche schlugen fehl. Habe es schon mit xcopy und auch mit robocopy versucht.
Hallo, wer kann mir helfen? Ich will eine Festplatte kopieren, auf der ca. 20 Millionen Tiff Dateien mit einer Gesamtgröße von ca. 300GB vorhanden sind. Es sind zwei identische Platten mit 400GB. Es beginnt zu kopieren und bei ca 40-50 GB hängt sich das Betriebssystem (WinXP Professional) auf. Sämtliche Versuche schlugen fehl. Habe es schon mit xcopy und auch mit robocopy versucht.
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: 26058
Url: https://administrator.de/forum/xcopy-robocopy-26058.html
Ausgedruckt am: 24.12.2024 um 14:12 Uhr
10 Kommentare
Neuester Kommentar
Dann probiere es mal mit einen Backupprogramm.
Davon gibt es ja sehr viele als Freeware.
Ich würde dir z.B. SyncBack Freeware V3.2.9 (www.2brightsparks.com/downloads.html) vorschlagen.
Damit kanst du die Verzeichnisse kopieren oder syncronisieren.
Gibt denn WinXp eine Fehlermeldung aus?
MoonStar
Davon gibt es ja sehr viele als Freeware.
Ich würde dir z.B. SyncBack Freeware V3.2.9 (www.2brightsparks.com/downloads.html) vorschlagen.
Damit kanst du die Verzeichnisse kopieren oder syncronisieren.
Gibt denn WinXp eine Fehlermeldung aus?
MoonStar
Nein es kommt keine Fehlermeldung. Kopieren wird immer langsamer bis sich das System aufhängt. Es geht nicht einmal mehr der Taskmanager auf.
Hi,
vielleich hilft ja DriveCopy oder ähnliche Tools weiter!
Psycho
Klug ist jeder - der eine vorher, der andere hinterher
vielleich hilft ja DriveCopy oder ähnliche Tools weiter!
Psycho
Klug ist jeder - der eine vorher, der andere hinterher
Ich würde das ganze mit RSYNC versuchen
freier rsync
http://www.itefix.no/phpws/index.php?module=pagemaster&PAGE_user_op ...
p.s.: steht in der Ereignis Anzeige etwas über den Absturz ?
freier rsync
http://www.itefix.no/phpws/index.php?module=pagemaster&PAGE_user_op ...
p.s.: steht in der Ereignis Anzeige etwas über den Absturz ?
in der Ereignisanzeige ist nichts zu sehen, als wir einmal mit dem Copytool robocopy kopierten,
kam die Felermeldung 1450, " für den angeforderten Dienst sind nicht genügend Ressourcen verfügbar".
Eigentlich ist nicht einsehbar, daß beim kopieren ( lesen schreiben ) soviel Systemleistung benötigt werden soll. Dabei haben wir den Hauptspeicher schon auf 1028 MB aufgerüstet
kam die Felermeldung 1450, " für den angeforderten Dienst sind nicht genügend Ressourcen verfügbar".
Eigentlich ist nicht einsehbar, daß beim kopieren ( lesen schreiben ) soviel Systemleistung benötigt werden soll. Dabei haben wir den Hauptspeicher schon auf 1028 MB aufgerüstet
Hallo,
da hängt zwar auch Windows mit drin, aber versuchs mal mit dem Total Commander.
Der ist da teilweise net so anfällig..
MfG IceBeer
da hängt zwar auch Windows mit drin, aber versuchs mal mit dem Total Commander.
Der ist da teilweise net so anfällig..
MfG IceBeer
Moin riwa,
grundsätzlich würde ich den Vor-Postern zustimmen und eins der genannten Tools verwenden. Denn vor allem der XCopy-Befehl ist schon etwas eigenwillig programmiert, was den Ressourcen-Verbrauch bzw. die Ressourcenfreigabe bei größeren Datenmengen angeht.
Dennoch -"echte" Probleme hat auch XCopy hier im Forum nur dann gemacht, wenn er auf Dateien gelaufen ist, die nicht lesbar bzw. auf dem Zielsystem nicht schreibbar waren.
Du konntest also ein möglicherweise vorhandenes derartiges Problem dadurch eingrenzen, indem Du die Verzeichneskopiererei "portionierst", zum Beispiel durch eine rekursive Einzelaufrufe von XCopy in einer FOR..IN.. DO-Anweisung für alle Unterverzeichnisse der ersten Ebene unterhalb der Quellpfad-Rootebene.
Wenn Du dann nach jedem XCopy ...Unterverzeichnis.. Aufruf noch eine kurze Pause (15 sec) einlegst, hat Windows die Gelegenheit, den zertrümmerten Hauptspeicher zu regenerieren.
Wenn Du Deine Quell/Zielvenisstruktur mal skizzerst, können wir diese paar Zeilen zusammenschreddern.
Gruß Biber
grundsätzlich würde ich den Vor-Postern zustimmen und eins der genannten Tools verwenden. Denn vor allem der XCopy-Befehl ist schon etwas eigenwillig programmiert, was den Ressourcen-Verbrauch bzw. die Ressourcenfreigabe bei größeren Datenmengen angeht.
Dennoch -"echte" Probleme hat auch XCopy hier im Forum nur dann gemacht, wenn er auf Dateien gelaufen ist, die nicht lesbar bzw. auf dem Zielsystem nicht schreibbar waren.
Du konntest also ein möglicherweise vorhandenes derartiges Problem dadurch eingrenzen, indem Du die Verzeichneskopiererei "portionierst", zum Beispiel durch eine rekursive Einzelaufrufe von XCopy in einer FOR..IN.. DO-Anweisung für alle Unterverzeichnisse der ersten Ebene unterhalb der Quellpfad-Rootebene.
Wenn Du dann nach jedem XCopy ...Unterverzeichnis.. Aufruf noch eine kurze Pause (15 sec) einlegst, hat Windows die Gelegenheit, den zertrümmerten Hauptspeicher zu regenerieren.
Wenn Du Deine Quell/Zielvenisstruktur mal skizzerst, können wir diese paar Zeilen zusammenschreddern.
Gruß Biber
Hallo an alle, die uns auf aunser Problem geschrieben haben und vielen Dank dafür. Tut uns echt
leid, daß wir uns nicht eher melden konnten, aber leider sind wir, wie solls auch anders sein
völlig unterbesetzt. Unser Problem besteht leider weiterhin.
An IceBeer ( Martin ): Totoalcommander kennen wir natürlich, ist auch echt besser als Windows
Explorer. Hilft uns aber leider nicht, weil das Copy nachts im Batch laufen muß.
Moin Biber,
vielen Dank auch für Deine Antwort. An schlecht lesbare Dateien haben wir auch schon gedacht,
doch Tests mit verschieden Datenträgern ( HDD's ) wiederlegt das eigentlich.
Das einzige, was es wirklich bringt, ist den XCOPY ( wir haben auch mit robocopy getestet, selbiges Problem ) immer wieder zu starten.
Unsere Verzeichnisstruktur ist eigentlich recht simpel
z.B: F:\ordner\tagesordner
tagesordner wird mit dem jeweiligen Tagesdatum automatisch angelegt, z.B. von heute
16022006, und die an diesem Tag gescannten Tiffs verden darin abgelgt. Dieser Ordner
wird dann Nachts von, (wie hier beschrieben F:\) als Siecherung zum Server kopiert.
Das Problem trat eigenlich erst auf, als wir ein größere Festplatte ( 400 GB ) installierten,
mit vorher 250 GB hat es noch immer funktioniert. Wir habe auch schon eine weitere 400 GB
Platte probiert, weil wir dachten, daß dies erste vielleicht defekt wäre, Festplattendiagnosen
haben auch keine Fehler aufgezeigt.
Die Frage ist : hängt das Problem mit der Plattengröße zusammen ( unlogisch ? ), warum
benötigen Copyprogramme soviel Systemressourcen
kann ein normaler PC ( 3.0 GHz mit 1028 MB Hauptspeicher ) als Server überhaupt solche
Datenmengen handeln ? ( es sind mittlerweile über 2 Mio. Tiffs )
vielen Dank im voraus für Euere Bemühungen
leid, daß wir uns nicht eher melden konnten, aber leider sind wir, wie solls auch anders sein
völlig unterbesetzt. Unser Problem besteht leider weiterhin.
An IceBeer ( Martin ): Totoalcommander kennen wir natürlich, ist auch echt besser als Windows
Explorer. Hilft uns aber leider nicht, weil das Copy nachts im Batch laufen muß.
Moin Biber,
vielen Dank auch für Deine Antwort. An schlecht lesbare Dateien haben wir auch schon gedacht,
doch Tests mit verschieden Datenträgern ( HDD's ) wiederlegt das eigentlich.
Das einzige, was es wirklich bringt, ist den XCOPY ( wir haben auch mit robocopy getestet, selbiges Problem ) immer wieder zu starten.
Unsere Verzeichnisstruktur ist eigentlich recht simpel
z.B: F:\ordner\tagesordner
tagesordner wird mit dem jeweiligen Tagesdatum automatisch angelegt, z.B. von heute
16022006, und die an diesem Tag gescannten Tiffs verden darin abgelgt. Dieser Ordner
wird dann Nachts von, (wie hier beschrieben F:\) als Siecherung zum Server kopiert.
Das Problem trat eigenlich erst auf, als wir ein größere Festplatte ( 400 GB ) installierten,
mit vorher 250 GB hat es noch immer funktioniert. Wir habe auch schon eine weitere 400 GB
Platte probiert, weil wir dachten, daß dies erste vielleicht defekt wäre, Festplattendiagnosen
haben auch keine Fehler aufgezeigt.
Die Frage ist : hängt das Problem mit der Plattengröße zusammen ( unlogisch ? ), warum
benötigen Copyprogramme soviel Systemressourcen
kann ein normaler PC ( 3.0 GHz mit 1028 MB Hauptspeicher ) als Server überhaupt solche
Datenmengen handeln ? ( es sind mittlerweile über 2 Mio. Tiffs )
vielen Dank im voraus für Euere Bemühungen
Moin riwa,
mit welchen Parametern startet ihr denn den XCopy?
Poste doch mal bitte die Zeile. Ich könnte mir vorstellen, dass ein "Verify"-Parameter das Problem sein könnte.
Wenn es die Anzahl der Dateien ist, die den XCopy in die Knie zwingt, könnten wir das mit einer FOR /R oder FOR /D _Anweisung aushelben IMHO.
Gruß Biber
mit welchen Parametern startet ihr denn den XCopy?
Poste doch mal bitte die Zeile. Ich könnte mir vorstellen, dass ein "Verify"-Parameter das Problem sein könnte.
Wenn es die Anzahl der Dateien ist, die den XCopy in die Knie zwingt, könnten wir das mit einer FOR /R oder FOR /D _Anweisung aushelben IMHO.
Gruß Biber
moin Biber
wir haben nur /E und /B als Parameter angegeben, also kein Verify, es muß also die
große Anzahl an Dateien sein
Gruß riwa
wir haben nur /E und /B als Parameter angegeben, also kein Verify, es muß also die
große Anzahl an Dateien sein
Gruß riwa
