Veeam Agent Backup auf NAS schlägt fehl

RedPanda

Ensign
Registriert
Apr. 2020
Beiträge
131
Hallo alle zusammen,

ich versuche aktuell mehrere Windows 10 Clients mit Hilfe der Software Veeam Agent for Windows free auf einen lokalen NAS zu sichern.
Der NAS und die Software sind auch soweit konifguriert, allerdings bricht das Initialbackup jedes mal nach ein paar Minuten mit folgendem Fehler ab:

"Error: Shared memory connection was closed Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. Exception from Server: Unerwarteter Netzwerkfehler Failed to write data to the file [NAS IP\Shared Folder\Job Name\xxx.vbk]. | Cannot handle notification about a written block. Failed to download disk."

Veeam legt dabei jedes mal erfolgreich einen Backup Ordner auf dem über den NAS bereitgestellten Ordner an, sichert die Efi Partition und bricht dann iergendwann beim sichern der C: Partition ab (Fortschritt zwischen 90MB - 1,3GB).

Kurz zu dem Setup:
In der Umgebung befinden sich mehrere Windows 10 Clients. Alles HP ProDesk 400 G6 mini Geräte. Diese sind per Wlan mit dem lokalen Netz verbunden. In dem selben Netz befindet sich auch ein lokaler NAS, ein Synology DS218 (DSM7).
Als Router hantiert ein Linksys WRT45GL im Netzwerk. Sämtliche Geräte besitzen eine statische IP-Adresse.
Der NAS stellt im Netzwerk 2 Shared Folder über SMB zur verfügung. Jeweils einen Ordner für den Datentransfer zwischen den einzelnen Clients und einen weiteren verschlüsselten Ordner als Ziel für die Backups. Der NAS ist mit btrfs formatiert. Für die Freigabe auf beide Ordner wurde auf dem NAS ein Benutzer angelegt, welcher auf beiden Ordnern read/write Rechte besitzt und von sämtlichen Clients (inkl. dem Veeam Agent auf sämtlichen Clients) eingesetzt wird.
Der Veeam Agent soll nun 2x die Woche die Clients aus dem Ruhezustand aufwecken und ein Fullbackup auf dem NAS ablegen (1x Active Fullbackup pro Monat).

Durch etwas Recherche bin ich nun schon auf den ein oder anderen Lösungsansatz gestoßen, allerdings ließ sich das Problem bis jetzt nicht lösen.

Folgende Dinge habe ich bereits ausprobiert:
  • Backup von anderem Client (selbe config) aus getestet -> selber Fehler
  • Windows 10 und Treiber aktualisiert -> 21h1 - Treiber aktuell laut HP Support Assistent
  • Windows 10 Festplatte bereinigt (Update-Dateien, Temporäre Dateien usw.)
  • Energieverwaltung für Intel AX201 Wifi Karte deaktiviert ("Computer kann das Gerät auschalten, ...")
  • chkdsk /f und DISM /Online /Cleanup-Image /CheckHealth -> keinerlei Fehler gefunden
  • Testdatei (~20 Gb) manuell auf den Backup Ordner hochgeladen -> erfolgreich
  • Veeam Agent Backup Job neu erstellt
  • Veeam Agent neu installiert
  • Datei Checksumme für den freigegebenen Ordner auf NAS deaktiviert
  • Speicherplatzreservierung für Dateien auf NAS deaktiviert
  • Ordner + Benutzer auf NAS neu angelegt
  • Papierkorb in freigegebenem Ordner entfernt

So langsam bin ich mit meinem Latein wirklich am Ende und würde mich über jegliche Hilfe freuen :)
 
Zuletzt bearbeitet:
Der spezifische Fehler ist mir bisher nicht über den Weg gelaufen.

Hast du schon die Agent Logs geprüft, ob da mehr Details zu finden sind? Die sind standardmäßig in diesem Pfad gespeichert: C:\Programdata\Veeam\Endpoint

Sonst - schonmal den KB durchgelesen?
https://www.veeam.com/kb1735

Mal die Laptops per Ethernet-Kabel statt wlan angebunden?
Auf iSCSI statt SMB Share umsteigen dürfte bei dir wohl leider wenig praktikabel sein...
 
