Wenn du mit Dirvish arbeitest – einem populären Backup-Tool unter Linux – kann es vorkommen, dass du beim Ausführen von Backups auf den Fehler
Dirvish default error (10) -- error in socket IO
stößt. Dieser Fehler tritt häufig auf, wenn das Backup aufgrund von Netzwerkproblemen oder fehlerhaften Konfigurationen nicht korrekt gestartet werden kann. In diesem Artikel erklären wir die möglichen Ursachen und zeigen konkrete Lösungen.
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 failedWas bedeutet der Fehler „Dirvish default error (10) – error in socket IO“?
Der Fehler „error in socket IO“ weist darauf hin, dass Dirvish beim Versuch, eine Verbindung zu einem Remote-Host herzustellen, auf ein Problem mit der Socket-Kommunikation gestoßen ist.
Sockets sind in diesem Kontext die Schnittstelle, über die Dirvish Daten zwischen deinem Backup-Server und dem Zielsystem überträgt.
Ursachen können sein:
- Netzwerkprobleme – Unterbrechungen in der Verbindung oder Paketverluste.
- SSH- oder rsync-daemon-Verbindungsprobleme – Dirvish verwendet entweder SSH oder den rsync-daemon für die Übertragung.
- Fehlerhafte Konfiguration – Falsche Pfade, Benutzerrechte oder Backup-Parameter.
- Speicherprobleme – Wenn der Zielhost nicht genügend Speicher oder Inodes hat, kann dies ebenfalls zu Socket-Fehlern führen.
SSH vs. rsync-daemon
Dirvish kann Backups über SSH oder direkt über den rsync-daemon durchführen.
- SSH: Standardmethode, verschlüsselt die Verbindung, benötigt SSH-Zugang.
- rsync-daemon: Direkter Zugriff auf den rsync-Dienst, schneller, aber weniger verschlüsselt.
Prüfen, welche Methode verwendet wird
In der Vault-Konfiguration (/etc/dirvish/<vault>.conf) siehst du:
server: <remote-host>
client: <user>
method: rsync
- SSH-Verbindung:
server:<user>@hostund kein expliziter Daemon-Port - rsync-daemon:
server: rsync://host/module
Prüfen, ob der rsync-daemon aktiv ist
Auf dem Zielhost kannst du prüfen, ob der rsync-daemon läuft:
ps x | grep rsync- Läuft er, siehst du den Prozess: rsync –daemon
- Läuft er nicht, ist das der Grund für den Socket-Fehler.
Die Ausgabe sieht so aus:
root@server01:~# ps x | grep rsync
1574616 ? Ss 0:00 rsync --daemon
1581956 pts/1 S+ 0:00 grep --color=auto rsync
rsync-daemon aktivieren
Falls der Daemon nicht aktiv ist, kannst du ihn starten:
rsync --daemon
- Testen, ob der Dienst läuft:
sudo systemctl status rsync
rsync-daemon für Autostart aktivieren
Damit der rsync-Dienst beim Hochfahren des Servers automatisch startet:
sudo systemctl enable rsync
Schritt-für-Schritt-Lösungen
1. Netzwerkverbindung prüfen
ping <remote-host>
ssh <user>@<remote-host>
- Wenn der Ping fehlschlägt → Netzwerkproblem
- Wenn SSH fehlschlägt → Firewall oder SSH-Dienst prüfen
2. SSH-Zugriff testen
ssh -i /pfad/zum/private_key <user>@<remote-host> 'ls'
- Öffentlichen Schlüssel hinterlegen:
~/.ssh/authorized_keys - Berechtigungen prüfen
3. Backup-Konfiguration prüfen
- Pfad prüfen:
/backup/vaultexistiert auf dem Remote-Host - Benutzerrechte prüfen: Lese-/Schreibrechte für den Backup-Benutzer
- Vault-Konfiguration: Korrekte Angaben für Server, Client, Methode
4. Firewall und Ports prüfen
- SSH (Port 22) oder rsync-Daemon (Port 873) offen:
sudo ufw status
sudo iptables -L
5. Temporäre Dateien und Speicherplatz prüfen
df -h
df -i
- Speicherplatz oder Inodes prüfen und ggf. aufräumen
6. Dirvish im Debug-Modus starten
dirvish --test --verbose --debug <vault>
- Detaillierte Fehleranalyse
Fazit
Der „Dirvish default error (10) – error in socket IO“ tritt meist durch Verbindungsprobleme, fehlerhafte SSH- oder rsync-Konfiguration oder fehlende Rechte auf.
- Prüfe, ob SSH oder der rsync-daemon verwendet wird.
- Stelle sicher, dass der rsync-daemon auf dem Zielhost aktiv ist und bei Bedarf autostart aktiviert ist.
- Teste Netzwerk, Berechtigungen und Speicherplatz.
Mit diesen Schritten lassen sich Socket-Fehler in Dirvish zuverlässig beheben, sodass Backups wieder fehlerfrei laufen.
Hi, ich bin gelernter Fachinformatiker für Systemintegration und arbeite als Linux-Systemadministrator. Zuhause fühle ich mich vor allem bei Proxmox, Ubuntu und Debian – die drei begleiten mich sowohl im Job als auch privat auf meinen Servern. Wenn ich nicht gerade an der Shell hänge, tüftle ich gern an neuen Projekten und meinem Smart Home (Hometinker.io), teste spannende Open-Source-Tools oder optimiere bestehende Setups. Auf linuxbase.io möchte ich meine Erfahrungen teilen, damit andere nicht jede Stolperfalle selbst mitnehmen müssen.