Hallo in die Runde,
ich habe durch trial&error den Verdacht, dass die Windows Server Sicherung (im Folgenden WSS) empfindlich darauf reagiert, wenn man in einen mit samba bereitgestellten share sichert, der auf einem md-Raid liegt.
Dazu habe ich eine SATA-HDD und eine USB3-HDD als md-Raid-1 (weil ich dann wöchentlich durch Auflösen und neu Zusammensetzen des Raid eine Platte der Datensicherung extern lagern kann). Sichere ich mit WSS nun über den share auf dieses Raid, gelingt mir das vielleicht in 1 von 10 Fällen, die anderen 9 brechen nach verschiedenen Volumina (7-24gb) mit "Netzwerkfehler, Prüfen Sie den Zugriff auf das Zielmedium" ab. Sichere ich auf einen share, dem kein md zugrunde liegt, sind 5 von 5 Sicherungen erfolgreich.
Warum ist nun wahrscheinlich md (mit)schuld? - ich habe dem Raid die USB-Platte entnommen und ohne Erfolg gesichert - ich habe dem Raid sie SATA-Platte entnommen und ohne Erfolg gesichert - ich habe die entnommene SATA-Platte (auch) mit ext4 formatiert und mit Erfolg gesichert - ich habe das selbe mit der USB-Platte auch erfolgreich hinbekommen = Ports, Geräte, Dateisystem, Anbindung (Netzwerk), Sicherungsclient und -Software waren dabei immer identisch
Und warum könnte samba (mit)schuldig sein? - ich konnte auf das md-Raid direkt (also ohne samba dazwischen) größere Datenmengen mit rsnapshot (rsync) sichern, was mich einen Zusammenhang zwischen samba und md oder WSS (also der Art, wie das auf Storage wirkt) und md vermuten lässt.
Nun zur Frage: Hat einer ähnliches erlebt und gelöst oder zumindest Ideen ob man mit (welcher?) Parametrierung an samba bzw. md da noch irgendwas experimentieren kann? Ich habe ja nichtmal eine Idee, wieso sich rsync und WSS unterschiedlich auswirken (rsync in kleinen Blöcken, WSS als Stream?).
ps : Das obige Vorhaben hat mit Debian Stretch funktioniert, seit Buster habe ich die Probleme; in beiden Fällen nutze ich den gleichen selbstgebackenen Kern - es hat sich also vor allem samba geändert (vllt. auch Kernelparameter dank sysctl oder systemd).
pps : ich nutze eigentlich zusätzlich noch die ex4 Verschlüsselung und musste beim Wechsel auf Buster feststellen, dass der smbd nun nicht mehr den Schlüsselring des Nutzers "erbt", vielmehr hat Pöttering da was am Verfahren geändert und den Unit-Parameter KeyringMode vorgesehen, den ich nun auf "shared" setzen muss. Sicher bin ich nur zu einfältig, aber systemd k***t mich an - angetreten um init zu ersetzen ist das inzwischen ein halbes Betriebssystem und widerspricht Teilen der Unix-Philosophie.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8