Rickmer schrieb:
Hast du schon die Agent Logs geprüft, ob da mehr Details zu finden sind? Die sind standardmäßig in diesem Pfad gespeichert: C:\Programdata\Veeam\Endpoint

Sonst - schonmal den KB durchgelesen?
https://www.veeam.com/kb1735
Hatte da mal kurz einen Blick reingeworfen. War da bloß ehrlich gesagt etwas "lost" bei der Menge an versch. Logs. Dann werde ich mich da mal noch durchwühlen :)

Auf den KB Artikel bin ich auch schon gestoßen:
- "Network issues ..."
--> Habe mal testweise manuell eine ~20 GB große Testdatei auf den selben Ordner hochgeladen (explorer.exe). Lief ohne Probleme durch.

Hatte mich auch während des Backups mal auf den Router (Linksys WRT45GL) aufgeschalten. Dieser meldet während dieser Zeit keine Fehler und ist auch durchgängig erreichbar.

- "Firewalls ..."
--> Habe testweise sowohl Firewall auf NAS als auch auf Client deaktiviert. Bricht immer noch mit selbem Fehler ab.

- "The NAS may stop responding..."
--> Der NAS ist während dem kompletten Backup Prozess über die WebUI noch ansprechbar. Auch Dateien hochladen auf den zweiten (Datentransfer) Ordner von selbem/anderem Client ist währenddessen noch möglich.

- "GPO security policies ..."
--> Standard Windows 10 Pro Installation. Mir sind aktuell keine Policies bekannt, die da dazwischen Funken sollten.

- "Limited timeouts/reconnects on SMB or TCP Layer ..."
--> Hier könnte ich mir sogar vorstellen, dass dies zutreffen könnte, allerdings bin ich mir nicht sicher wie ich das verifizieren soll.

Merkwürdigerweise bricht das Backup ja auch nicht jedes mal an der selben Stelle ab. Veeam ist in der Lage, die komplette EFI Partition des Clients auf den NAS zu sichern. Sobald dann die C: Partition dran kommt, bricht er aber nach einer zufälligen Zeit ab. Da war bis jetzt alles zwischen abbrechen nach lesen von 90MB bis 1,5 GB dabei.

Aktuell verwende ich (zu Testzwecken - wird noch geändert) ein und denselben Benutzer um sowohl den Datentransfer Ordner als Netzwerklaufwerk auf den Clients automatisch zu verbinden als auch innerhalb des Veeam Agents um das Backup auf dem Backup Ordner abzulegen. Gibt es hier ggf. eine Limitierung im SMB Protokoll dass hier dazwischen funken könnte?

Rickmer schrieb:
Mal die Laptops per Ethernet-Kabel statt wlan angebunden?
Auf iSCSI statt SMB Share umsteigen dürfte bei dir wohl leider wenig praktikabel sein...
Sind Mini-PC's. Würde diese auch gerne per LAN Kabel direkt verbinden, allerdings Lokationsbedingt (ohne große Umbauten, Kabel verlegen usw.) auf Dauer nicht möglich.
 
Zuletzt bearbeitet:
Zumindest mal mit Kabel testen, ob's dann weiterhin auftritt. Wlan kann ekelig sein.

Sonst würde ich es mal mit einem komplett anderen Client versuchen - am besten einen Laptop (etc) der in Verbindung mit einem anderen SMB Share schon getestet wurde und funktioniert. Dann weiß man ob's am NAS (oder Verbindung) oder an den Clients hängt.

Oder meinetwegen eine USB-Platte an einen der Clients hängen -> Netzwerkfreigabe -> von einem anderen Client darauf sichern versuchen, also mal das NAS komplett raus nehmen
 
  • Gefällt mir
Reaktionen: snaxilian
Rickmer schrieb:
Zumindest mal mit Kabel testen, ob's dann weiterhin auftritt. Wlan kann ekelig sein.

Sonst würde ich es mal mit einem komplett anderen Client versuchen - am besten einen Laptop (etc) der in Verbindung mit einem anderen SMB Share schon getestet wurde und funktioniert. Dann weiß man ob's am NAS (oder Verbindung) oder an den Clients hängt.

Oder meinetwegen eine USB-Platte an einen der Clients hängen -> Netzwerkfreigabe -> von einem anderen Client darauf sichern versuchen, also mal das NAS komplett raus nehmen
Werde ich auf jedenfall mal testen.

