7
Backup mit robocopy ergibt ERROR 5 Zugriff verweigert
Aloha,
da mein Backup mit xcopy scheinbar auf seine Grenzen stieß (ich vermute mal der gesamte Pfadname dürfte in seiner Länge (224 Zeichen der Pfad + 36 Zeichen die Datei, wo xcopy abbricht) her Probleme bereiten auch wenn die Fehlermeldung „Nicht genügend Arbeitsspeicher“ ausgegeben wird, was nicht nachvollziehbar ist), habe ich mich dem tool robocopy zugewandt ... leider mit weniger glücklichem Ablauf als ich gehofft hatte.
Aber zum Punkt:
Fundament
Hardware: Das Backup läuft auf einem virtualisiertem Windows 2000 (Fileserver 3GB host-RAM) bzw. alternativ virt. Windows 2003 R2 (SQL-Server 4GB host-RAM) Server und die Daten sollen auf ein NAS per Netzwerk gesichert werden.
Zugriff: Die batch für den robocopy-Vorgang wird per Taskplaner (dort als Administrator) gestartet; der Zugriff auf das NAS ist öffentlich (also ohne jegliche benötigten Benutzerfreigaben)
D:\ = W2K Server lokaler Datenträger
B:\ = NAS Netzwerklaufwerk
Problem
Beim Kopieren der Daten wird er Zugriff verweigert, siehe Beispiel (Logausschnitt):
D:\Home\Unterordner\supportfiles\
New File 2.0 m customResource0009.dll
2010/12/08 10:21:00 ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory D:\Home\Unterordner\supportfiles\
Zugriff verweigert
Die batch sieht wie folgt aus:
Lösungsversuch:
Natürlich habe ich mich auch schon hinter's Steuer geklemmt und nach Lösungen gegoogelt (hier im Forum scheinen nur sehr alte, offene Threads zu sein ohne Lösung) und bin auch auf eine gestoßen, die zumindest das Kopieren erfolgreich machte:
einsetzen ...
Das Problem an der Sache ist nur, dass jetzt viele Dateien „unbrauchbar“ zu sein scheinen, Dateien wie z.B. Windows Update-Files (z.B. WindowsInstaller-KB893803-v2-x86.exe), die jetzt weder geöffnet, kopiert oder sonstwie genutzt werden können und auch kein Fenster Eigenschaften aufweisen (auf Grund der wohl fehlenden Attribute?).
Tja, nun, ich bin am Ende meines Wissens (NTBACKUP soll nach Vorgabe nicht genutzt werden, da es schon früher nicht ordnungsgemäß funktioniert haben soll und man nicht aus der backup-file eventuelle Daten wiederherstellen/extrahieren möchte) und hoffe, dass jemand hier noch einen Rat geben kann oder gar eine Lösung des Ganzen.
erhabene Grüße, André
EDIT: hm habe gerade bemerkt, dass es an der Länge des gesamten Pfades liegt, dass einige Dateien nun unter Windows nicht mehr genutzt werden können, da sollte ich wohl mein Backup ohne den Überordner „Backup_SERVER2000" machen ... allerdings behebt das leider noch nicht mein eigentliches Problem, da die Attribute und Eigentümer schon übernommen werden sollten
Fundament
Hardware: Das Backup läuft auf einem virtualisiertem Windows 2000 (Fileserver 3GB host-RAM) bzw. alternativ virt. Windows 2003 R2 (SQL-Server 4GB host-RAM) Server und die Daten sollen auf ein NAS per Netzwerk gesichert werden.
Zugriff: Die batch für den robocopy-Vorgang wird per Taskplaner (dort als Administrator) gestartet; der Zugriff auf das NAS ist öffentlich (also ohne jegliche benötigten Benutzerfreigaben)
D:\ = W2K Server lokaler Datenträger
B:\ = NAS Netzwerklaufwerk
Problem
Beim Kopieren der Daten wird er Zugriff verweigert, siehe Beispiel (Logausschnitt):
D:\Home\Unterordner\supportfiles\
New File 2.0 m customResource0009.dll
2010/12/08 10:21:00 ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory D:\Home\Unterordner\supportfiles\
Zugriff verweigert
Die batch sieht wie folgt aus:
@echo off
robocopy "D:\Home" "B:\Backup_SERVER2000\Home" /S /B /COPY:DATSO /XA:TO /V /R:1 /W:30 /LOG+:"B:\Serverbackup.log" Lösungsversuch:
Natürlich habe ich mich auch schon hinter's Steuer geklemmt und nach Lösungen gegoogelt (hier im Forum scheinen nur sehr alte, offene Threads zu sein ohne Lösung) und bin auch auf eine gestoßen, die zumindest das Kopieren erfolgreich machte:
/COPY:DTDas Problem an der Sache ist nur, dass jetzt viele Dateien „unbrauchbar“ zu sein scheinen, Dateien wie z.B. Windows Update-Files (z.B. WindowsInstaller-KB893803-v2-x86.exe), die jetzt weder geöffnet, kopiert oder sonstwie genutzt werden können und auch kein Fenster Eigenschaften aufweisen (auf Grund der wohl fehlenden Attribute?).
Tja, nun, ich bin am Ende meines Wissens (NTBACKUP soll nach Vorgabe nicht genutzt werden, da es schon früher nicht ordnungsgemäß funktioniert haben soll und man nicht aus der backup-file eventuelle Daten wiederherstellen/extrahieren möchte) und hoffe, dass jemand hier noch einen Rat geben kann oder gar eine Lösung des Ganzen.
erhabene Grüße, André
EDIT: hm habe gerade bemerkt, dass es an der Länge des gesamten Pfades liegt, dass einige Dateien nun unter Windows nicht mehr genutzt werden können, da sollte ich wohl mein Backup ohne den Überordner „Backup_SERVER2000" machen ... allerdings behebt das leider noch nicht mein eigentliches Problem, da die Attribute und Eigentümer schon übernommen werden sollten
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 156570
Url: https://administrator.de/contentid/156570
Printed on: April 18, 2024 at 04:04 o'clock
7 Comments
Latest comment
Moin,
es gibt viele NAS Systeme, die wenigsten verstehen sich mit NTFS.
Von daher - ist das Ziel überhaupt NTFS formatiert?
Gruß
es gibt viele NAS Systeme, die wenigsten verstehen sich mit NTFS.
Von daher - ist das Ziel überhaupt NTFS formatiert?
Gruß
Aloha,
laut Eigenschaften-Aufruf des Datenträgers unter Windows ist es im Dateisystem NTFS (im interface des NAS selbst steht nirgends etwas darüber).
greetz André
laut Eigenschaften-Aufruf des Datenträgers unter Windows ist es im Dateisystem NTFS (im interface des NAS selbst steht nirgends etwas darüber).
greetz André
Also ich arbeite ohne Probleme mit Robocopy Ich nutze meist den / mir parameter da bei / mir alle eigenschaften der Files (Berechtigungen usw.) mit übernommen werden.
Ich kann dir aber auch ein Image System wie Norton backup exec System Recovery sehr empfehlen damit kannst du auch das gesammte System sichern inkl laufendem Exchange usw.
Wir haben die Software bei allen Kunden im Einsatz und auch schon einen Notfall gehabt hat alles Perfekt geklappt in 30 min läuft alles wieder alle daten sind wieder da bei einem Totalausfall und einer Wiederherstellung auf einen anderen Server (andere hardware).
LG Andy
Ich kann dir aber auch ein Image System wie Norton backup exec System Recovery sehr empfehlen damit kannst du auch das gesammte System sichern inkl laufendem Exchange usw.
Wir haben die Software bei allen Kunden im Einsatz und auch schon einen Notfall gehabt hat alles Perfekt geklappt in 30 min läuft alles wieder alle daten sind wieder da bei einem Totalausfall und einer Wiederherstellung auf einen anderen Server (andere hardware).
LG Andy
Aloha,
naja bei uns in der Firma muss immer alles für Null sein, wenn's Geld kostet, muss eine Alternative her. (Dinge wie Exchange & Co. sind hier Fremdwörter ^.^)
Aber siehste, das mit dem /mir wäre nochmal eine Idee (nutze den bisher gewollt nicht - weiß aber auch nicht mehr warum) - werde ich mal demnächst testen, danke für dein Feedback.
greetz André
naja bei uns in der Firma muss immer alles für Null sein, wenn's Geld kostet, muss eine Alternative her. (Dinge wie Exchange & Co. sind hier Fremdwörter ^.^)
Aber siehste, das mit dem /mir wäre nochmal eine Idee (nutze den bisher gewollt nicht - weiß aber auch nicht mehr warum) - werde ich mal demnächst testen, danke für dein Feedback.
greetz André
Naja Geld kosten is ja übertrieben schau mal was das pro PC kostet. man muss das ja nicht bei jedem machen reicht ja bei den Wichtigsten Rechnern.
LG Andy
LG Andy
Hallo,
ich hatte das selbe Problem, und bin auf folgende Lösung gekommen:
Das Problem macht das Filesystem, das als Ziel angegeben ist, auch wenn das der Fehlermeldung widerspricht.
Wird der Parameter "/COPY" nicht explizit angegeben, verwendet robocopy den Defaultwert "/COPY:DAT". Hier ist aber das "A" das Problem, da manche (Ziel-)Filesysteme die Attributes nicht richtig verarbeiten können.
Seit ich explizit den Parameter "/COPY:DT" angebe, funktioniert der RC ohne den ERROR 05.
viele Grüße, Farbauti.
ich hatte das selbe Problem, und bin auf folgende Lösung gekommen:
Das Problem macht das Filesystem, das als Ziel angegeben ist, auch wenn das der Fehlermeldung widerspricht.
Wird der Parameter "/COPY" nicht explizit angegeben, verwendet robocopy den Defaultwert "/COPY:DAT". Hier ist aber das "A" das Problem, da manche (Ziel-)Filesysteme die Attributes nicht richtig verarbeiten können.
Seit ich explizit den Parameter "/COPY:DT" angebe, funktioniert der RC ohne den ERROR 05.
viele Grüße, Farbauti.
Aloha,
wie du in meinem EP lesen kannst, habe ich diese Semi-Lösung bereits verwendet, jedoch ist dies nunmal keine richtige Lösung, da die Attribute übernommen werden sollen.
greetz André
wie du in meinem EP lesen kannst, habe ich diese Semi-Lösung bereits verwendet, jedoch ist dies nunmal keine richtige Lösung, da die Attribute übernommen werden sollen.
greetz André
