XCOPY bricht ab !!!
XCOPY bricht bei einer Datensicherung mit der Fehlermeldung "zu wenig Speicher" ab!
Hallo Allerseits,
wir haben folgendes Problem. Ein System, welches bereits seit Jahren einwandfrei läuft
und auch ansonsten keinerlei Probleme aufweist, kopiert bei der Datensicherung
auf eine externe USB-Platte nicht mehr alle Daten.
Die Batch, welche vollautomatisch oder aber manuell vom Anwender gestartet werden kann
bricht mit der Fehlermeldung "zu wenig Arbeitsspeicher. ... " ab.
Es handelt sich vom System her um einen AMD Athlon XP 2800 mit 512 Mb DD-RAM.
Das BS ist Windows 2000 und es sind noch über 380 Mb Speicher frei. (lt. Taskmanager)
Auf allen Partitionen sind noch mind. 30 GB frei, auf der Ext. Festplatte noch 132 GB. Es sind seit der Einrichtung keine Programme hinzugekommen.
Auch nach dem Beenden sämtlicher TSR-Progs, Demons bzw. Virenscanner etc. ist dieser Effekt nach einer 3/4-Kopie zu erkennen. Von 19256 Dateien werden nur 17.xxx kopiert.
kopiert wird mit z.B. xcopy d:\*.* %sicher%\DDRIVE /S /E /V /Y /H /C im Dos-Task
(die Batch wird natürlich im Dos-Task - Eingabeaufforderung ausgeführt, hier angezeigter freier Speicher - wie immer ca. 630 kb unterer Ram für DOS-Proggys frei)
Hat jemand eine Ahnung, was diesen Effekt auslösen kann ? Wir machen Datensicherungen
schon seit Jahren mit individuell angepassten Batches, welche dann vollautomatisch z.B. über
den Taskplaner aktiviert werden. Aber soetwas habe ich bei einem so "neuen System" noch nie
gesehen.
Für Eure Hilfe wäre ich sehr dankbar
MfG
Der Onkel
Hallo Allerseits,
wir haben folgendes Problem. Ein System, welches bereits seit Jahren einwandfrei läuft
und auch ansonsten keinerlei Probleme aufweist, kopiert bei der Datensicherung
auf eine externe USB-Platte nicht mehr alle Daten.
Die Batch, welche vollautomatisch oder aber manuell vom Anwender gestartet werden kann
bricht mit der Fehlermeldung "zu wenig Arbeitsspeicher. ... " ab.
Es handelt sich vom System her um einen AMD Athlon XP 2800 mit 512 Mb DD-RAM.
Das BS ist Windows 2000 und es sind noch über 380 Mb Speicher frei. (lt. Taskmanager)
Auf allen Partitionen sind noch mind. 30 GB frei, auf der Ext. Festplatte noch 132 GB. Es sind seit der Einrichtung keine Programme hinzugekommen.
Auch nach dem Beenden sämtlicher TSR-Progs, Demons bzw. Virenscanner etc. ist dieser Effekt nach einer 3/4-Kopie zu erkennen. Von 19256 Dateien werden nur 17.xxx kopiert.
kopiert wird mit z.B. xcopy d:\*.* %sicher%\DDRIVE /S /E /V /Y /H /C im Dos-Task
(die Batch wird natürlich im Dos-Task - Eingabeaufforderung ausgeführt, hier angezeigter freier Speicher - wie immer ca. 630 kb unterer Ram für DOS-Proggys frei)
Hat jemand eine Ahnung, was diesen Effekt auslösen kann ? Wir machen Datensicherungen
schon seit Jahren mit individuell angepassten Batches, welche dann vollautomatisch z.B. über
den Taskplaner aktiviert werden. Aber soetwas habe ich bei einem so "neuen System" noch nie
gesehen.
Für Eure Hilfe wäre ich sehr dankbar
MfG
Der Onkel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 14037
Url: https://administrator.de/forum/xcopy-bricht-ab-14037.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
4 Kommentare
Neuester Kommentar
Hmmm, Tee-Onkel,
habe zwar auch keine konkrete Vermutung, aber auch ähnliche Xcopy-Mimiken bei Kunden installiert. Auch bei Kunden, die regelmäßig ihre Hardware erneuern oder aufbrezeln und die alten Programme weiterlaufen lassen. Von daher habe ich auch ein gewisses Interesse, diesen Fehler einzugrenzen.
Deshalb erstmal die drei für mich naheliegensten Fragen:
- Das zu sichernde Laufwerk -sind dort auch %temp%-Verzeichnisse und/oder gar Auslagerungsdateien? Und sehr große Dateien? (sprich- kann es durch verify-Aktionen bei sehr großen Dateien zu FlushBuffer-Deadlock-Situationen kommen?)
wenn ja: kannst Du die %temp%-Ordner per Exclude beim Xcopy ausnehmen?
- ist (nicht lachen jetzt) zufällig für die USB-Festplatte im Power-Management eine Standby-Zeitdauer angegeben?
- hängt dieser Effekt Deiner Meinung nach von der ZeitDAUER der xcopy-Runs ab -d.h verreckt der immer nach 8 Minuten oder ist der Abbruch bei Start unter Normal-Bedingungen (mit Virenscanner und TSR etc) schon nach kürzerer Zeit?
Es wird spätestens morgen der Tipp kommen "nimm doch Robocopy, das geht prima" oder so ähnlich - aus den o.a. Gründen würde ich aber gern mit auf die Xcopy-Fehlersuche gehen.
Frank / der Biber aus Bremen
habe zwar auch keine konkrete Vermutung, aber auch ähnliche Xcopy-Mimiken bei Kunden installiert. Auch bei Kunden, die regelmäßig ihre Hardware erneuern oder aufbrezeln und die alten Programme weiterlaufen lassen. Von daher habe ich auch ein gewisses Interesse, diesen Fehler einzugrenzen.
Deshalb erstmal die drei für mich naheliegensten Fragen:
- Das zu sichernde Laufwerk -sind dort auch %temp%-Verzeichnisse und/oder gar Auslagerungsdateien? Und sehr große Dateien? (sprich- kann es durch verify-Aktionen bei sehr großen Dateien zu FlushBuffer-Deadlock-Situationen kommen?)
wenn ja: kannst Du die %temp%-Ordner per Exclude beim Xcopy ausnehmen?
- ist (nicht lachen jetzt) zufällig für die USB-Festplatte im Power-Management eine Standby-Zeitdauer angegeben?
- hängt dieser Effekt Deiner Meinung nach von der ZeitDAUER der xcopy-Runs ab -d.h verreckt der immer nach 8 Minuten oder ist der Abbruch bei Start unter Normal-Bedingungen (mit Virenscanner und TSR etc) schon nach kürzerer Zeit?
Es wird spätestens morgen der Tipp kommen "nimm doch Robocopy, das geht prima" oder so ähnlich - aus den o.a. Gründen würde ich aber gern mit auf die Xcopy-Fehlersuche gehen.
Frank / der Biber aus Bremen
.."wenn alle anderen Möglichkeiten ausgeschlossen werden können, dann muss die letzte übrig gebliebene Möglichkeit eingetreten sein, wie unwahrscheinlich sie auch klingen mag.."
(so ähnlich lässt es Sir Arthur Conan Doyle seinen Sherlock sagen, glaube ich mich zu erinnern..)
Vielen Dank für die Rückmeldung, Tee-Onkel
Biber
P.S. Und das Du bereits mit chkdsk und/oder scandisk unterwegs warst, habe ich als gesichert angenommen. Dieser Tipp wäre mir zu peinlich gewesen.
P.P.S. Und wehe, es postet eine/r "Robocopy hätte diesen Fehler ignoriert, der hat einen Schalter 'trotz Fehler fortfahren' ..." *gg
(so ähnlich lässt es Sir Arthur Conan Doyle seinen Sherlock sagen, glaube ich mich zu erinnern..)
Vielen Dank für die Rückmeldung, Tee-Onkel
Biber
P.S. Und das Du bereits mit chkdsk und/oder scandisk unterwegs warst, habe ich als gesichert angenommen. Dieser Tipp wäre mir zu peinlich gewesen.
P.P.S. Und wehe, es postet eine/r "Robocopy hätte diesen Fehler ignoriert, der hat einen Schalter 'trotz Fehler fortfahren' ..." *gg