Konnte mich heute mal wieder remote auf einen der Clients aufschalten und habe dabei mal einen Blick in die Windows Ereignisanzeige geworfen. Dabei ist mir direkt aufgefallen, dass regelmäßig Fehlermeldungen bzgl. Netwtw10 im Log auftauchen.
Habe dann mal spaßeshalber ein Backup über Veeam gestartet und die Anzeige aktualisiert und es werden mir direkt 4 neue Fehler angezeigt, bevor nach einigen Minuten dann das Backup abbricht. Gehe also inzwischen davon aus, dass das Problem mit Veeam durch die Wlan Karte der Clients + Router das Problem verursachen.

Werde die Tage mal dort vor Ort vorbei gehen und das ganze dann per Kabel testen um meine Vermutung zu verifizieren. Ich poste hier mal die Fehlermeldungen der Ereignisanzeige, evtl. kann dazu hier jemand etwas sagen:

  • Netwtw10, Ereignis 5007 - TX/CMD Timeout (TfdQueue hanged)
  • Netwtw10, Ereignis 5005 - Intel Wi-Fi 6 AX201 160MHz: Interner Fehler aufgetreten
  • Netwtw10, Ereignis 5002 - Intel Wi-Fi 6 AX201 160MHz: Fehlfunktiond es Netzwerkadapetrs wurde ermittelt
  • Netwtw10, Ereignis 5005 - Intel Wi-Fi 6 AX201 160MHz: Interner Fehler aufgetreten

Interessanterweise treten die oben genannten fehler in regelmäßigen Abständen ind er Ereignsianzeige auf (alle paar Stunden). Veeam ist allerdings die einzige Anwendung, die ich bis jetzt in direkter Verbindung damit verifizieren konnte (und scheint auch die einzige Anwendung zu sein, die daraufhin den Dienst einstellt).
 
  • Gefällt mir
Reaktionen: Rickmer
@RedPanda
Hast du für das Problem eine Lösung gefunden?

Ich habe ein ähnliches Problem. Ich versuche gerade mit einem Full Backup neu zu starten bei Veeam und kriege es seit Tagen nicht hin. Die Read Rate ist mit 35 MB/s relativ niedrig und bei der entsprechenden Dauer rennt er irgendwann in den "Shared Memory Connection was closed." Fehler. Das merkwürdige ist aber die Tatsache, dass es zu unterschiedlichen Zeiten passiert. Ich habe es gestern über Nacht laufen lassen und bei 13h+ ist der Abbruch erst passiert. Heute dann nach knapp 2h. Die Rate ist am Anfang auch meist deutlich höher und sinkt dann aus welchen Gründen auch immer.

Interessanterweise habe ich deine Checkliste mehr oder weniger auch schon vollständig durch. Ich werde hier bald wahnsinnig ;)
Bei mir ist allerdings alles per Kabel verbunden. Gesichert wird ebenfalls auf ein Synology NAS. Auf das entsprechende SMB Share.

Das sieht dann so aus z.B.

1637526167560.png


Vllt. hat auch jemand anders noch Ideen.
 
@Phear
Ich kann es letztendlich nicht zu 100% genau sagen, vermute aber ein Problem zwischen dem Router und den Clients bzgl. des WLANs. Der Router selbst unterstützt lediglich 802.11 b/g während die Netzwerkkarten der Clients auf 802.11ax ausgelegt sind. In der Theorie müsste letzteres zwar backwards kompatibel sein, führt aber in der Praxis, laut Intel Support und etwaigen anderen Forenbeiträgen (-> Google Suche), des öfteren zu Problemen.
Hatte zum verifizieren dann testweise die Clients direkt per Netzwerkkabel an den Router angeschlossen und seitdem funktionieren die Backups auf den Synology NAS ohne Probleme. Habe danach allerdings keine weiteren Tests mehr durchgeführt.

