robocopy - kopieren schlägt fehl > fehlende Berechtigungen?

[andrew 15]

Liebe Board Benutzerinnen und Benutzer

 

 

Ziel:

Möchte via Aufgabenplanung einen Skript aufrufen, welcher via Robocopy und dem Parameter /mir jeweils die Verzeichnisstruktur auf ein Zielort spiegelt Und: dabei möchte ich einen Backup Benutzer in der Aufgabenplanung hinterlegen, welcher meiner Ansicht nach in der Gruppe Sicherungs-Operatoren sein müsste, damit es funktioniert?!

 

Doch zuerst habe ich als Test Skript via cmd mit administratoren Rechten gestartet und von hier aus manuell gestartet.

Verzeichnisstruktur X wurde nach Speicherort Y gespiegelt (296 GB), jedoch zeigte die Statistik am Ende ca. 846 Fehler an

 

 

 

Was habe ich bis jetzt versucht und umgesetzt?

Nach Berechtigungsprinzip AGDLP vorgegangen

 

Bemerkung dazu:

(Accounts in Globabe Gruppen, Globale Gruppen in DomänenLokale Gruppen und die DomänenLokalen Gruppen auf dem entsprechenden Share (Laufwerk) berechtigt)

 

> Den Benutzer Backup erstellt und als Mitglied der Gloabel Gruppe G_Backupgruppe gemacht

> die Globale Gruppe in die DomänenLokale Gruppe gesteckt, sprich: unter Reiter Mitglied von die DomänenLokale Gruppe DL_Backupgruppe hinzugefügt und auch die DomäneLokale Sicherheitsgruppe Sicherungs-Operatoren (ist per Standard im AD in der OU unter Domäne\Builtin zu finden) unter dem Reiter Mitglied von hinzugefügt (wie zuvor die DL_Backupgruppe)

 

Zwischenergebnis:

Habe also nun einen Benutzer namens Backup, der ist ist Mitglied der Globalen Gruppe G_Backupgruppe und diese wiederum ist Mitglied von der DomänenLokalen Gruppe DL_Backupgruppe und der DomänenLokalen Gruppe Sicherungs-Operatoren

 

Als nächstes habe ich dien Quelle Share und den Ziel Share mit der DomänenLokalen Gruppe namens DL_Backupgruppe berechtigt, da meine Überlegung war und ist, dass robocopy beim Kopieren sowohl auf der Quelle wie auch auf dem Ziel die nötige Berechtigung braucht?!

 

 

Im oben genannten Beispiel ist Verzeichnisstruktur X und Speicherort Y jeweils ein Laufwerk, konkret:

> Speicherort X = externe HD an meinem Notebook, mit NTFS formatiert und ist unter dem Freigabenamen ext-Disk erreichbar. NTFS Rechte sind wie folgt: unter anderem ist wie erwähnt, in meinen Augen die notwendige, DomänenLokale Gruppe mit dem Namen DL_Backupgruppe mit Vollzugriff definiert

> die gleichen Berechtigungen habe ich auf dem Server, auf dem entsprechenden Laufwerk umgesetzt!

Habe auch da das Laufwerk unter einer Freigabe freigegeben, Freigabename = Daten, NTFS Berechtigungen auch da: unter anderem die DomänenLokale Gruppe DL_Backupgruppe mit Vollzugriff ausgestattet!

 

So, Fazit:

Sowohl die QuellFreigabe wie auch die ZielFreigabe haben nun die DomänenLokale Gruppe DL_Backupgruppe mit Vollzugriff definiert, Shareseitig = Jeder Vollzugriff

 

 

So, nochmals zur Verwirrung :-) Da die DL_Backupgruppe Mitglied der G_Backupgruppe ist und diese wiederum Mitglied der Sicherungs-Operatoren, müsste doch jetzt robocopy Verzeichnisstruktur X nach Zielspeicherort Y spiegel, sofern ich ein CMD unter dem Kontext des oben erwähnten Backup Benutzers öffne und danach starte oder nicht?

 

Antwort: es funktioniert in der Realität bei mir nicht, kann ich aber nicht verstehen, da doch nun mein backup Benutzer schlussendlich auch Mitgleid der Gruppe Sicherungs-Operatoren ist, diese Gruppe auch auf dem QuellShare und dem ZielShare berechtigt ist (auf dem Root) und somit es möglich sein sollte, das robocopy starten sollte?

 

 

Die Fehlermeldung lautet wie folgt: (Ausgabe de Log Files)

--------------------------------------------------------------------------------------------------------------------------------------------------------

FEHLER: Sie verfgen nicht ber die Benutzerrechte zum Sichern und Wiederherstellen von Dateien.
*****   Diese Rechte sind erforderlich, um Sicherungskopien anzufertigen (/B oder /ZB).

FEHLER: Nicht gengend Arbeitsspeicher. Der Vorgang wird beendet.
FEHLER: Ungltiger Parameter #%d : "%s"

FEHLER: Ungltige Auftragsdatei, Zeile #%d :"%s"

  Gestartet: %hs

   Quelle %c

     Ziel %c
  Einfache Syntax :: ROBOCOPY Quelle Ziel /MIR

        Quelle :: Quellverzeichnis (Laufwerk:\Pfad oder \\Server\Freigabe\Pfad)
          Ziel :: Zielverzeichnis (Laufwerk:\Pfad oder \\Server\Freigabe\Pfad)
          /MIR :: Spiegelt eine vollst„ndige Verzeichnisstruktur.

    Weitere Informationen erhalten Sie ber den Befehl "ROBOCOPY /?"

                                                         
**** Der Befehl "/MIR" kann Dateien sowohl kopieren als auch L™SCHEN.

--------------------------------------------------------------------------------------------------------------------------------------------------------

 

Hat schon Jemand von euch es erfolgreich hingekriegt, dass robocopy unter einem erstellen Benutzer, welcher schlussendlich Mitglied der Sicherungs-Operatoren ist, eine Sicherung ausführt?

 

Wenn ja, auch als Task in der Aufgabenplanung? (wäre mein nächstes Ziel)

 

 

Bin der Ansicht, dass diese Gruppe nicht treffender für mein Vorhaben sein könnte als einfach wie oft viele das Motto anwenden, ach: nehmen wir doch den Admin, denn gehts  schon...nein, ich will keinen Admin, für was? wir haben die Sicherungs-Gruppe, die ist doch dafür da oder nicht?

 

 

Danke euch für die Unterstützung, danke danke danke

 

cheers

André aus der Schweiz

[frr 11]

Hallo André,

 

machst Du das zufällig unter Windows 2008 oder auch R2? Da gibt es einen Hotfix dafür. Schau mal in diesem Artikel nach ungefährt in der Hälfte stehen die Links:

 

http://blog.iteach-online.de/index.php/2012/06/wie-migriere-ich-einen-fileserver/

 

Viele Grüße

 

Frank

[andrew 15]

Hallo Frank

 

Danke für den Link. Den habe ich auch bereits gefunden und sowohl für X64 wie auch X86 (Windows 7 Enterprise 32 Bit) und Windows Server 2008 Enterprise 64 Bit) heruntergeladen und die Installation gestartet (auf dem Windows 7 Gerät, die Domänen-Admin Infos im UAC Passwort Abfrage Fenster eingegeben)

 

Auf dem Server eh mit dem Domänen-Admin angemeldet, auf beiden Systemen kommt folgende Meldung: Das Update gilt nicht für Ihr System..

 

tolllllll :-)

 

Habe dann nach dem KB950790-x64 Artikel und dieser Fehlermeldung gesucht, doch zum Ziel kam ich so trotzdem nicht.
Irgendwo habe ich noch gelesen, dass wenn der Quell Share und der Ziel Share mit der Gruppe Sicherungs-Operatoren berechtigt seien (Vollzugriff), Robocopy dann als Admin ausgeführt werde, dieser einfach somit nicht explizit auch noch auf dem Quell Share und Ziel Share berechtigt werden müsse, sondern die Sicherung auch ohne expizite Berechtigungen für den Admin auf den Shares dann funktioniere (sinngemäss übersetzt)

 

Es erstaunt mich wirklich, denn dass man einen Robocopy Skript in einem Batch ausführt, dieser bevor man Ihn in einer Aufgabenplanung einbindet, zuerst manuell via cmd Fenster aufruft und testet, versteht sich zumindest für meine Vorgehensweise als normal ;) und eben, dass man dann auch versucht, das cmd Fenster als diesen Benutzer auszuführen, welcher der DomänenLokalen Gruppe Sicherungs-Operatoren angehört, weil man ja testen möchte, ob der Benutzer die Berechtigungen nun hat und das Robocopy Skript so durchläuft und kopiert, ist meiner Ansicht nach doch auch normal oder findet Ihr meine Vorgehensweise "komisch"?

 

Wie schon von mir im vorhergehenden Beitrag geschildert, hat sich diese Idee einfach daraus entwickelt, dass ich dachte: oook, es gibt eine DomänenLokale Sicherungsgruppe mti dem Namen Sicherungs-Operatoren, es gibt wie Du Franz angesprochen hast sogar Microsoft seitig "Hotfixes" für genau dieses Szenario und ja, funktionieren tuts dann trotzdem nicht...

 

Also ich finde das extrem speziell, auch desswegen, weil ich unter google sehr wenig finde, wenn ich als Stichwort robocopy und Sicherungs-Operatoren in den Zusammenhang bringe...

 

Habe einfach den Eindruck, dass viele Admins wie oft sich gar keine Mühe machen wollen, können, keine Lust haben oder wie auch immer, sich über solche Dinge "zu ärgern" oder denen nachzugehen ?? das ist zumindest mein Eindruck auf Grund der Suchresultate in google

 

Bin schon frech oder? *lach* ...Nein Spass bei Seite, ich habe jetzt, weil ich nicht weiterkomme, mal den Skript via cmd, rechte Maustaste, als Admin ausführen, so ausgeführt ...

 

So gehts, zumal ich dann zig Fehlermeldungen am Schluss in der Zusammenfassung des Logfiles vorfinde und habe soeben selber festgestellt, dass dies mit dem Schalter /copy:dat (dem A = Attribute) zusammenhängt.

Sprich, die Fehlermeldungen bedeuten anscheinend, dass Robocopy von den ca. 296 GB nicht überall das Attribute mitkopieren konnte?? so deute ich zumindest die Sache, denn wenn ich nur /copy:dt ausführe, habe ich Null Fehlermeldungen.

 

Doch das Problem ist dabei ja, wenn ich beispielsweise Dateien schreibschützen würde, mit Betonung auf würde, so wird dann beispielsweise der bereits vorhandenen Datei im Ziel Share diese Attribute nicht hinzugefügt?! (wenn ich dann im Skript wieder die Option /copy:dat verwende)

 

Wie ich das wiederum hinkriege, ist dann eine zweite Baustelle ...Aber zumindest kopiert es schon mal, ist doch auch schon was *grins* (mit admin Rechten)

 

[Weingeist 157]

Du wirst manchmal auch Probleme mit dem Admin-Account haben. Dieser hat zwar theoretisch Zugriff, muss man manchmal aber explizit bestätigen/erzwingen. Also ähnlich wie wenn Du mit dem Admin-Account in den Windowsordner navigierst.

 

Weiterer Stolperstein: Du hast die automatische Vererbung bei einigen Ordner deaktiviert und alle Konten entfernt und nur die drin, die Zugriff haben. Leider geht jetzt auch nix mehr mit Robocopy. =)

 

Sicherungs-Operatoren: Nun die dienen nur der Sicherung der DC's und haben mit eigentlich Schreibrechten auf Verzeichnisse wenig zu tun. Für FileLevel-Zugriff werden File-Level Berechtigungen benötigt.

 

Lösungsvorschlag:

V1: Du schaust dass dein Backupuser wirklich alle benötigten Rechte hat überall hat, auch in Ordner mit unterbrochener Vererbungskette

V2: Du lässt das Script als System laufen und wertest nacher das Log aus ob sogar System kein Zugriff hat --> Entfernten System aus unterbrochener Vererbungskette. System ist meistens überall drinn, wenn es nicht mutwillig entfernt wurde

[andrew 15]

Hallo Member

 

(ich bin auch Member)

Hast Du einen Namen? :-)

 

Betreffend der Vererbung der DomänenLokalen Gruppe DL_Backupgruppe:

Habe unter anderem als erstes zusätzlich auf dem Root (also zuoberst in der Hierarchie der Ordnerstruktur) der externen Festplatte zusätzlich die DomänenLokale Gruppe DL_Backupgruppe definiert und dieser Vollzugriff gewährt. Die Vererbung der untergeordneten Ornder war zu diesem Zeitpunkt noch aktiviert, somit haben alle Unterordner und Dateien diese Berechtigung geerbt.

 

Diese Angelegenheit sollte funktionieren. Darum bleibe ich vorerst beim Vorschlag 1 :) ..

 

Bemerkung betreffend Sicherungs-Operatoren:
Wenn diese Gruppe effektiv in erster Linie dafür da sein sollte, die Sicherung von Dateien auf einem DC zuzulassen, würde dies ja im Umkehrschluss bedeuten, dass wenn ich jetzt meine Filestruktur (Ziel Share, welcher Robocopy benutzt) auf meinem jetzigen Member Server NICHT da drauf hätte, sondern auf dem DC, mein Vorhaben betreffend: cmd Fenster als backup Benutzer starten und Skript starten, welches robocopy anstösst, funktionieren?

 

In der Theorie ja oder?

Das wäre jetzt noch spannend zu wissen, bin mir gerade am überlegen, ob ich das noch kurz testen soll?! :-)

 

Aber wer hat den Daten auf einem DC? Was für Daten? Klar, wenn man nur einen DC hat, als Beispiel, bleibt einem nichts anders übrig, hat man aber die Möglichkeit, mehrere Server zu installieren, verwalten, so würde zumindest ich Daten NICHT auf einem DC speichern, sprich, den DC als Fileserver benutzen wollen

 

Vielleicht siehst Du das anders?

Darum frage ich mich, warum wohl die Gruppe nur dazu da ist, Daten auf einem DC zu sichern?

 

Kann da Microsofts Philosophie nicht ganz folgen :-)

[Sunny61 772]

Hallo Member

 

(ich bin auch Member)

Hast Du einen Namen? :-)

Schau doch einfach 1 cm weiter nach oben. :p

[Weingeist 157]

DC + Fileserver: Nun, kann man in kleinen Umgebungen durchaus kombinieren. Muss man im Zusammenhang mit DFS aber vorsichtig sein (PDC-Emulator Problematik). Da hätte ich höchstens den Datenspiegel (zbsp. mit Robocopy erstellt) auf nem DC den man dann notfals als Ziel im DFS eintragen könnte, wenn der Fileserver in die Knie geht (bevorzuge jeweils nur ein aktives Ziel --> Versionskonflikte)

Bemerkung betreffend Sicherungs-Operatoren:

Wenn diese Gruppe effektiv in erster Linie dafür da sein sollte, die Sicherung von Dateien auf einem DC zuzulassen, würde dies ja im Umkehrschluss bedeuten, dass wenn ich jetzt meine Filestruktur (Ziel Share, welcher Robocopy benutzt) auf meinem jetzigen Member Server NICHT da drauf hätte, sondern auf dem DC, mein Vorhaben betreffend: cmd Fenster als backup Benutzer starten und Skript starten, welches robocopy anstösst, funktionieren?

War falsch. Sorry. Gilt nicht nur für DC's. Der Sicherungsoperator sollte das durchaus generell können. Ich frage mich nur welche Rechte zusätzlich gesetzt sein müssen, ob da System die Berechtigung im Ordner haben muss damit das klappt oder nicht.

 

Wenn Dein BackupUser die NTFS Rechte sowieso hat, sollte es aber auch ohne die Backupflags in Robocopy funktionieren. Schonmal ohne versucht?

 

Von wo nach wo kopierst du? Freigabe zu Freigabe von einem externen Rechner? Lokal zu Lokal? Lokal zu Freigabe?

--> Fals über Freigaben, funktioniert das Script den lokal? Also evtl. mangelnde FreigabeRechte? --> Kann nicht sagen ob der SicherungsOp seine Rechte auch von extern wahrnehmen kann oder nur auf der Maschine wo man das Script ausführt. Also Script testweise Lokal auf der Quelle ausführen, fals nicht bereits so gemacht wird. Ziel sollte egal sein (Du musst nur auch auf dem Ziel SicherungsOp sein, sonst dürfte das nicht gehen).

 

Kopiert er überhaupt was oder läuft er sofort in den Fehler?

 

Wie sieht der aufgerufene Befehl aus?

bearbeitet 21. Februar 2013 von Weingeist

[andrew 15]

Hallo Weingeist

 

 

Betreffend DC + Fileserver Und: DFS

Schon lange kein DFS mehr konfiguriert, danke für den HInweis, nett zu Wissen :-)

 

Betreffend Sicherungs-Operatoren: Sollte generell auch gehen? Hast Du das schriftlich *grins*

 

Meine eigentliche Quelle - Ziel Robocopy Konstellation sieht wie folgt aus:

> Quelle = externe HD an meinem NB, UNC Pfad im Skript nennt sich hierfür: \\clifau001\ext-disk (externe USB HD als ext-Disk freigegeben)

> Ziel = virtueller Server, UNC Pfad im Skript nennt sich hierfür: \\vmsrvfau003\Daten$

 

 

Aktueller Stand:

Die Daten von \\clifau001\ext-disk sind in die root Freigabe Daten$ gespiegelt, gleicher Datenbestand. Wie habe ich das mit robocopy hingekriegt?

 

Weil das Skript, welches robocopy aufruft, via rechts (und gleiczeitig noch die Shift Taste) Klick auf cmd, als anderen Benutzer ausführen, backup Benutzer eingegeben mit Passwort und so das cmd Fenster mit den rechten des backup Benutzers gestartet habe, jedoch der Skript nicht läuft, sprich, kein Bit kopiert, habe ich das cmd Fenster via Rechtsklick, als Administrator ausführen so starten können :-)

 

Aber eben, mein Ziel wäre, sofern technisch möglich, wie soeben beschrieben, schlussendlich eine Aufgabenplanung, einfache Aufgabe einrichten (nennt sich so, in der Aufgabenplanung) und da muss ja ein Benutzer angegeben werden, sprich, man definiert einen Benutzer, damit das Skript oder welches Programm man auch immer ausführen mag, weiss, unter welchem Benutzerkontext es ausgeführt werden soll.

 

Da möchte ich eben dann meinen backup Benutzer angeben!

 

> Der Backup Benutzer hat gemäss meinem AGDLP Berechtigungsprinzip nicht nur auf dem root Quell Share wie auch auf dem root Ziel Share Vollzugriff

> Er ist auch Mitglied der Gruppe Sicherungs-Operatoren.

 

Bemerkung diesbezüglich: Interessant ist auch, dass wenn ich das CMD Fenster als backup Benutzer starte und den Befehl whoami /priv eingebe, mir kein Recht betreffend Sichern von Dateien angezeigt wird, obwooooooohl er ja immer noch zu den Sicherungs-Operatoren anzeigt, aber das scheint ein anderes Microsoft Problem zu sein...

 

Egal, will nicht noch für mehr Verwirrung sorgen :-)

 

 

Stand:

> Skript mit robocopy wird zur Zeit nur ausgeführt (Share zu Share >> \\clifau001\ext-disk \\vmsrvfau003\daten$), wenn ich das cmd Fenster via Rechtsklick als Administrator ausführe

> Skript läuft NICHT, wenn ich das cmd rechtsklick (mit gedrückter Shift Taste) anwähle und sage, als anderen Benutzer ausführe und hier eben meinen Backup Benutzer eingebe

> Und: Wenn ich von Lokal zu Lokal kopiere, habe mir extra die Mühe genommen und auf meinem NB auf dem C:\ zwei Ordner erstellt C:\Quelle + C:\Ziel im Ordner C:\Quelle habe ich zwei Textdateien erstellt. QuellDatei.txt und QuellDatei02.txt

 

Dann mit folgendem robocopy Befehl (extra für diesen Kopierzweck etwas angepasst >> Quelle und Ziel Definition)

robocopy.exe c:\Quelle\ C:\Ziel /mir /zb /copy:DATSO /r:2 /XD "_RESTORE" "MSOCache" "Recycled" "RECYCLER" "Temporary Internet Files" "System Volume Information" "WUTemp" /XF $RECYCLE.BIN desktop.ini *.swp *.dmp *.tmp pagefile.sys hiberfil.sys /mt:22 /ns /nc /log+:c:\Logfiles\backup-all-Files-test.txt

 

 

Bemerkung: Würde ich anstatt den Schalter copy:DATSO den Schalter /copyall verwenden, würde dann im LOG File stehen:

FEHLER: Sie verfgen nicht ber Benutzerrechte zum Verwalten von šberwachungsprotokollen.
*****   Diese Rechte sind erforderlich, um šberwachungsinformationen zu kopieren (/COPY:U oder /COPYALL).

 

 

Ob ich nun lokal oder von externe HD am Notebook (Share) auf den Share (auf virtuellem Mitgliedsserver) kopiere, der Fehler im LOG Lautet immer:

FEHLER: Sie verfgen nicht ber die Benutzerrechte zum Sichern und Wiederherstellen von Dateien.
*****   Diese Rechte sind erforderlich, um Sicherungskopien anzufertigen (/B oder /ZB).

 

 

Bemerkung betreffend lokal kopieren:

Habe auf den erstellten zwei Ordnern (C:\Quelle + C:\Ziel) zusätzlich unter den NTFS Rechten die Gruppe DL_Backupgruppe eingepflanzt, Vollzugriff vergeben.

 

Und betreffend deiner Frage im Bezug auf den SystemBenutzer: Der hat vererbte Rechte auf den zwei neu erstellten Ordnern, nämlich jweils Vollzugrif.

 

Somit ist die Frage auch geklärt, ob der evtl. Vollzugriff auf dem Quell Share (Quelle) und Ziel Share (Ziel) haben muss, nebst den Sicherungs-Operatoren NTFS Vollzugriff Berechtigungen ;)

 

Der Mitgliedsserver, auf welchem der Ziel Share vorhanden ist, hat die neuten Windows Updates installiert, SP2 und das volle Programm

 

mein NB hat fast alle Updates drauf. Habe im Moment absichtlich noch nicht alle drauf, weil es anscheinend ein Windows Update gibt, welches schuld ist, dass danach dann das rechtsklicken auf cmd, ausführen als Adminsitrator nicht mehr funktioniert (kommt dann immer eine Fehlermeldung, welche ich jetzt so nicht habe)

 

Hatte darum mein Windwos 7 NB via Systemwiederherstellung ein paar Tage zurückgesetzt, damit ich diese Funktion nach wie vor fehlerfrei nutzen kann, das noch so nebenbei als Information zion ;)

 

Soo, ob wir da noch eine Lösung finden?

 

 

cheers

Andrew

 

 

[Weingeist 157]

Aber eben, mein Ziel wäre, sofern technisch möglich, wie soeben beschrieben, schlussendlich eine Aufgabenplanung, einfache Aufgabe einrichten (nennt sich so, in der Aufgabenplanung) und da muss ja ein Benutzer angegeben werden, sprich, man definiert einen Benutzer, damit das Skript oder welches Programm man auch immer ausführen mag, weiss, unter welchem Benutzerkontext es ausgeführt werden soll.

So sichere ich meine Files jeweils auch.

 

 

Zitat: Betreffend Sicherungs-Operatoren: Sollte generell auch gehen? Hast Du das schriftlich *grins* --> Leider nein

 

Hast Du die BackupFlags mal entfernt im Robocopy-Kommando? Also ZB entfernt? Macht er dann was? Das bräucht der Benutzer nämlich nicht wenn er Vollzugriff auf die Files hätte.

 

robocopy.exe c:\Quelle\ C:\Ziel /mir /zb /copy:DATSO /r:2 /XD "_RESTORE" "MSOCache" "Recycled" "RECYCLER" "Temporary Internet Files" "System Volume Information" "WUTemp" /XF $RECYCLE.BIN desktop.ini *.swp *.dmp *.tmp pagefile.sys hiberfil.sys /mt:22 /ns /nc /log+:c:\Logfiles\backup-all-Files-test.txt

 

Ansonsten, sind die Beteiligten Computer alle in der selben Domäne?

Hat dein Backupbenutzer auch auf der lokalen Maschine - also dein Notebook - Sicherungs-Ops Rechte? --> Schuss ins blaue, weiss nicht ob notwendig.

[andrew 15]

Hallo Weingeist

 

Betreffend dem Robocopy Parameter /z /b, sprich, /zb

 

/Z :: Kopiert Dateien im Neustartmodus = würde ich umbedingt belassen, da gemäss meiner Erfahrung immer vorkommen kann, dass warum auch immer, beispielsweise ein Netzwerkunterbruch eintritt und somit erlaubt der Parameter /z den Neustart, sprich, beginnt nicht wieder von vorne den ganzen Karspumpel zu kopieren, sondern fährt dort weiter, wo robocopy zuletzt unterbrochen wurde

/B :: Kopiert Dateien im Sicherungsmodus = diesen Modus würde ich immer anwenden, da gibt es keine Probleme beim Kopieren (meine Erfahrung)

 

Die Lösung habe ich mittlerweile gefunden, da ich mich ebenfalls in meiner Umgebung mit dem Sicherungstool wbadmin.exe beschäftige und mittlerweile so erfolgreich DCs, Memberserver und Windows 7 Gerät auf meine externe HD sichere.

 

Da stellte ich fest, dass

der wbadmin.exe Backup Job auf einem Memberserver nur erfolgreich sichern kann, wenn der backup Benutzer den Skript, welcher wbadmin.exe aufruft

> beispielsweise in der Aufgabenplanung im Reiter Aktionen steht: C:\Skripte\fullbackup-serverXY.bat (im Gegensatz zur Aufgabenplanung bei Windows 7, hier muss der Aufrug anders geschehen, siehe weiter unten das Beispiel)

> in der Aufgabenplanung der Task mit erhöhten Admin Rechten ausgeführt wird (Feld Allgmein -> mit höchsten Berechtigungen ausführen)

> der Backup Benutzer in der lokalen Gruppe Sicherungs-Operatoren Member ist

> der Backpu Benutzer auf dem Member Server das Recht hat, Auftrag als Stapelverarbeitungsauftrag auszuführen

 

 

beim Windows 7 Notebook war im Vergleich alles gleich, bis auf den Aufruf für den Skript, welcher in der Aufgabenplanung wie folgt stehen muss, damit es funktioniert:

Reiter Aktion: bei Programm/ Skript disen Pfad hier angeben -> C:\Windows\System32\cmd.exe (Pfad zur cmd Datei, da zuerst das cmd aufgerufen werden muss)

dann im Feld: Argumente hinzufügen (optional) diesen Pfad hier angeben -> /c "c:\skripts\fullbackup-client.bat"

und zum Schluss, im Feld: starten in (optional) den  Pfad zum Verzeichnis angeben, in welchem sich die Batch Datei befindet, bei mir ist das: C:\Skripts\

 

Auch da wie schon erwähnt, alle Bedingungen müssen analog sein, wie beim Beispiel oben, wenn ich den Memberserver sichern möchte, also auch da: unter anderem muss der backup Benutzer auch da in der lokalen Sicherungs-Operatoren Gruppe sein (habe hier wie auch beim Member Server die DomänenLokale Gruppe DL_Backupgruppe da hineingepflanzt)

 

Im Gegensatz dazu muss auf einem DC die Gruppe oder der backup Benutzer NICHT in der lokalen Sicherungs-Operatoren Gruppe sein, da reicht es aus, wenn dieser in der DomänenLokalen Gruppe Sicherungs-Operatoren ist!!

 

Das ist der springende Punkt, der Punkt, der springt :-)

 

Ansonsten der Rest wie üblich, der Backup Benutzer muss natürlich Schreibrechte auf dem Ziel Ordner haben, auch auf dem Quell Share ...

Hoffe, habe nichts vergessen, es geht, goil :-)

 

cheers

Andrew aus der Schweiz

[Weingeist 157]

Flag Z: Darüber lässt sich streiten. Die Performance geht manchmal doch spürbar in die Knie und ein Abgleich von bestehenden, bereits kopierten Dateien ist in der Regel Ratz-Fatz durch wenn nochmals gestartet werden muss.

Flag B: Das war nur als Test gedacht, weil er dann garantiert mit den Rechten des Users arbeitet. -->Fehlereingrenzung

 

Lokale Sicherungsgruppe auf den Maschinen: Nun, das hatte ich dich ja extra gefragt ob er oder die Gruppe das auf dem NB und auch anderen Maschine ist. ;)

 

Aber schön das es nun klappt. Die ganzen Vollberechtigungen würde ich für den BackupUser noch etwas begrenzen. Benötigt er imho nicht. Read auf Quelle und RWD auf Ziel sollte ausreichen.

bearbeitet 22. Februar 2013 von Weingeist