Veeam und Proxmox ließen sich nicht einrichten. Die o.g. Fehlermeldung trat immer auf, egal ob beim Hinterlegen des Hosts oder beim tatsächlichen Durchführen eines Backups.
Ursache war eine gehärtete Proxmox-Config. Wir gehen kurz die Schritte durch

SSH

Veeam meldet sich als root-Benutzer an. Aber Anmeldung des root-Benutzers ist in der /etc/ssh/sshd_config mit PermitRootLogin no deaktiviert.
Wirklich Lust, das für alle auf yes zu setzen, hatte ich nicht; sicherheitsbedenken.

Der Trick an der Sache: unten an der sshd_config folgende Zeile anhängen:

Match Address 10.0.0.10
    PermitRootLogin yes

Match Address 10.0.0.11
    PermitRootLogin yes

Wobei die 10.0.0.10 die IP-Adresse des B&R-Servers, und 10.0.0.11 die IP-Adresse der von Worker-VM von Veeam ist.
Die zwei IPs können sich dann nämlich direkt als root anmelden, andere weiterhin nicht. Neustart vom SSH-Dienst nicht vergessen.

Firewall-Regeln

Der nächste Fehler war dann genau so doof – der Worker ist beim Preparen in ein Timeout gelaufen. Hintergrund hier: iptables-Regeln, die den Zugriff restriktiert haben.
Also habe ich beide IP-Adressen komplett freigegeben:

/sbin/iptables -I INPUT  -s 10.0.0.10 -j ACCEPT
/sbin/iptables -I OUTPUT -d 10.0.0.10 -j ACCEPT
/sbin/iptables -I INPUT  -s 10.0.0.11 -j ACCEPT
/sbin/iptables -I OUTPUT -d 10.0.0.11 -j ACCEPT

Der Host kann netzwerktechnisch dann frei mit dem B&R Server und dem Worker kommunizieren.

Anpassungen in der pveproxy

Und final: in der /etc/default/pveproxy war noch hinterlegt, dass nur der B&R Server auf das Interface zugreifen darf. Den braucht der Worker allerdings, da er die API ansteuert.

Also nano /etc/default/pveproxy und folgendes anpassen:

ALLOW_FROM="127.0.0.1,10.0.0.10,10.0.011"
DENY_FROM="all"
POLICY="allow"

Stattdessen kann ALLOW_FROM auch „*“ sein, dann ist alles freigegeben. In diesem Fall ist der Host allerdings öffentlich erreichbar, und wird via SSH Tunnel administriert, daher hier nur 127.0.0.1 und die IP der Sicherungs-VMs.

Anschließend den pveproxy-Dienst neustarten