Vollständige Anleitung zur Virtualmin Server-Migration: Behebung häufiger Fehler und Einschränkungen

Einführung

Migrieren von einem VPS zu einem anderen mit Virtualmin Der Betrieb von mehr als 10 WordPress-Domänen klingt in der Theorie einfach: Backup auf dem alten Server, Wiederherstellung auf dem neuen Server, fertig. In Wirklichkeit handelt es sich um ein Minenfeld aus versteckten Systemgrenzen, Dateideskriptor-Beschränkungen und Festplattenplatzproblemen, in dem du stundenlang feststecken kannst.

Ich habe kürzlich eine anspruchsvolle Virtualmin-Migration von einem Debian 12 VPS in Frankreich auf einen neuen Debian 13 VPS in den Niederlanden, wobei ich mehr als 4,4 GB Backup-Daten über mehr als 10 Domains hinweg verschob. Während dieses Prozesses bin ich auf jeden größeren Fehler gestoßen, mit dem Virtualmin-Administratoren konfrontiert werden - und habe sie alle gelöst. Dieser Artikel dokumentiert die genauen Probleme und Lösungen, damit du sie nicht auf die harte Tour lernen musst.

Egal, ob du deinen VPS-Provider aufrüstest, horizontal skalierst oder einen ausgefallenen Server wiederherstellen möchtest, dieser Leitfaden führt dich durch die häufigsten Fehler und deren Behebung.

---

Teil 1: Planung und Vorbereitung vor der Migration

Wähle deine VPS-Spezifikationen

Bevor du irgendetwas auf deinem aktuellen Server anfasst, solltest du sicherstellen, dass dein neuer VPS über ausreichende Ressourcen verfügt. Der häufigste Fehler ist die Annahme, dass nur der Festplattenspeicher wichtig ist - das ist nicht der Fall.

Mindestanforderungen für Virtualmin mit 10+ Domains:

• Speicherplatz: 100 GB (nicht 50 GB - WordPress-Seiten mit Backups wachsen schnell)
• CPU: 6+ Kerne (8+ Kerne empfohlen für 10+ Domains)
• RAM: Mindestens 8 GB (15 GB+ für die Produktion)
• Tauschen: 4 GB (wird nach der Betriebssysteminstallation hinzugefügt, falls nicht vorkonfiguriert)

Dein neuer Server sollte die gleiche oder eine höhere CPU- und RAM-Leistung wie dein alter Server haben und über mehr Festplattenspeicher verfügen. Virtualmin ist während der Wiederherstellungsvorgänge CPU- und E/A-intensiv - ein schwacher Prozessor führt dazu, dass die Wiederherstellung nur langsam vorankommt.

Checkliste vor der Migration

Auf deinem alten Server (48 Stunden vor der Migration):

1. DNS-TTL auf 300 Sekunden reduzieren (5 Minuten), um Probleme mit dem Cache zu minimieren:

virtualmin modify-dns --all-domains --ttl 300

2. Erstelle eine neue Sicherung mit dem von Virtualmin empfohlenen Format:

mkdir /backup
virtualmin backup-domain \
  --dest /backup/ \
  --all-domains \
  --all-features \
  --neues-format

3. Überprüfung der Integrität der Sicherung vor der Übermittlung:

tar -tzf /backup/backup_*.tar.gz > /dev/null && echo "Sicherung OK" || echo "Sicherung beschädigt"

4. Notiere die Größe deiner Datenbank für die Planung:

mysql -e "SELECT table_schema AS 'Database', ROUND(SUM(data_length+index_length)/1024/1024,2) AS 'Size_MB' FROM information_schema.TABLES GROUP BY table_schema;"

5. Prüfung auf benutzerdefinierte Konfigurationen die möglicherweise nicht übertragen werden:
   • Benutzerdefinierte PHP-Versionen
   • Geänderte NGINX-Konfigurationen
   • Cronaufträge in /etc/cron.d/
   • Benutzerdefinierte SSL-Zertifikate

---

Teil 2: Der Migrationsprozess

Schritt 1: Übertragen der Sicherungsdatei

Verwende SCP mit Prüfsummen um die Integrität der Datei zu überprüfen:

# Auf altem Server, Prüfsumme erzeugen
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Backup und Prüfsumme übertragen
scp /backup/backup_*.tar.gz [email protected]:/Files/
scp /backup/backup.sha256 [email protected]:/Files/

# Auf dem neuen Server überprüfen
cd /Files/
sha256sum -c backup.sha256

Wenn die Prüfsummen nicht übereinstimmen, sofort aufhören. Die Datei wurde während der Übertragung beschädigt. Übertrage erneut oder verwende rsync mit Prüfsummen:

rsync -avz --checksum /backup/backup_*.tar.gz [email protected]:/Files/

Schritt 2: Virtualmin auf dem neuen Server installieren

Verwende das offizielle Installationsprogramm von Virtualmin:

curl https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh | sh

Das ist wichtig: Installiere die gleiche Betriebssystemversion (oder eine ähnliche) - das ist wichtiger, als man denkt. Ich bin von Debian 12 auf Debian 13 umgestiegen (nicht empfohlen, aber machbar). Bleib nach Möglichkeit bei der gleichen Hauptversion.

Schritt 3: Vor der Wiederherstellung der Systemkonfiguration

An dieser Stelle scheitern die meisten Migrationen. Bevor du die Wiederherstellung in Angriff nimmst, solltest du diese drei kritischen Grenzen beseitigen:

Fix 1: Offene Dateideskriptoren erhöhen

Dies ist die #1 Ursache für die Fehlermeldung “Kein Platz mehr auf dem Gerät” während der Wiederherstellung, auch wenn genügend Speicherplatz vorhanden ist.

# Stromgrenze prüfen
ulimit -n
# zeigt wahrscheinlich: 1024 (zu niedrig für Virtualmin)

# Erhöhen für aktuelle Sitzung
ulimit -n 65536

# Überprüfen
ulimit -n
# Sollte anzeigen: 65536

# Dauerhaft machen
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536
EOF

Warum 65536? Jede geöffnete Datei, jeder Socket, jede Pipe und jede Datenbankverbindung verbraucht einen Dateideskriptor. Bei mehr als 10 WordPress-Sites, Mail-Servern, NGINX-Workern und MySQL-Verbindungen überschreitest du leicht 1024. OVH und andere Anbieter haben diesen konservativen Standardwert aus Sicherheitsgründen festgelegt - er soll pro Anwendung erhöht werden.

Lösung 2: /tmp (tmpfs) vergrößern

Während der Wiederherstellung erstellt Virtualmin MySQL-Dumps in /tmp/. Standardmäßig, /tmp ist eine tmpfs (RAM-Disk), die auf ~50% des gesamten RAM begrenzt ist. Mit 11GB RAM, /tmp liegt bei maximal ~5,8 GB. Virtualmin kann jedoch bei der Wiederherstellung leicht 5-6 GB temporäre Dateien erzeugen.

# Aktuelle /tmp-Größe prüfen
df -h /tmp

# Dynamische Größenänderung ohne Aushängen
mount -o remount,size=8G /tmp

# Überprüfen
df -h /tmp

# Dauerhaft machen
echo "tmpfs /tmp tmpfs size=8G,mode=1777 0 0" >> /etc/fstab

Fix 3: Swap Space hinzufügen

Wenn die Wiederherstellung den gesamten Arbeitsspeicher aufbraucht, reagiert das System nicht mehr. 4 GB Swap-Speicher bieten einen Sicherheitspuffer:

# 4GB Auslagerungsdatei erstellen
fallocate -l 4G /swapfile
chmod 600 /auslagerungsdatei
mkswap /auslagerungsdatei
swapon /auslagerungsdatei

# Dauerhaft machen
echo '/swapfile keine swap sw 0 0' >> /etc/fstab

# Überprüfen
swapon --show

---

Teil 3: Der Wiederherstellungsprozess und häufige Fehler

Fehler 1: “Überprüfen des Inhalts der Sicherung ...” Hängt für 20+ Minuten

Wie es aussieht:

Prüfen des Inhalts der Sicherung ..

(15-30 Minuten ohne Fortschritt)

Grundlegende Ursache: Das ist kein Hängen - es ist wirklich langsam. Virtualmins tar -tzf Verifizierung liest das gesamte 4,4 GB große komprimierte Archiv, verifiziert jeden Dateiheader und prüft die tar-Integrität. Auf älteren CPUs (z. B. Haswell) kann dies für eine 4-GB-Sicherung mehr als 20 Minuten dauern.

Lösung:

1. Kein Grund zur Panik. Prüfe, ob tar tatsächlich läuft:

ps aux | grep tar
iostat -x 1 # Festplattenaktivität prüfen

2. CLI-Wiederherstellung anstelle der Web-UI verwenden (umgeht die Zeitüberschreitung bei der Überprüfung):

Bildschirm -S wiederherstellen
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --all-domains \
  --all-features \
  --reuid

Die --Ruid passt die Benutzer-/Gruppen-IDs automatisch an - wichtig bei der Wiederherstellung über verschiedene Systeme hinweg.

Fehler 2: “/bin/tar: Cannot write: Kein Platz mehr auf dem Gerät”

Wie es aussieht:

/bin/tar: ./seo.grahammiranda.com_mail_users: Cannot write: No space left on device
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: Cannot write: No space left on device

(Dutzende weiterer solcher Fehler)

/bin/tar: Beendet mit Fehlerstatus aufgrund vorheriger Fehler

Der verwirrende Teil: Du hast 75 GB frei, aber es heißt “Kein Speicherplatz mehr auf dem Gerät.”

Grundlegende Ursachen (in der Reihenfolge ihrer Eintrittswahrscheinlichkeit):

1. Dateideskriptor-Limit erreicht (am häufigsten)
   • Symptom: Fehler erscheinen 5-10 Minuten nach der Wiederherstellung, nicht am Anfang
   • Reparieren: ulimit -n 65536 (siehe oben)
2. /tmp füllt sich (zweithäufigste)
   • Symptom: Fehler erwähnen MySQL oder temporäre Dateien
   • Prüfen: df -h /tmp während der Wiederherstellung - beobachte, wie er sich auf 100% füllt
   • Reparieren: mount -o remount,size=8G /tmp (siehe oben)
3. Aktueller Speicherplatz geht zur Neige (weniger häufig, aber möglich)
   • Prüfen: df -h / zeigt <5GB frei
   • Lösung:

# Bereinigung der fehlgeschlagenen Wiederherstellung
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/

# Wenn sich das Backup noch in /Files befindet, solltest du es verschieben
mv /Files/backup_*.tar.gz /mnt/ # Auf eine andere Partition verschieben, falls verfügbar

4. Inode-Erschöpfung (selten)
   • Prüfen: df -i / zeigt >90% iGebraucht
   • Die Ursache: Dateisystem mit zu wenig Inodes erstellt
   • Lösung: Dateisystem mit mehr Inodes neu formatieren (destruktiv)

Diagnostischer Ansatz bei der Wiederherstellung:

Öffne ein zweites Terminal und überwache in Echtzeit:

watch -n 2 'df -h / && echo "---" && df -h /tmp && echo "---" && du -sh /tmp/* 2>/dev/null | sort -rh | head -5'

Dies zeigt genau, wann und wo du die Grenze erreicht hast.

Fehler 3: NGINX wird nach der Wiederherstellung nicht gestartet

Fehlermeldung:

nginx[34392]: [emerg] 34392#34392: open() "/etc/nginx/snippets/block-manager.conf" fehlgeschlagen (2: Keine solche Datei oder kein solches Verzeichnis)
nginx: Test der Konfigurationsdatei /etc/nginx/nginx.conf fehlgeschlagen

Grundlegende Ursache: Die Wiederherstellung ist teilweise fehlgeschlagen, oder bestimmte Dateien wurden nicht korrekt übertragen. NGINX-Konfigurationen verweisen auf Dateien, die nicht existieren.

Lösung:

1. Erstelle die fehlende Datei:

mkdir -p /etc/nginx/snippets
touch /etc/nginx/snippets/block-manager.conf

2. Teste die NGINX-Konfiguration:

nginx -t

3. Starte NGINX:

systemctl start nginx
systemctl status nginx

Wenn die Datei einen aktuellen Inhalt benötigt, überprüfe deinen alten Server:

scp alter-server.com:/etc/nginx/snippets/block-manager.conf /etc/nginx/snippets/

---

Teil 4: Erweiterte Lösungen und Optimierung

Wiederherstellung einer Domäne nach der anderen (sicherste Methode)

Wenn die vollständige Wiederherstellung trotz Korrekturen fehlschlägt, stelle selektiv wieder her:

# Frühere Fehlversuche bereinigen
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Stelle zunächst nur die Hauptdomäne wieder her
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --domain grahammiranda.com \
  --all-features \
  --reuid

So lässt sich feststellen, welche Domänen Probleme haben. Wenn eine Domäne erfolgreich wiederhergestellt wird, funktioniert das Muster auch für andere.

Überlegungen zur Migration von Debian 12 auf Debian 13

Ich bin von Debian 12 auf Debian 13 umgestiegen. Während im Allgemeinen kompatibel, achte auf:

1. Unterschiede in der PHP-Version: Debian 12 könnte PHP 8.1 haben, Debian 13 hat 8.3
   • Prüfen: php -v auf beiden Servern
   • Ausgabe: Seltene Kompatibilitätsprobleme mit alten PHP-Erweiterungen
   • Reparieren: Alte PHP-Version erzwingen: virtualmin modify-web --domäne beispiel.de --php-version 8.1
2. NGINX/Apache-Konfigurationssyntax: Normalerweise kompatibel, aber nach der Wiederherstellung testen
   • Test: nginx -t und apache2ctl configtest
3. MySQL/MariaDB-Kompatibilität: Generell vorwärtskompatibel
   • Prüfen: mysql --version auf beiden Servern
   • Unterschiede im Dump-Format: Selten, aber neuere Debian-Versionen haben möglicherweise strengere SQL-Modi
4. Kompatibilität mit SSL-Zertifikaten: Keine Probleme zwischen Debian-Versionen, aber überprüfen:

certbot-Zertifikate # Let's Encrypt-Zertifikate prüfen

---

Teil 5: Verifizierung nach der Migration

Kritische Checks vor dem Going Live

Überprüfe nach Abschluss der Wiederherstellung, ob alles funktioniert:

# 1. Alle wiederhergestellten Domains auflisten
virtualmin list-domains

# 2. Web-Konnektivität testen
curl -I https://yourdomain.com

# 3. Mail-Funktionalität prüfen
mysql -u root -p'password' -e "SELECT user FROM mysql.user;"

# 4. DNS überprüfen
dig yourdomain.com @localhost

# 5. Virtualmin-Modul prüfen
virtualmin test-domain --domain yourdomain.com

# 6. Logs auf Fehler überwachen
journalctl -f
tail -f /var/log/nginx/error.log

DNS-Einträge aktualisieren

Sobald alle Domänen erfolgreich wiederhergestellt sind:

1. Nameserver der Registrierstelle aktualisieren auf einen neuen Server verweisen
2. TTL-Countdown überwachen (sollte 5 Minuten mit reduzierter TTL betragen)
3. Teste von mehreren Standorten aus:

nslookup ihredomain.de
dig ihredomain.de +kurz

4. DNS-TTL auf normal zurücksetzen nach 24-48 Stunden:

virtualmin modify-dns --all-domains --ttl 3600

---

Teil 6: Systemgrenzwerte Referenz

Als Referenz für die Zukunft findest du hier alle Systemgrenzen, die während dieser Migration überprüft wurden:

# Benutzer-/Prozessgrenzen
ulimit -a # Alle Beschränkungen
ulimit -n # Offene Dateien
ulimit -u # Maximale Prozesse
ulimit -v # Virtueller Speicher

# Systemweite Beschränkungen
cat /proc/sys/fs/file-max # Systemweit geöffnete Dateien
cat /proc/sys/kernel/pid_max # Maximale Prozess-IDs
cat /proc/sys/vm/max_map_count # Höchstgrenze für Speicherkarten

# Aktuelle Ressourcennutzung
df -h # Festplattenspeicher
df -i # Inode-Nutzung
free -h # RAM und Swap
ps aux | wc -l # Laufende Prozesse
lsof | wc -l # Offene Dateideskriptoren

# Besonderheiten des Dateisystems
mount | grep /dev/sda1 # Einhängeoptionen
quota -s # Festplattenkontingente
tune2fs -l /dev/sda1 # Dateisystemeigenschaften

---

Wichtigste Erkenntnisse

1. OVH (und die meisten Anbieter) setzen konservative Standardwerte fest. Du musst die Dateideskriptor-Limits erhöhen, bevor du Virtualmin-Backups wiederherstellst.
2. Die Systemgrenzen sind der wahre Feind, nicht der Speicherplatz. Selbst wenn 75 GB frei sind, erhältst du die Meldung “Kein Speicherplatz mehr auf dem Gerät”, wenn /tmp voll ist oder die Dateideskriptoren erschöpft sind.
3. Erhöhung /tmp Größe vor der Wiederherstellung. Virtualmin erstellt während der Wiederherstellung eines Backups 5-6 GB an temporären Dateien. Die standardmäßige tmpfs-Zuweisung ist nicht genug.
4. Verwende die CLI-Wiederherstellung, nicht die Web-UI. Die Web-UI hat Timeout-Probleme bei großen Backups. Die Befehlszeilenwiederherstellung ist zuverlässiger und zeigt den aktuellen Fortschritt an.
5. Die Migration von Debian 12 auf Debian 13 funktioniert, aber die gleiche Version ist sicherer. Geringfügige Versionsunterschiede verursachen nur selten Probleme, aber bleib nach Möglichkeit innerhalb derselben Hauptversion.
6. Überprüfe die Integrität der Sicherung vor der Übertragung. Verwende SHA256-Prüfsummen, um sicherzustellen, dass die Sicherungsdatei während der Übertragung nicht beschädigt wurde.
7. Die Planung vor der Migration spart Stunden. Die Reduzierung der DNS-TTL, die Überprüfung der Datenbankgrößen und die Vorbereitung des Zielservers beugen den meisten Problemen vor.

---

Schlussfolgerung

Die Migration von Virtualmin ist nicht schwierig - sie ist nur pingelig. Die meisten Fehler sind nicht auf Virtualmin selbst zurückzuführen, sondern auf versteckte Systemgrenzen, die von Hosting-Anbietern festgelegt wurden. Wenn du diese Beschränkungen verstehst und die hier dokumentierten Korrekturen anwendest, kannst du 10+ WordPress-Sites zuverlässig über mehrere Server hinweg migrieren.

Die spezifischen Fehler, auf die ich gestoßen bin (file descriptor limits, /tmp Erschöpfung, fehlende NGINX-Snippets) sind reproduzierbar und häufig. Wenn du auf eines dieser Probleme stößt, kehre zu diesem Leitfaden zurück - dort findest du die genaue Lösung.

Viel Glück bei deiner Migration. Mögen deine Backups schnell wiederhergestellt werden und deine Domains ohne Probleme online gehen.

---

Autor Bio

Diese Anleitung dokumentiert eine reale Virtualmin-Migration, die im Februar 2026 abgeschlossen wurde. Dabei wurden 10+ Produktionsdomains von einem Debian 12 VPS (Frankreich) auf einen Debian 13 VPS (Niederlande) migriert. Die Lösungen sind kampferprobt und praxiserprobt.