4
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
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: 14037
Url: https://administrator.de/contentid/14037
Ausgedruckt am: 23.11.2024 um 01:11 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
Hey uncle!!!
versuchs doch mal mit robocopy!!!
hatte das gleiche Problem!!!
und anstatt mich mit dem xcopy rumzuschlagen hat mit robocopy alles ganz hervoragend funktioniert!
versuchs doch mal mit robocopy!!!
hatte das gleiche Problem!!!
und anstatt mich mit dem xcopy rumzuschlagen hat mit robocopy alles ganz hervoragend funktioniert!
@Biber
ersteinmal vorweg, ich habe das Problem gelöst.
Vielen Dank für Deine Anregungen und hier meine Antworten:
- 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?)
Es lagen sowohl die Temp-u. Cache-Ordner von Mozilla mit auf dem Laufwerk
und zudem auch die über 2 Gb grossen Ghost-Images der Maschine. Diese Verzeichnisse
und auch das Ghost-Images wurden einwandfrei kopiert.
- wenn ja: kannst Du die %temp%-Ordner per Exclude beim Xcopy ausnehmen?
s.o.
- ist (nicht lachen jetzt) zufällig für die USB-Festplatte im Power-Management eine Standby-Zeitdauer angegeben?
Ich kenne die gleiche Problematik bei anderen Wechsel bzw. USB-Platten, hatte ich ebenfalls nachgeschaut, war kein Powermanagement bzw. Stand-By für das Laufwerk aktiviert.
- 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?
Nein, aber genau nach der gleichen Datei
- 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.
, war auch so ....
Also zu der Lösung:
Man glaubt es kaum, es lag an ein paar elendig verreckten Directory-Einträgen. Diese
Einträge sind im Explorer NICHT zu sehen gewesen und setzen sich aus diversen Sonderzeichen, Leertasten und anderen schönen Symbolen zusammen. Ich habe diese
zufällig entdeckt, da ich im Dos in dem Verzeichnis in dem die Batch verreckt war, mir die Verzeichnisse mit dir *. habe anzeigen lassen und somit drei dieser hieroglyphenartigen Einträge sehen konnte.
Ebenfalls zu sehen waren zwischen den über 110 Zeichen langen Einträgen, das Erstelldatum sowie eine "virtuelle" Datei-Größe (konnte nicht stimmen).
Natürlich hatte ich bereits gestern ein Scandisk und Defrag über die Platte laufen lassen, auch nach einem nochmaligen Durchlauf wurden diese Einträge jedoch nicht entfernt.
Da diese Einträge im normalen Explorerfenster nicht zu sehen waren, habe ich über SUCHEN
im Explorer mit der Datum- und Zeiteingrenzung mir alle Dateien in diesem Bereich anzeigen lassen. Und siehe da, hier waren meine verwaisten kleinen Schlingel ....
(Nur vorweg die Einträge waren weder versteckt noch als System markiert, im Übrigen lasse ich mir als Admin immer sämtliche Dateien anzeigen - auch Systemdateien und versteckte).
Jetzt konnte ich sie im Suchenfenster markieren und löschen.
Mein Gott, das war eine Aktion beim Kunden ... aber ich wollte es halt wissen.
Jetzt frage ich mich natürlich, wie kann soetwas sein ? Wie kann im normalen Explorerfenster dieser Müll nicht angezeigt werden, jedoch über die Suchfunktion schon.
Alle meine kleinen Aufräum-utilities haben in diesem Fall völlig versagt und im Prinzip habe ich diese "Dateisystemanomalie" auch nur durch Zufall gefunden. Gnade uns Gott, wenn soetwas auch mal bei einigen ded. Servern passiert.
Ich hoffe, ich kann so auch ein paar anderen Leuten behilflich sein.
Problem gelöst, in diesem Sinne, vielen Dank und bis zum nächsten Mal
Olli, The Uncle
ersteinmal vorweg, ich habe das Problem gelöst.
Vielen Dank für Deine Anregungen und hier meine Antworten:
- 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?)
Es lagen sowohl die Temp-u. Cache-Ordner von Mozilla mit auf dem Laufwerk
und zudem auch die über 2 Gb grossen Ghost-Images der Maschine. Diese Verzeichnisse
und auch das Ghost-Images wurden einwandfrei kopiert.
- wenn ja: kannst Du die %temp%-Ordner per Exclude beim Xcopy ausnehmen?
s.o.
- ist (nicht lachen jetzt) zufällig für die USB-Festplatte im Power-Management eine Standby-Zeitdauer angegeben?
Ich kenne die gleiche Problematik bei anderen Wechsel bzw. USB-Platten, hatte ich ebenfalls nachgeschaut, war kein Powermanagement bzw. Stand-By für das Laufwerk aktiviert.
- 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?
Nein, aber genau nach der gleichen Datei
- 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.
, war auch so ....Also zu der Lösung:
Man glaubt es kaum, es lag an ein paar elendig verreckten Directory-Einträgen. Diese
Einträge sind im Explorer NICHT zu sehen gewesen und setzen sich aus diversen Sonderzeichen, Leertasten und anderen schönen Symbolen zusammen. Ich habe diese
zufällig entdeckt, da ich im Dos in dem Verzeichnis in dem die Batch verreckt war, mir die Verzeichnisse mit dir *. habe anzeigen lassen und somit drei dieser hieroglyphenartigen Einträge sehen konnte.
Ebenfalls zu sehen waren zwischen den über 110 Zeichen langen Einträgen, das Erstelldatum sowie eine "virtuelle" Datei-Größe (konnte nicht stimmen).
Natürlich hatte ich bereits gestern ein Scandisk und Defrag über die Platte laufen lassen, auch nach einem nochmaligen Durchlauf wurden diese Einträge jedoch nicht entfernt.
Da diese Einträge im normalen Explorerfenster nicht zu sehen waren, habe ich über SUCHEN
im Explorer mit der Datum- und Zeiteingrenzung mir alle Dateien in diesem Bereich anzeigen lassen. Und siehe da, hier waren meine verwaisten kleinen Schlingel ....
(Nur vorweg die Einträge waren weder versteckt noch als System markiert, im Übrigen lasse ich mir als Admin immer sämtliche Dateien anzeigen - auch Systemdateien und versteckte).
Jetzt konnte ich sie im Suchenfenster markieren und löschen.
Mein Gott, das war eine Aktion beim Kunden ... aber ich wollte es halt wissen.
Jetzt frage ich mich natürlich, wie kann soetwas sein ? Wie kann im normalen Explorerfenster dieser Müll nicht angezeigt werden, jedoch über die Suchfunktion schon.
Alle meine kleinen Aufräum-utilities haben in diesem Fall völlig versagt und im Prinzip habe ich diese "Dateisystemanomalie" auch nur durch Zufall gefunden. Gnade uns Gott, wenn soetwas auch mal bei einigen ded. Servern passiert.
Ich hoffe, ich kann so auch ein paar anderen Leuten behilflich sein.
Problem gelöst, in diesem Sinne, vielen Dank und bis zum nächsten Mal
Olli, The Uncle
.."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
