Systemabbild Win10 auf NAS

Status
Für weitere Antworten geschlossen.

Meteorman

Benutzer
Mitglied seit
16. Apr 2017
Beiträge
28
Punkte für Reaktionen
1
Punkte
3
Hallo

Hab ein Verzeichnis Backup auf der Nas erstellt in dem ich mein Systemabbild von win 10 speichern will.
Ich benutze das Win 10 eigene Backup und sichere über Netzwerkadresse.

Leider klappt es nicht, kommt immer eine Fehlermeldung " Auf das bereitgestellte Sicherungsmedium konnte nicht zugegriffen werden".
Aber einzelne Datei kann ich dorthin kopieren und es sind auch schon einige Daten des Backup geschrieben worden, also kann draufzugegriffen werden.

Irgendwelche Tipps?

Meteorman
 

Meteorman

Benutzer
Mitglied seit
16. Apr 2017
Beiträge
28
Punkte für Reaktionen
1
Punkte
3
Hallo

Danke für den Tipp aber ich bin normal anwender und hab von linux keine ahnung.
Kann doch nicht angehen das solch einfache dinge nicht möglich sind ohne linux kenntnisse.

Meteorman
 

Tinitus

Benutzer
Mitglied seit
14. Dez 2016
Beiträge
23
Punkte für Reaktionen
0
Punkte
0
Selbe Thematik bei mir. Würde auch gern eine Sicherung von meinem Win10 auf der NAS machen. Geht das echt nicht???
 

AndiHeitzer

Benutzer
Sehr erfahren
Mitglied seit
30. Jun 2015
Beiträge
3.214
Punkte für Reaktionen
503
Punkte
174
Entweder ne eigene Software einsetzen, hier bei mir rennt dazu AOMEI-Backupper.

Oder dem Windows-Rechner per iSCSI ein lokales Laufwerk unterschieben und dorthin die WIN-Sicherung 'lokal' schreiben lassen.

Un den Tipp in Heise ist auch nicht sooo falsch ...
Ein bissel einlesen und schlau machen tut nicht weh :rolleyes:
 

Benji86

Benutzer
Mitglied seit
27. Jun 2017
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Der Tipp in Heise erscheint mir schon falsch, zumindest ist es mir so nicht gelungen. Überhaupt könnte der Tipp durchaus etwas ausführlicher sein.

Ich musste ne ganze Weile recherchieren, bis mir überhaupt der Root Zugriff gelungen ist. Dann liegt die smb.conf nicht am angegebenen Speicherort, sondern in /etc/samba/. Habe sie dann editiert, wobei ich finde, dass auch der Hinweis, an welcher Stelle man "strict allocate = yes" einzuführen hat durchaus weiterer Erklärung bedarf. Schließlich noch das max. Protokoll wie angegeben geändert, sowohl NAS als auch Windows mal neu gestartet und weiterhin bricht das Backup mit dem altbekannten Fehler 0x807800C5 ab.

Wäre über nützliche Hinweise dankbar :)
 

chriwo

Benutzer
Mitglied seit
18. Feb 2014
Beiträge
14
Punkte für Reaktionen
0
Punkte
1
Hi Benji86,

hast du es zum laufen gebracht? ich habe das gleiche Problem habe Windows 10 1803 installiert und der Backup bricht immer mit der Fehlermeldung ab wenn das Systemabbild fast fertig ist...

Für Hilfe wäre ich dankbar:)
 

Benji86

Benutzer
Mitglied seit
27. Jun 2017
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Leider nicht, sorry.
 
Zuletzt bearbeitet von einem Moderator:

loetlampe

Benutzer
Mitglied seit
25. Okt 2013
Beiträge
121
Punkte für Reaktionen
1
Punkte
18
Ich kann an dieser Stelle immer nur wieder den Veeam Agent for Windows empfehlen. Kinderleicht und sehr praktisch.
 

ikorbln

Benutzer
Mitglied seit
26. Nov 2017
Beiträge
341
Punkte für Reaktionen
32
Punkte
28
Hallo,

Veeam kann ich nur empfehlen, geht sehr gut.
Ansonsten funktioniert bei mir die Lösung per ISCSI, geht auch relativ einfach.
 

Racing65

Benutzer
Mitglied seit
08. Jun 2015
Beiträge
83
Punkte für Reaktionen
8
Punkte
14
Hallo,

Acronis True Image kann das.
 

Luzzil

Benutzer
Mitglied seit
28. Jan 2013
Beiträge
43
Punkte für Reaktionen
0
Punkte
0
Der Heise Tipp funktioniert bei mir nicht. DSM 6.2. "strict allocate=Yes" ist in der [Global] section eingetragen. Die einzelnen Shares sind in der /etc/samba/smb.conf nicht vorhanden. "smb2&large MTU" ist aktiviert.
Gibts noch Hinweise?
 

