Hi, den gleichen Fehler hatten wir bei einem Backupcopy, die Backups liefen normal.

Die genaue Ursache kennen wir auch noch nicht, aber die Fehlermeldung kam, wenn der Reposerver ausgehend keine Verbindung zum Proxy aufbauen konnte. Am besten auf dem LHR die ausgehende Verbindung zum Agent prüfen.

Könnte DNS sein oder irgend ein anderes Netzwerkproblemchen.

Hallo.

richtig, bei einem Backup Copy Job bekommen wir den gleichen Fehler, hier ist es auch egal, ob es sich um eine VM oder phys. Server handelt. :(

Die Fehlermeldung ist etwas irreführend. Das Problem sitzt auf dem ausgehenden Weg vom LHR.

Kannst du den Agent oder beim Copy den Proxy anpingen?

Habt ihr die notwendige Ports für diese Operationen gecheckt?

Das hört sich so an  dass für diese Operationen einige Ports nicht frei sind.

Das sind die dynamischen Ports welche automatisch über die temporären Regeln aufgemacht werden.

Laut der Fehlermeldung sucht man auch zuerst den Fehler dort, aber selbst mit abgeschalteter Firewall lässt sich das reproduzieren. Tritt übrigens erst seit V12 auf.

Muss ich das vom Backupserver zum Repo testen, oder anders rum?

Was soll ich da genau testen? Ping, Port, DNS…..

Ich habe bei meinem Kunden den Workaround, immer wenn der Fehler auftritt, pingen wir vom Linux den Proxy einmal an und dann läuft es wieder.

Das hört sich aber doch nach DNS Problem an….

Vielleicht ein preferred Network für den Backup Verkehr gesetzt und über das ist der DNS Server nicht erreichbar?  Nach dem Ping wird der Name ja eine Zeit lang im Cache gehalten….

Habe mal eine Portabfrage auf dem Repo während des Backup Copy Job gemacht:

Wir haben überall nur IPs benutzt, DNS ist es bei uns schon mal nicht. Das Interessante, wenn wir vom Linux pingen, gehen die ersten 4 Pakete verloren, danach dauerhaft unter 1ms. 
Ich hatte schon arp auf dem Switch im Verdacht, aber das komische, wenn der Linux frisch gebootet ist, ist der Fehler wieder da. Wenn ich vom Proxy pinge ist alles OK, aber der Fehler besteht weiterhin. Ich sehe auch die Verbindung über Port 6162 und die temporären Firewallregeln, für jeweils 1-2 Sekunden, bevor die nach dem Timeout der direkt kommt, wieder entfernt werden. Erst das pingen vom Linux wo ein paar Pakete verloren gehen, behebt den Fehler.

Sorry, klingt weiterhin danach, dass zuerst auf einem anderen Netz gepingt wird. Veeam ist da anscheinend nicht so “geduldig".