Was ich allerdings bis heute nicht verstehe ist, warum in meinem Fall lediglich Veeam komplett den Dienst versagt hat. Ich bin ja in meinem Post vom 13.09. auf die Netwtw10 Ereignisse im Ereignisslog gestolpert. Habe letztendlich herausgefunden, dass diese immer wieder dort auftauchen, sobald man auf den Clients irgendeine Software, welche Netzwerkaktivität besaß, ausgeführt hat. Nur hat man das in z. Bsp. Outlook, Firefox usw. schlichtweg nicht bemerkt, da diese deswegen nicht direkt abgestürzt sind oder einen Fehler gemeldet haben. Die haben das wohl von selbst gehandelt bekommen. Aber bei Veeam -> Totalausfall.
Habe auch den Veeam Support mal danach angefragt, die haben mir aber nur nach 2 Monaten mitgeteilt, dass Sie keine Zeit für meine Support-Anfrage haben (da free Agent) :(.

Kann daraus nur schließen, das Veeam wohl etwas empfindlicher ist, was die Konfiguration und die Umgebung, in der es eingesetzt wird, angeht.
 
  • Gefällt mir
Reaktionen: Phear
@RedPanda
Hast du noch Anpassungen an den SMB Einstellungen vorgenommen oder so?
 
Phear schrieb:
@RedPanda
Hast du noch Anpassungen an den SMB Einstellungen vorgenommen oder so?
Das einzige was mir dazu gerade einfällt ist:
  • Hatte Probleme bei den Clients in Veeam einen anderen Account für den Zugriff auf den Backup Ordner zu nutzen als für den SMB Share -> Windows erlaubt für den Zugriff auf den selben Server zur selben Zeit nur einen SMB Account
  • Clients verwenden untersch. Arten von SMBvX. Ein paar Verwenden SMBv3 und ein paar auf Grund der Nutzung eines sehr alten Netzwerkdruckers SMBv1. Habe da aber keine Unterschiede bzgl. Veeam feststellen können.

Seitens des NAS habe ich hier m. W. n. allerdings nichts spezielles eingestellt. Evtl. kann ich die Tage noch einmal einen Blick darauf werfen.
 
Also ich versuche es jetzt die ganze Woche und habe noch nicht einmal geschafft, dass es durchläuft. Habe nun auf 2 Laufwerke mit "nur" 1,4 TB reduziert, aber die Read Rate ist so dermaßen langsam mit 14-16Mb/s, dass das Backup einfach ewig dauert.
Wenn ich den Ordner aufrufe und per Copy Paste etwas einfüge, habe ich den Full Speed der Gigabit Leitung. Ich frage mich was Veeam da macht.
 
Kleines Update:
Durch einen glücklichen Zufall konnte ich kurzer Hand den alten Linksys WRT45gl Router durch eine Fritzbox 7590 AX ersetzen. Nach Anschluss dieser wollte ich natürlich testen, ob sich das von mir beschriebene Problem mit Veeam immer noch beobachten lässt. Also WLAN konfiguriert, sicherheitshalber Netzwerkeinstellungen der Clients zurückgesetzt, diese per WLAN mit dem Netzwerk verbunden und Backup gestartet -> siehe da, läuft ohne Probleme innerhalb kürzester Zeit durch.
Habe dann auch noch einmal einen Blick in die Ereignisanzeige geworfen und auch dort plötzlich keine Spur mehr von den von mir vorher beobachteten Netwtw10-Fehlern.

Sieht für mich also so aus, als wären die Backups vorher tatsächlich durch Problemen zwischen Client und Router auf Grund von Nutzung unterschiedlicher WLAN Standards verursacht worden.
Dachte eigentlich, dass neuere 802.11XX Standards Abwärtskompatibel sind (Intel listet dies ja auch in Ihren Datenblättern Ihrer Netzwerkkarten) nur scheint das in der Praxis wohl mehr schlecht als recht zu funktionieren :(

Phear schrieb:
Also ich versuche es jetzt die ganze Woche und habe noch nicht einmal geschafft, dass es durchläuft. Habe nun auf 2 Laufwerke mit "nur" 1,4 TB reduziert, aber die Read Rate ist so dermaßen langsam mit 14-16Mb/s, dass das Backup einfach ewig dauert.
Wenn ich den Ordner aufrufe und per Copy Paste etwas einfüge, habe ich den Full Speed der Gigabit Leitung. Ich frage mich was Veeam da macht.
In deinem Bild oben kann ich nur "Shared Memory Connection was closed" erkennen. Wie heißt den der voll ausgeschriebene Fehler? Die wichtigen Infos listet Veeam meist erst danach.
 
Zurück
Oben