Kurzfassung (TL;DR): Der Fehler „Dirvish default error (10) – error in socket IO“ bedeutet, dass Dirvish/rsync beim Verbindungsaufbau oder während der Übertragung über den Socket scheitert. Meistens liegt es an Netzwerk‑/Firewall‑Problemen, SSH‑Zugriff oder daran, dass der rsync‑Daemon nicht läuft. Unten findest du eine Checkliste und konkrete Befehle zum Kopieren.
Fehlermeldung #
dirvish <vault>:default error (10) -- error in socket IOWas bedeutet der Fehler genau? #
Der Hinweis „error in socket IO“ stammt aus rsync und signalisiert ein Problem bei der Socket‑Kommunikation zwischen Backup‑Server (Dirvish) und Zielsystem. Ursachen reichen von gestörter Netzwerkverbindung über falsche Methode (SSH vs. rsync‑Daemon) bis hin zu Fehlkonfigurationen oder fehlendem Speicher/fehlenden Inodes auf einer der Seiten.
Häufige Ursachen:
- Netzwerkunterbrechung, DNS‑Probleme, MTU/Packet Loss
- SSH‑Probleme (Keys, Berechtigungen, Hostkey‑Änderungen)
- rsync‑Daemon läuft nicht oder ist nicht erreichbar (Port 873)
- Fehler in der Dirvish‑Konfiguration (falsche Pfade/Benutzer)
- Zu wenig Speicherplatz oder Inodes (df/df ‑i)
SSH vs. rsync‑Daemon – welche Methode nutzt dein Vault? #
Dirvish kann über SSH oder über den rsync‑Daemon übertragen. Prüfe in deiner Vault‑Konfiguration (z. B. /etc/dirvish/<vault>.conf) die Zieldefinition:
Typische Muster
- SSH (Standard, verschlüsselt):client: backupuser@remote-host# optional: rsync-Remote-Shell setzenrsh: ssh -i /path/to/key -o ConnectTimeout=10method: rsyncMerkmale: Kein „rsync://“-Schema, Verbindung erfolgt via SSH auf Port 22.
- rsync‑Daemon (schneller, unverschlüsselt):server: rsync://remote-host/modulemethod: rsyncMerkmale: „rsync://“-Schema und Port 873; dafür muss der rsync‑Daemon auf dem Ziel laufen.
Hinweis: In manchen Setups heißen die Felder
client/serverleicht anders oder es wird ausschließlich überclient:gearbeitet. Entscheidend ist: SSH‑Ziel (user@host) vs. Daemon‑URL (rsync://host/module).
Schritt‑für‑Schritt‑Diagnose #
Arbeite die Punkte der Reihe nach durch. Beende nach jeder Änderung Tests mit einem kurzen Lauf im Test/Debug‑Modus.
1) Netzwerk & Namensauflösung prüfen #
ping-c3 <remote-host>
getent hosts <remote-host>
traceroute <remote-host> # optional
- Ping/Traceroute fehlschlägt → Routing/Firewall/Netz prüfen
- DNS‑Fehler →
/etc/resolv.conf/DNS‑Server prüfen
2) SSH‑Zugriff testen (falls SSH‑Methode) #
ssh-i /pfad/zum/private_key <user>@<remote-host> ‚echo OK && ls -la /‘
- Public Key auf dem Zielhost in
~/.ssh/authorized_keys - Berechtigungen:
~/.ssh= 700,authorized_keys= 600, Benutzerrechte korrekt - Hostkey‑Änderung? →
ssh-keygen -R <remote-host>und neuen Key akzeptieren
3) Läuft der rsync‑Daemon (falls rsync://‑Methode)? #
ps x | grep'[r]sync‘
sudo systemctl status rsync
Wenn nicht aktiv:
sudo systemctl enable –now rsync
Debian/Ubuntu Besonderheit: In /etc/default/rsync ggf. RSYNC_ENABLE=true setzen und Dienst neu starten.
Schnelltest:
rsync rsync://<remote-host>/
Listet der Befehl Module auf, ist der Daemon erreichbar.
4) Firewall & Ports öffnen #
- SSH: Port 22/tcp
- rsync‑Daemon: Port 873/tcp
# UFW
sudo ufw allow 22/tcp
sudo ufw allow 873/tcp
sudo ufw status
# iptables (Beispiel)
sudo iptables -A INPUT -p tcp –dport22-j ACCEPT
sudo iptables -A INPUT -p tcp –dport873-j ACCEPT
# firewalld (RHEL/CentOS/Rocky)
sudo firewall-cmd –permanent–add-service=ssh
sudo firewall-cmd –permanent–add-port=873/tcp
sudo firewall-cmd –reload
5) Speicherplatz & Inodes prüfen #
df -h
df -i
Bei 0 % frei oder 0 Inodes: Aufräumen (Logs, alte Images), ggf. Partitionen vergrößern.
6) Dirvish im Test/Debug‑Modus #
dirvish –vault <vault> –test–verbose–debug
Achte auf die Stelle, an der der Verbindungsaufbau/rsync startet – dort erscheinen i. d. R. die eigentlichen Hinweise.
7) Hinweis aus dem Beispiel‑Log beachten (Mountpoint) #
Wenn im Log zusätzlich erscheint:
mount: /mnt/srv_snapshot: mount point does not exist.
→ Lege den Mountpoint an oder korrigiere den Pfad in der Vault‑Konfiguration. Das ist ein separater Fehler, der unabhängig von Socket‑Problemen zu Fehlschlägen führen kann.
rsync‑Daemon korrekt einrichten (falls benötigt) #
Minimal‑Konfiguration /etc/rsyncd.conf auf dem Zielhost:
uid = nobody
gid = nogroup
use chroot = no
read only = no
max connections = 4
log file = /var/log/rsyncd.log
[module]
path = /data/backup
comment = Backup Module
auth users = backupuser
secrets file = /etc/rsyncd.secrets
Zugriffsdatei /etc/rsyncd.secrets (nur root lesen):
backupuser:SEHR_GEHEIMES_PASSWORT
Dienst aktivieren:
sudo systemctl enable --now rsyncSicherheit: Wenn möglich per Firewall auf Quell‑IP(s) begrenzen oder statt Daemon SSH verwenden.
Typische Dirvish‑Konfig‑Fallen & Fixes #
- Pfad/Verzeichnisrechte: Zielpfade existieren, Besitzer/Rechte passen (auch für Hard‑Links/Incrementals)
rshdefinieren:rsh: ssh -i /path/to/key -o ConnectTimeout=10 -o StrictHostKeyChecking=yes- Timeouts/KeepAlive: Bei wackligen Leitungen
--timeout/--contimeoutin rsync‑Options (über Dirvish‑Optionen) setzen - Hostkeys & Known‑Hosts: Nach Serverwechsel Hostkey aktualisieren
Quick‑Fix‑Checkliste (zum Abhaken) #
Beispiel‑Ausgabe #
root@backup:~# dirvish --vault server01-srv
mount: /mnt/srv_snapshot: mount point does not exist.
dirvish server01-srv:default error (10) -- error in socket IO
umount: /dev/data/srv_snap: not mounted.
dirvish error: branch /srv/rsync1/server01-srv:default image 2025-08-29--14-35 failedFAQ #
Fazit #
Der Dirvish‑Fehler „default error (10) – error in socket IO“ ist in der Praxis fast immer auf Netzwerk/Firewall, SSH‑Zugriff oder einen inaktiven rsync‑Daemon zurückzuführen. Mit der obigen Diagnoseabfolge, der Daemon‑Einrichtung (falls benötigt) und der Checkliste behebst du die Ursache in wenigen Schritten – und deine Backups laufen wieder stabil.