Luzzil

Benutzer
Mitglied seit
28. Jan 2013
Beiträge
43
Punkte für Reaktionen
0
Punkte
0
Er scheint übrigens zunächst fertig zu werden. Kurz kommt die Meldung, die Sicherung sei abgeschlossen; dann gefällt es ihm aber doch nicht und er zeigt "nicht erfolgreich" ... an .
Alle Dateien im Ziel wurden vor dem Backup gelöscht.
 

Luzzil

Benutzer
Mitglied seit
28. Jan 2013
Beiträge
43
Punkte für Reaktionen
0
Punkte
0
Es läuft:
/etc/samba/smb.share.conf, benutztes share: strict allocate = yes
"Systemsteuerung/Dateidienste/Windows Dateidienst/Erweiterte Einstellungen“ “Max. Protokoll für Windows-Dateidienst“ auf “SMB 3” und min. Protokoll auf “SMB 1“ einstellen.
und einen Haken bei “Opportuunistic Locking aktivieren” setzen.
der Unterpunkt “SMB2 Lease aktivieren” bleibt deaktiviert.

Logs gibt es in C:\Windows\Logs\WindowsBackup
und in der Ereignisanzeige
 

JueRgenB

Benutzer
Mitglied seit
08. Mai 2013
Beiträge
22
Punkte für Reaktionen
0
Punkte
1
Hallo Luzzil,

mit welcher Windows Version ist dir das zuletzt erfolgreich gelungen?
 

Luzzil

