none
Windows Server Sicherung schlägt fehl mit "Fehler beim Komprimieren der virtuellen Festplatte am Sicherungsspeicherort" RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe bei einem virtuellen Windows Server 2012 R2 ein Problem mit dem Backup. Der Server ist eine virtuelle Maschine auf einem Windows Server 2012 R2 Hyper-V vom Typ 2. In der virtuellen Maschine ist das Sicherungslaufwerk per iSCSI angebunden.

    Komisch ist, dass das Backup mit Warnungen abgeschlossen wurde. Alle Elemente wurden vollständig gesichert: EFI, C:, D:, Wiederherstellung, Bare-Metal, Systemstatus. Der Sicherungstyp war bei allen Vollständig. Der Problemfall ist Laufwerk D. Laufwerk D ist wie Laufwerk C eine eigenständige VHDX Datei auf dem Hyper-V-Server (ganz normal auf einem RAID5) mit fixer Größe. Bei Laufwerk 'D' steht in der Zusammenfassung bei "Übertragene Daten" 307,63 GB von 307,63 GB. Bei allen anderen stehen nur die Werte (ohne von).

    Im Tab "Fehler" (den Fehler finde ich sonst nicht! - kein Log oder Protokolldatei steht das) steht dann nur D: "Fehler beim Komprimieren der virtuellen Festplatte am Sicherungsspeicherort. Detaillierter Fehler: Ein an das System angeschlossene Gerät funktioniert nicht." Die Protokolldatei Backup_Error-<Datum>.log ist leer. In Backup-<Datum>.log steht:

    Das Volume "\\?\GLOBALROOT\Device\HarddiskVolume2\" wurde erfolgreich gesichert.
Das Volume "C:" wurde erfolgreich gesichert.
Das Volume "\\?\Volume{1660126e-61c4-4187-bbea-e7ed3911e5b2}\" wurde erfolgreich gesichert.
Das Volume "D:" wurde erfolgreich gesichert.

    Zeitlich erscheint mir aber alles in Ordnung zu sein. Das Backup dauert gerade mal von 5 Uhr bis 6:24 - also recht fix. Ich bin echt ratlos. Beim Starten einer Wiederherstellung taucht das Laufwerk auch nicht auf. Die Sicherung hat seit der Einrichtung (Das System ist sehr neu im Betrieb) 2 mal in Folge nach der manuell gestarteten Initialsicherung funktioniert. Ich tippe mal, wenn ich die Sicherung auf dem Laufwerk lösche und somit eine komplett neue starte, würde es wieder gehen - habe ich natürlich noch nicht gemacht und würde ich gerne auch vermeiden.

    Was soll ich unter "Sicherungsleistung optimieren" (unter Aktionen "Leistungseinstellungen") konfigurieren? Zurzeit ist noch "Normale Sicherungsleistung" eingestellt. Könnte es etwas bringen "Schnellere Sicherungsleistung" einzustellen? Dann würde hier unter Umständen eine inkrementelle Sicherung gemacht werden. Das wäre so nicht das Problem - habe ich nur nicht gemacht, da es sich hier um einen DATEV File-Server handelt, welcher mit vielen Datenbanken arbeitet, wo "nur Änderungen der Dateien sichern" aus meiner Sicht nicht viel Sinn machen.

    Auf dem früheren System (SBS 2008 - auch virtuell) wurde das auch so gemacht - da gab es die Schwierigkeiten nie. Die LUN wurde neu für das System auf der Storage angelegt.

    Für jede Hilfe bin ich dankbar.

    Zusatz:

    Nach ein wenig Suchen bin ich im Log auf den Fehlereintrag gestoßen. Unter VHDMP: Error ID 5; Quelle VHDMP; "

    Fehler beim Compact der virtuellen Festplatte "X:\WindowsImageBackup\s-datev-1\Backup 2015-02-05 212701\945f1898-fe57-4bce-ac96-77b594e53cd3.vhdx". Fehlerstatus "0xC0000001".

    "


    Donnerstag, 5. Februar 2015 18:34
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    So. Ich habe jetzt sehr lange mit einem Kollegen telefoniert, welcher ähnliche Probleme mit dem Backup gehabt hat. Ich bin mir jetzt ziemlich sicher, dass es am RAM liegen kann. Zwar ist es in dem Fall etwas merkwürdig - aber dennoch möglich.

    Die Maschine besitzt 48 GiB RAM und hat eine Auslastung von 87%. Immerhin sind noch 6 GiB RAM frei, was auch nicht zu verachten ist. Aber ich habe erfahren, dass der "compact"-Vorgang (komprimieren ist da nicht die beste Übersetzung) doch einiges an Ressourcen erfordert. Bei dem compact-Vorgang steigt der Arbeitsspeicheranteil "geändert" extrem stark an (zu sehen im Taskmanager im Tab Leistung im Diagramm "Speicherzusammensetzung").

    Zu beachten ist, dass eine komplette Vollsicherung auf eine leere Platte und eine komplette Vollsicherung auf eine mit Backup belegten Platte etwas anderes ist. Da eine Vollsicherung des Datenträgers "D" nicht möglich war, war auch kein Inkrementelles Backup möglich, was die nicht geänderte Leistungskonfiguration des Laufwerks "D" erklärt.

    Ich werde jetzt abwarten, ob das Problem bei der nächsten Vollsicherung (14 Tage oder ähnlich) noch einmal auftritt und werde dann den maximalen Arbeitsspeicher der SQL Servers von DATEV runtersetzen. Ich habe nämlich den maximalen Speicherverbrauch der DATEV SQL Instanz erst später geändert, weil dieser mit 8 GiB Initial belegt war (weil der Server zu beginn mit 8 GiB konfiguriert wurde).

    Aber ich bin optimistisch, dass es am freien Arbeitsspeicher liegt. An der detaillierten Protokollierung und Nachvollziehbarkeit des Windows Backups liegt die Erkenntnis auf jeden Fall nicht!


    Freitag, 6. Februar 2015 19:11
    |
  • Question
    Anmelden
    1
    Anmelden

    Die Idee mit dem RAM war leider nicht von Erfolg. Ich habe den Arbeitsspeicher des SQL Servers runtergesetzt und habe vorgestern bemerkt, dass das Backup fehlgeschlagen ist. Ich habe dann den SQL Server Dienst runtergefahren und das Backup von Hand gestartet. So waren circa 42 GiB RAM frei, was ja wohl mehr als ausreichend ist. Der Fehler ist dann wieder der gleiche gewesen.

    Die Aufteilung des Arbeitsspeichers war dann wie folgt: Geändert 6 bis maximal 20 GiB, 4 GiB in Verwendung und der Rest Standby. Wie auch immer - es hat nicht funktioniert. Selbst den blöden McAfee habe ich deinstalliert - hat den Server auch nicht interessiert, es ging immer noch nicht.

    Ich habe jetzt ein wenig "getrickst" und habe die iSCSI-Verbindung an der virtuellen Maschine getrennt und habe die LUN am Hyper-V Server angeschlossen und habe eine VHDX-Datei auf der LUN erstellt und diese am Server eingehängt. So hat die virtuelle Maschine mit dem iSCSI nichts mehr zu tun. Sollte es generell an der iSCSI-Technologie liegen besteht zumindest die Chance, dass es dann geht.

    Wenn es dann immer noch nicht geht, weiß ich nicht mehr weiter. Mal abwarten.

    Donnerstag, 12. Februar 2015 21:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Markus,

    wenn Sie eine Lösung gefunden haben, bitte teilen Sie sie der Community mit, sodass auch andere Benutzer als der Fragesteller davon profitieren können.

    Bitte beachten Sie, dass ich wegen keiner weiteren Aktivitäten das Thema als Diskussion verschieben werde. 

    Gruß,

    Teodora

    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 25. Februar 2015 11:40
    |
    Moderator
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    was spricht denn dagegen, das iScsi am Host einzubinden und am Host das Windowsbackup zu nehmen und damit die VM als solche zu sichern?

    Mittwoch, 25. Februar 2015 12:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Auch das funktioniert nicht. :( Es geht einfach nicht und ich verstehe es nicht. Mir ist aufgefallen, dass ich dieses mal vergessen hatte die VSS-Vollsicherung anzuschalten. Die Sicherung lief als VSS-Kopie-Sicherung und ich dachte, dass es deswegen jetzt funktioniert. Aber heute war wieder das tolle Warndreieck zu sehen. *seufz*

    was spricht denn dagegen, das iScsi am Host einzubinden und am Host das Windowsbackup zu nehmen und damit die VM als solche zu sichern?

    OK - eine Sicherung der virtuellen Maschine. Ich dachte, dass das Wiederherstellen einzelner Dateien aus dem Backup der virtuellen Maschine vom Host aus schwieriger wird, als wenn ich einfach das Backup in der Maschine selbst einrichte.
    Habe ich denn auch einen Versionsverlauf der Dateien, wenn ich vom Host die Sicherung starte?

    Aus meiner Sicht fehlen mir jetzt weitere Optionen/Lösungsansätze, um das Backup ordnungsgemäß durchführen zu können.

    Mittwoch, 25. Februar 2015 14:03
    |
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    ja das Wiederherstellen einzelner Dateien ist dann tatsächlich etwas umständlicher. Aber für den Totalausfall der VM sicher noch die eleganteste Lösung.

    Recovery Prozedere wenn deine VM nicht mehr bootet wäre dann aufwendiger.

    Wieviele VM's hast du denn auf dem Host?

    Ich kenn da ein ausgezeichnetes 3rd Party BackupTool dass auf dem Host installiert wird. Damit kannst du auch Exchange Item-Level Restore machen und es hat wirklich einen fairen Preis, bzw. ist bis 2 VMs gratis. :)

    Mittwoch, 25. Februar 2015 14:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Das müssten 6 Stück sein. Aber nicht alle sind so wichtig, dass eine tägliche Sicherung erforderlich ist. Auf einen externen Datenträger werden einmal wöchentlich alle virtuelle Maschinen über den Host mit Windows Backup gesichert (das klappt ja so weit auch). Das sind Maschinen wie eine Zertifizierungsstelle (in dem Unternehmen passiert nicht sehr viel mit der CA), ein Server für Zeit Erfassung und Terminal Server. Bei diesen Maschinen reicht eine wöchentliche Sicherung aus.

    Das eine Datenwiederherstellung umständlicher ist - OK. Das wäre nicht so das große Problem. Ich gehe mal davon aus, dass ich ggf. einen alternativen Wiederherstellungsort der VM auswähle und diese VHDX dann in die Maschine einbinde und mir dann die Daten da raus kopiere. Ist die Sicherung der VM in mehreren Versionen möglich oder sichert das Windows Backup da immer nur wegen der Größe eine Version? Also kann ich eine Hyper-V Maschine von vor 3 Tagen (z.B.) wiederherstellen oder ist bei Wiederherstellung einer Hyper-V Maschine das Datum nur "Zierde"?

    Abgesehen davon, wie lautet denn der Name der Sicherungssoftware?

    Mittwoch, 25. Februar 2015 14:42
    |
  • Question
    Anmelden
    0
    Anmelden

    Also einen Tag danach ging es wieder (gerade die Vollsicherung ging), dann - nach der erfolgreichen Vollsicherung - wieder nicht (so ist die Theorie, dass es bei großer Datenmenge nicht funktioniert auch vernichtet). Mir geht das jetzt ziemlich auf den Keks und habe daher das Backup auf den Hyper-V verlegt und sichere eine Auswahl an wichtigen virtuellen Maschinen täglich auf die Storage. Das braucht mehr Platz und dauert erheblich länger - aber OK.

    Was mich eher stört ist die Tatsache, dass ich überhaupt nicht weiß, weshalb dieses Problem überhaupt da ist und was ich dagegen tun kann (außer nichts).

    Freitag, 27. Februar 2015 23:10
    |
  • Question
    Anmelden
    1
    Anmelden
    Moin, entschuldige das verspätete Feedback, ich weiß nicht ob die Forenregeln gestatten das Produkt hier zu verlinken. Aber eine Google Suche nach "hyper-v Backup" liefert das Ergebnis recht weit oben. Was dich vielleicht noch daran interessieren koennte ist, dass das Tool sehr gut komprimiert. auch verschlüsselt und Offsite kopieren kann. und die dailys sind bitweise Änderungen. Ansonsten faellt mir nur ein den Perfmon Serverseitig mal mitlaufen zu lassen und auch das Storage zu prüfen. Hast du statt des RAM vielleicht auch mal dir Auslagerungsdatei geprüft? Hat das Storage genug Platz?
    Samstag, 28. Februar 2015 07:54
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo,

    wahrscheinlich meinst du die Software Veeam, wovon ich auch schon öfter von anderen Administratoren etwas mitbekommen habe. Es scheint eine sehr professionelle und gute Software zu sein. Ich werde es auf jeden Fall im Hinterkopf behalten - preislich passt das zu der Kundengröße leider nicht.

    Was das Backup angeht funktioniert das Backup auf dem Hyper-V Host zumindest bislang (es sind ja auch noch nicht so viele Tage vergangen - nach einer Zeit wird man mit voreiligen Optimismus halt vorsichtig ;)).

    Zur Information. Auch hier ist einfach nur eine LUN (welche ich vorher auf der Synology NAS noch vergrößert habe) am Hyper-V Server über iSCSI eingebunden (bei mir als ReFS Laufwerksbuchstabe X formatiert). Da der geplante Backup-Job (Sicherungszeitplan) für die Vollsicherung auf die externen Festplatten belegt ist, habe ich manuell eine Aufgabe angelegt, welche auf die passenden Zeitpunkte triggert und folgenden Befahl ausführt:

    wbadmin.exe START BACKUP -backupTarget:x: -allCritical -vssFull -quiet -hyperv:{2604B2FB-4D27-4759-8A23-A65603820E9E},{63D41DE3-6092-4832-89AF-FB6E1A95E063},{D1ED153A-AC5E-47F3-AD26-ED8770AFA9E8}
    Der Vorgang dauert bei den 3 virtuellen Maschinen 5 bis 6 Stunden (meistens in etwa 820 GiB). Sehr ärgerlich ist an dem ganzen Problem wie gesagt, dass ich im Nachhinein noch nicht einmal weiß, warum das Backup in der virtuellen Maschine nicht funktioniert (vorher auf dem alten SBS ging die selbe Technik ja auch ohne Probleme). Ich habe ja nun wirklich alles ausprobiert und nichts hat geholfen.

    Donnerstag, 5. März 2015 11:53
    |
  • Question
    Anmelden
    1
    Anmelden
    nein. ich meinte nicht Veam. veam ist teuer ;) ich meinte altaro.
    macht super Backups. Komprimierung ist gigantisch. kann verschlüsselt speichern. auch Offsite. Und es kann sandbox restore der kompletten vm. item Level restore fuer Dateisystem oder sogar Exchange Elemente.
    lizenziert wird pro host (egal wieviel CPUs, usw). Es gibt 3 Lizenz Modelle; eine freie, eine mittlere und eine unlimited. Die freie kann 2 vms sichern. ich persönlich nutze garnichts anderes mehr zum sichern von hyper-v vms.
    Donnerstag, 5. März 2015 17:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Nach längeren Beobachtungen kann ich sagen, dass das Backup über den Hyper-V Host bis lang noch gut funktioniert. Ich gehe davon aus, dass es auch weiterhin so sein wird.

    Nur schade, dass ich nicht weiß, weshalb das Backup auf dem Gastsystem nicht funktioniert, ist mir nach wie vor schleierhaft. Sollte das Problem irgendwann wo anders noch einmal auftauchen, bringt mir die Erfahrung von diesem Fall nichts.

    Mittwoch, 11. März 2015 19:54
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo aus Wuppertal,

    ich hatte das gleiche Problem auf einem physischen Server (Windows Server 2012 Essentials), interessanterweise auch ein kleiner DATEV-Server; wir sichern um 00:00 Uhr lokal auf einer zweiten Festplatte und um 03:00 Uhr auf ein NAS mit Nachbargebäude.

    Nachdem ich mit wbadmin alle Backups, mit vssadmin alle Schattenkopien, manuell die "WindowsImageBackup"-Ordner an beiden Sicherungsorten gelöscht und das System neu gestartet hatte, war das Problem verschwunden.

    Das Phänomen trat in meinem Fall auf, nachdem vor Kurzem das NAS vollgelaufen war; danach funktionierten beide Sicherungsläufe nicht mehr.

    Viele Grüße
    Mike


    • Bearbeitet Mike Amend Samstag, 21. März 2015 00:45 Tippfehler :o)
    Freitag, 20. März 2015 17:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Und nach dem "Reset" der Sicherung - also das Löschen - geht es jetzt schon länger wieder?

    Sieht so aus als ob die Sicherung durch das vollgelaufene NAS defekt gewesen ist. Bei mir ist die NAS auf alle Fälle nicht voll gewesen. Ich würde mich wundern, wenn in dem Fall ohne irgendwelche erkennbaren Fehler die Sicherung so oft defekt ist.

    Ich hatte ja auch leider schon alles probiert und habe mich nun mit der Lösung abgefunden. Da parallel noch eine Sicherung auf die NAS (ebenfalls ein LUN fester Größe) mit dem DATEV Online Sicherung läuft, kann darüber auch eine Wiederherstellung laufen, sofern nur Daten wiederhergestellt werden müssen (diese Sicherung läuft aber nicht zeitgleich!). So geht das wenigstens schneller. Es wäre sehr ärgerlich, wenn ich die ganze VHD rücksichern müsste nur um 100 KiB Daten für einen User wiederherzustellen.

    Freitag, 20. März 2015 18:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich will es mal so sagen:

    Vorher produzierte jede Sicherung über Tage diesen Fehler und danach habe ich beide Sicherungen (00:00 Uhr und 03:00 Uhr) manuell je 3x ausgeführt ohne einen einzigen Fehler; inzwischen sind die Sicherungen auch automatisch jeweils 2x ohne Probleme durchgelaufen.

    Ich bin sehr optimistisch, dass das Thema durch ist.

    In einer Woche gebe ich aber gerne nochmal eine kurze Rückmeldung, okay?

    Samstag, 21. März 2015 00:44
    |
  • Question
    Anmelden
    0
    Anmelden
    Ja, das wäre ganz interessant. Bei mir tauchte der Fehler immer wieder und wieder auf. Nach wie vielen Sicherungsläufen weiß ich nicht - warden so 5 bis 7 gewesen sein.
    Samstag, 21. März 2015 10:15
    |
  • Question
    Anmelden
    0
    Anmelden

    In der letzten Nacht sind die Sicherungen Nr. 7 und Nr. 8 ohne Probleme durchgelaufen...

    Update in Kürze.

    Sonntag, 22. März 2015 14:02
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke für die Info. Das sieht für mich dann so aus als wenn bei euch dieser Fehler durch einen nachvollziehbaren Grund aufgetreten ist und sich beheben lies. Zumindest läuft die Sicherung auf die gleiche NAS über iSCSI auf dem Hyper-V Host immer noch erfolgreich durch.

    Montag, 23. März 2015 16:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Kurze Abschlussmeldung: Sicherung 14 und 15 sind nun auch erfolgreich durchgelaufen...

    Für mich ist das Phänomen damit erledigt.

    Dir wünsche ich noch viel Erfolg.

    Mike

    Donnerstag, 26. März 2015 00:04
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich habe heute weniger erfolgreich nach Lösungen von "Sicherungsdatenträger nicht gefunden"-Meldungen gesucht. Bei dem Problem bin ich auf Meldungen anderer Benutzer gestoßen, dass ein eventuell fehlender Support des SMB3 Protokolls von der Synology/QNAP NAS damit zusammenhängen könnte.

    Das lässt mich vermuten, dass das auch hier - bei dem "Komprimieren der VHDX" - ein Problem sein könnte. Die Synology NAS unterstützt immer noch kein SMB3, was aber wohl mit der Firmware DSM 5.2 mittels Samba 4 in Grundzügen nachgereicht werden soll.

    Das ist zumindest der noch letzte verbleibende Lichtrest, den ich noch sehe.



    Mittwoch, 1. April 2015 16:51
    |
  • Question
    Anmelden
    1
    Anmelden

    Wenn die neueste SMB-Version nicht unterstützt wird, fällt der Server automatisch auf eine ältere Version zurück. Daran sollte es nicht liegen. Hast du dir das Logfile des Backup angesehen? Da stehen Details drin. Die Files liegen im Ordner C:\Windows\Logs\windowsServerBackup.

    Ich hatte auch schon das Phänomen, ich meine da kam auch eine "Sicherungsdatenträger nicht gefunden"-Meldung, dass das Backup fehlerhafte Infos auf das Sicherungsziel geschrieben hat. Nach dem Löschen des Sicherungsjobs und dem konfigurieren eines neuen Jobs mit leerem Sicherungsziel hat dann wieder alles funktioniert.

    Ich habe alle Beiträge überflogen. Sorry, wenn ich dennoch eine Frage wiederholt gestellt habe.

    Gruß,
    Matthias

    PS: Du kannst ja testweise Perf Logs konfigurieren, um zu sehen wie es sich mit den Ressourcen während des Backups verhält. Möglicherweise gibt das Aufschluss.


    Mittwoch, 22. April 2015 11:35
    |
  • Question
    Anmelden
    0
    Anmelden

    Bei einer Sicherung via Sicherungszeitplan auf unserem DATEV-Server hatte ich bis eben die gleichen Symptome - bis ich:

    • das DATEV-Daten-Laufwerk einmal aus dem Plan raus genommen habe
    • eine Einmalsicherung nach "Optionen für geplante Sicherung" gefahren hatte (quasi nur noch Bare-Metall-Recovery, Systemstatus, Systemlaufwerk und System-reserviert - aber halt ohne E: [DATEN])
    • und das Laufwerk danach wieder in den Zeitplan mit rein genommen habe.

    (Zuvor hatte ich geprüft, ob tatsächlich nur das komprimieren nicht klappt, oder aber tatsächlich gar nicht gesichert wird - da aber trotz übertragener Daten nix widerherstellbar war - war es eigentlich egal, das Laufwerk temporär raus zu nehmen. 

    Danach lief die nächste Einmalsicherung nach "Optionen für geplante Sicherung" wieder sauber durch. Ob es jetzt bei der nächsten regulären Sicherung klappt, sehe ich morgen.

    Allerdings hat der Server auch etwas Vorgeschichte - nach dem Jahresupdate auf DATEV 9.0 wollte die Sicherung gar nicht mehr. Ursache war der zunächst nicht mehr laufende VSS System Writer, den erst der Hotfix KB2807849 wieder an den Start brachte. (Für Server 2012 nimmt man die win8 x64-Version). Im Anschluss lief der VSS System Writer wieder (Allerdings mit einer Fehlermeldung, die eigentlich auf einen nicht ganz sauber deinstallierten DHCP hindeuten (ID 8193 -0x80070005) - Entsprechend wurde noch die Berechtigungen unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Diag für den Netzwerkdienst gegeben.

    Da im Zuge der Automatisierung des DATEV-Jahres-Updates auch gleich die aktuellen DATEV-Hotfixes eingespielt und alle Arbeitsstation aktualisiert werden und nachdem das zu laufen schien, auch gleich noch ein SQL-Server-Update, dass bereits mehrere Monate zuvor erschienen und seitens der DATEV nicht auf der Liste stand/steht, installiert wurde, kann ich leider nicht mehr exakt bestimmen, wann/weshalb die Sicherung/VSS abgeschmiert ist. Erster Ansatzpunkt war halt KB2009272, das lief aber nur bis zum vierten Punkt (icacls %windir%\wins.... BUILTIN\Users...) was mich auf den MS Hotfix brachte. In der Registry hatten Networkservice und Local Service unter VSS bereits ausreichend Berechtigungen, .NET-Temp-Files waren auch keine vorhanden.

    P.S. - was mir bei den Bildern auffällt ist, dass das Sicherungslaufwerk wohl einen Laufwerksbuchstaben zugeordnet bekommen hat - ohne einen solchen ist zwar der Zugriff via Explorer, etc. nicht möglich - aber so kann dann auch sonst kein Tool/etc., die während der Sicherung auch gar keinen Zugriff haben sollen, darauf zugreifen. Sicherungslaufwerken gibt man praktisch nur temporär einen Buchstaben, wenn es aus Wartungsgründen notwendig ist. 
    • Bearbeitet Nehl Dienstag, 29. September 2015 18:50
    Dienstag, 29. September 2015 18:28
    |