skyemugen
Goto Top

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:
@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:DT
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

Content-ID: 156570

Url: https://administrator.de/contentid/156570

Ausgedruckt am: 23.11.2024 um 00:11 Uhr

60730
60730 08.12.2010 um 12:47:53 Uhr
Goto Top
Moin,

es gibt viele NAS Systeme, die wenigsten verstehen sich mit NTFS.

Von daher - ist das Ziel überhaupt NTFS formatiert?


Gruß
Skyemugen
Skyemugen 08.12.2010 um 13:18:36 Uhr
Goto Top
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é
Ausserwoeger
Ausserwoeger 02.02.2011 um 17:27:17 Uhr
Goto Top
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
Skyemugen
Skyemugen 02.02.2011 um 17:53:45 Uhr
Goto Top
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é
Ausserwoeger
Ausserwoeger 03.02.2011 um 09:08:32 Uhr
Goto Top
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
Farbauti
Farbauti 12.06.2011 um 12:12:05 Uhr
Goto Top
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.
Skyemugen
Skyemugen 12.06.2011 um 21:12:49 Uhr
Goto Top
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é