Benutzer
Mitglied seit
28. Jan 2013
Beiträge
43
Punkte für Reaktionen
0
Punkte
0
Windows 10.
Allerdings sagt mein Netzwerk, dass das Systemabbild mit Windows 10 nicht sehr zuverlässig sei.
Aktuell bin ich wieder bei Disk2vhd; wobei ich dort keine Verzeichnisse ausschließen kann :-(
 

JueRgenB

Benutzer
Mitglied seit
08. Mai 2013
Beiträge
22
Punkte für Reaktionen
0
Punkte
1
OK Danke,

bei mir geht da nichts, egal wie alt/neu das Windows 10 ist.
Vielleicht mit dem Update 4 für 6.2.1 …

Mit einem Open-e DSS V7 war´s aber sofort (ohne smb.conf Anpassungen) lauffähig.

Ich will mal prüfen, ob das nicht besser läuft...
 

Mercator

Benutzer
Mitglied seit
17. Dez 2018
Beiträge
42
Punkte für Reaktionen
0
Punkte
6
Es läuft:
/etc/samba/smb.share.conf, benutztes share: strict allocate = yes
"Systemsteuerung/Dateidienste/Windows Dateidienst/Erweiterte Einstellungen“ “Max. Protokoll für Windows-Dateidienst“ auf “SMB 3” und min. Protokoll auf “SMB 1“ einstellen.
und einen Haken bei “Opportuunistic Locking aktivieren” setzen.
der Unterpunkt “SMB2 Lease aktivieren” bleibt deaktiviert.

Logs gibt es in C:\Windows\Logs\WindowsBackup
und in der Ereignisanzeige
Bei mir bringt das leider auch nichts. Genau die gleichen Einstellungen hatte ich sowieso schon standardmäßig - bis auf SMB3. Aber SMB3 ändert auch nichts. Am Ende des Schreibens des Systemabbildes (VHDX) kommt immer der "berühmte" Fehler 0x807800c5. (Wenn man kein VHDX schreibt, geht es, aber ohne das VHDX hat man ja keine volle Sicherung.)

In der Registry sehe ich dann noch, dass der "LastBackupResultHrDetailed" dazu der Fehler 0x80780081 ist, was aber letzten Endes auch nicht weiterhilft. Habe alle Tipps aus diversen Foren probiert, bisher immer ohne Erfolg. Der Tipp aus der c't ganz vorne bezieht sich auf uralte DSM-Versionen (vermutlich <= 4.x). Seither hat Synology einiges getauscht, u.a. die Versionen von Samba und glibc. Dadurch liegen u.a. die Konfig-Dateien woanders.

Das ganze Problem dreht sich ja eigentlich "nur" um die Behandlung von "Sparse"-Dateien durch den SMB-Server. Also hier der Samba unter Linux (DSM). "Sparse"-Dateien sind Dateien die ein große Anzahl von "Lücken" (leeren Blöcken) beinhalten, wie bei Systemabbildern wie VHDX. Für die "Lücken" wird dann kein realer Platz beleget. Die Option "strict allocate = yes" bewirkt, dass Samba bei der Erzeugung der Sparse-Dateien für die Lücken Platz alloziert, wie ein Windows-Dateiserver. Während bei "no" kein Platz alloziert wird und dabei eine Datei angelegt wird, die nominell (scheinbar) so groß wie das System-Image ist, aber real für alle Lücken keine Blöcke (Sektoren) auf den Platten belegt. Wenn der Client (hier Windows Backup) nicht mit solchen Lücken-Dateien umgehen kann, kommt er aus dem Tritt. Daher sollte strict allocate = yes das ja auch lösen und hat es anscheinend auch eine Zeit lang. Ich sehe auch den Unterschied beider Optionen beim Anlegen (bei "no" wird sofort die große VHDX-Datei angelegt, bei "yes" wächst sie langsam).

Trotzdem kommt am Ende immer der obige Fehler. Meist erst am Ende der Sicherung, manchmal schon schneller. Was ich dabei auch nicht verstehe ist, dass die Option "strict allocate = yes" eigentlich von Samba selber seit Version 3.5.7 aus Performance-Gründen auch für Linux selber die empfohlene Einstellung ist, insofern das darunterliegende Dateisystem sogenannte "Extends-based allocation" unterstützt, was u.a. für ext4 und BTRFS gilt (für ext3 z.B. nicht).
(Siehe ausführliche Erklärungen hier im Samba-Wiki: https://wiki.samba.org/index.php/Linux_Performance)

Kurioserweise gibt es im DSM unter Systemsteuerung => Dateidienste => SMB => Erweiterte Einstellungen auch die Option "Beim Erstellen von Dateien keinen Speicherplatz reservieren". Wenn man die anhakt, wird vom DSM die Option "strict allocate = no" in eine Datei /etc/samba/smbinfo.conf geschrieben, die angelegt wird, wenn sie nicht schon da ist. Entfernt man den Haken wieder, wird die Option nicht auf "yes" geändert, sondern ganz entfernt. Es sieht fast so aus, als würde Synology annehmen "yes" ist der default-Wert. Ist es aber bei Samba nicht. Es sei denn Synology hat das für die eigene Version geändert. Dagegen spricht aber das unterschiedliche Verhalten.

Apropo Synology-Version von Samba:

In DSM 6.2.1 ist aber Samba 4.4.16 ("Synology Build 23824, Oct 26 2018 20:04:21"). Die glibc ist 2.20-2014.11. Also beides neu genug.

Bei mir: NAS: DS214play mit DSM 6.2.1-23824 Update 2, 2x Platten, ein Volumen mit ext4 formatiert. Der Client mit Windows Backup ist Windows 10 Pro Version 1803.

Gut wäre zu wissen, ob es ein generelles oder versionsspezifisches Samba-Problem ist oder ein Problem des Synology-Builds von Samba. Denn ich bin nicht sicher, ob es wirklich noch die gleiche Ursache ist, wie früher oder eine neue "Verschlimmbesserung". Ich hätte zwar auch andere Linux VMs mit Samba zum Vergleich aber aktuell keine mit genügend Platz, dass da ein volles VHDX draufpassen würde und Sicherungen ohne VHDX sind ja eh kein Problem.

Meine DS1618+ ist jedoch schon unterwegs. Dann wechsele ich auch auf BTRFS und schaue dann mal weiter...
 

Luzzil

Benutzer
Mitglied seit
28. Jan 2013
Beiträge
43
Punkte für Reaktionen
0
Punkte
0
Deinen Weg ging ich auch lange. Alles rausgesucht, getestet, Versionen geprüft, ... Letzendlich gings. Nutzen tue ich es nicht, weil mir ein Windows Admin gesteckt hat, dass er das Systemabbild mit Windows 10 nicht nutzt, da es dort öfter mal nicht retaurierbar ist.Und was bringt es mir dann? Sein Bild wurde von diversen Postings im Netz bestätigt.
 

Mercator

Benutzer
Mitglied seit
17. Dez 2018
Beiträge
42
Punkte für Reaktionen
0
Punkte
6
Also ich habe das mitgelieferte Windows Backup für Windows 7 und Windows 10 einige Male zum Restoren von Systemen benutzt. Also nicht nur getestet, sondern auch im "Ernstfall" wiederhergestellt. War nicht sehr oft, aber es hat für mich bislang immer funktioniert mit verschiedenen PCs und Laptops - nicht nur für mich selber.

Man sollte natürlich darauf achten, dass das System vor der Sicherung nicht korrupt ist. Sollte man aber sowieso. Ja, es ist recht einfach, aber funktional. Dass man ein VHDX bekommt, was man im Notfall auch anderweitig mounten kann, fand ich immer einen Vorteil.

Klar gibt es viel "Rauschen" im Netz, wie zu jedem Thema und jeder hat irgendeine Meinung/Erfahrung/Anekdote, wo die näheren Umstände selten im Detail beschrieben werden, aber die ich ja auch niemandem nehmen will. Trotzdem ist es für mich nicht einsehbar, dass das direkte Sichern auf Synology nicht (mehr) funktioniert.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat