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 Sie stundenlang feststecken können.

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 Sie sie nicht auf die harte Tour lernen müssen.

Egal, ob Sie Ihren VPS-Provider aufrüsten, horizontal skalieren oder einen ausgefallenen Server wiederherstellen möchten, dieser Leitfaden führt Sie durch die häufigsten Fehler und deren Behebung.

---

Teil 1: Planung und Vorbereitung vor der Migration

Wählen Sie Ihre VPS-Spezifikationen

Bevor Sie irgendetwas auf Ihrem aktuellen Server anfassen, sollten Sie sicherstellen, dass Ihr 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)

Ihr neuer Server sollte die gleiche oder eine höhere CPU- und RAM-Leistung wie Ihr 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 Ihrem 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. Erstellen Sie 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. Notieren Sie die Größe Ihrer 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

Verwenden Sie 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 root@new-server.com:/Files/
scp /backup/backup.sha256 root@new-server.com:/Files/

# Überprüfen Sie auf dem neuen Server
cd /Dateien/
sha256sum -c backup.sha256

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

rsync -avz --checksum /backup/backup_*.tar.gz root@new-server.com:/Files/

Schritt 2: Virtualmin auf dem neuen Server installieren

Verwenden Sie das offizielle Installationsprogramm von Virtualmin:

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

Das ist wichtig: Installieren Sie 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). Bleiben Sie nach Möglichkeit bei der gleichen Hauptversion.

Schritt 3: Vor der Wiederherstellung der Systemkonfiguration

An dieser Stelle scheitern die meisten Migrationen. Bevor Sie die Wiederherstellung in Angriff nehmen, sollten Sie 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 überschreiten Sie 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üfen Sie, 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: Kein Platz mehr auf dem Gerät
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: Cannot write: Kein Platz mehr auf dem Gerät

(Dutzende weiterer solcher Fehler)

/bin/tar: Beendet mit Fehlerstatus aufgrund vorheriger Fehler

Der verwirrende Teil: Sie haben 75 GB frei, aber es wird angezeigt, dass kein Platz mehr auf dem Gerät vorhanden ist.“

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 - beobachten Sie, 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, sollten Sie 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:

Öffnen Sie ein zweites Terminal und überwachen Sie 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 Sie die Grenze erreicht haben.

Fehler 3: NGINX wird nach der Wiederherstellung nicht gestartet

Fehlermeldung:

nginx[34392]: [emerg] 34392#34392: open() "/etc/nginx/snippets/block-manager.conf" fehlgeschlagen (2: No such file or directory)
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. Erstellen Sie die fehlende Datei:

mkdir -p /etc/nginx/snippets
berühren Sie /etc/nginx/snippets/block-manager.conf

2. Testen Sie die NGINX-Konfiguration:

nginx -t

3. Starten Sie NGINX:

systemctl start nginx
systemctl status nginx

Wenn die Datei einen aktuellen Inhalt benötigt, überprüfen Sie Ihren 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, stellen Sie selektiv wieder her:

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

# Stellen Sie 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, achten Sie 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üfen Sie nach Abschluss der Wiederherstellung, ob alles funktioniert:

# 1. Alle wiederhergestellten Domains auflisten
virtualmin list-domains

# 2. Testen Sie die Web-Konnektivität
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 ihredomain.de @localhost

# 5. Prüfen Sie das Virtualmin-Modul
virtualmin test-domain --domain ihredomain.de

# 6. Überwachen Sie die Logs auf Fehler
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. Testen Sie 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 finden Sie 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. Sie müssen die Dateideskriptor-Limits erhöhen, bevor Sie Virtualmin-Backups wiederherstellen.
2. Die Systemgrenzen sind der wahre Feind, nicht der Speicherplatz. Selbst wenn 75 GB frei sind, erhalten Sie 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. Verwenden Sie 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 bleiben Sie nach Möglichkeit innerhalb derselben Hauptversion.
6. Überprüfen Sie die Integrität der Sicherung vor der Übertragung. Verwenden Sie 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 Sie diese Beschränkungen verstehen und die hier dokumentierten Korrekturen anwenden, können Sie 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 Sie auf eines dieser Probleme stoßen, kehren Sie zu diesem Leitfaden zurück - dort finden Sie die genaue Lösung.

Viel Glück bei Ihrer Migration. Mögen Ihre Backups schnell wiederhergestellt werden und Ihre 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.