Guide complet de la migration des serveurs Virtualmin : Résoudre les erreurs courantes et les limites

Introduction

Migrer d'un VPS à un autre avec Virtualmin Gérer plus de 10 domaines WordPress semble simple en théorie : sauvegarder sur l'ancien serveur, restaurer sur le nouveau, et le tour est joué. En réalité, c'est un champ de mines de limites cachées du système, de contraintes de descripteurs de fichiers et de problèmes d'espace disque qui peuvent vous laisser bloqué pendant des heures.

J'ai récemment réalisé une migration Virtualmin difficile à partir d'un système de gestion de l'information. Debian 12 en France vers un nouveau VPS Debian 13 aux Pays-Bas, déplaçant plus de 4,4 Go de données de sauvegarde à travers plus de 10 domaines. Au cours de ce processus, j'ai rencontré toutes les erreurs majeures auxquelles les administrateurs de Virtualmin sont confrontés, et je les ai toutes résolues. Cet article documente les problèmes et les solutions exactes afin que vous n'ayez pas à les apprendre à la dure.

Que vous souhaitiez mettre à niveau votre fournisseur de VPS, passer à l'échelle horizontale ou récupérer un serveur défaillant, ce guide vous guidera à travers les erreurs du monde réel et leurs correctifs.

---

Partie 1 : Planification et préparation de la migration

Choisir les spécifications de votre VPS cible

Avant de toucher à quoi que ce soit sur votre serveur actuel, assurez-vous que votre nouveau VPS dispose de ressources adéquates. L'erreur la plus fréquente est de croire que seul l'espace disque compte - ce n'est pas le cas.

Spécifications minimales pour Virtualmin avec 10+ domaines :

• Espace disque : 100GB (pas 50GB - les sites WordPress avec sauvegardes grandissent vite)
• CPU : 6+ cœurs (8+ cœurs recommandés pour 10+ domaines)
• RAM : 8GB minimum (15GB+ pour la production)
• Échange : 4 Go (ajoutés après l'installation du système d'exploitation s'ils ne sont pas préconfigurés)

Votre nouveau serveur doit être équivalent ou supérieur à votre ancien serveur en termes de CPU et de RAM, avec plus d'espace disque. Virtualmin est très gourmand en ressources processeur et en E/S lors des opérations de restauration - un processeur faible rendra la restauration laborieuse.

Liste de contrôle pré-migration

Sur votre ancien serveur (48 heures avant la migration) :

1. Réduire le TTL DNS à 300 secondes (5 minutes) pour minimiser les problèmes de cache :

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

2. Créer une nouvelle sauvegarde en respectant le format recommandé par Virtualmin :

mkdir /backup
virtualmin backup-domain \N- --dest /backup/ \N
  --dest /backup/ \N- -all-domains
  --all-domains \N-all-domains
  --all-features \N-all-features
  --newformat

3. Vérifier l'intégrité de la sauvegarde avant le transfert :

tar -tzf /backup/backup_*.tar.gz > /dev/null && echo "Backup OK" || echo "Sauvegarde corrompue"

4. Notez la taille de votre base de données pour la planification :

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. Vérifier les configurations personnalisées qui pourraient ne pas être transférés :
   • Versions personnalisées de PHP
   • Configurations NGINX modifiées
   • Travaux Cron dans /etc/cron.d/
   • Certificats SSL personnalisés

---

Partie 2 : Le processus de migration

Étape 1 : Transfert du fichier de sauvegarde

Utilisation SCP avec sommes de contrôle pour vérifier l'intégrité du fichier :

# Sur l'ancien serveur, générer la somme de contrôle
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Transférer la sauvegarde et la somme de contrôle
scp /backup/backup_*.tar.gz root@new-server.com:/Files/
scp /backup/backup.sha256 root@new-server.com:/Files/

# Sur le nouveau serveur, vérifier
cd /Files/
sha256sum -c backup.sha256

Si les sommes de contrôle ne correspondent pas, arrêter immédiatement. Le fichier a été corrompu pendant le transfert. Transférez à nouveau ou utilisez rsync avec des sommes de contrôle :

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

Étape 2 : Installer Virtualmin sur le nouveau serveur

Utilisez l'installateur officiel de Virtualmin :

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

Important : Installez la même version du système d'exploitation (ou une version proche) - ce point est plus important qu'on ne le pense. J'ai migré de Debian 12 à Debian 13 (ce n'est pas recommandé, mais c'est faisable). Restez dans la même version majeure si possible.

Étape 3 : Configuration du système avant la restauration

C'est là que la plupart des migrations échouent. Avant de toucher à la restauration, corrigez ces trois limites critiques :

Correction 1 : Augmenter les descripteurs de fichiers ouverts

Il s'agit de la #1 cause des erreurs “No space left on device” lors de la restauration, même lorsque l'espace disque est abondant.

# Vérifier la limite de courant
ulimit -n
# Probablement : 1024 (trop faible pour Virtualmin)

# Augmenter la limite pour la session en cours
ulimit -n 65536

# Vérifier
ulimit -n
# Devrait s'afficher : 65536

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

Pourquoi 65536 ? Chaque fichier ouvert, socket, pipe et connexion à une base de données consomme un descripteur de fichier. Avec plus de 10 sites WordPress, des serveurs de messagerie, des travailleurs NGINX et des connexions MySQL, vous dépassez facilement 1024. OVH et d'autres fournisseurs ont défini cette valeur conservatrice par défaut pour des raisons de sécurité - elle est destinée à être augmentée pour chaque application.

Correction 2 : Agrandir /tmp (tmpfs)

Lors de la restauration, Virtualmin crée des dumps MySQL dans le répertoire /tmp/. Par défaut, /tmp est un tmpfs (disque RAM) limité à ~50% de RAM totale. Avec 11GB de RAM, /tmp ne dépasse pas 5,8 Go. Mais Virtualmin peut facilement générer 5-6GB de fichiers temporaires pendant la restauration.

# Vérifier la taille actuelle de /tmp
df -h /tmp

# Redimensionner dynamiquement le disque sans le démonter
mount -o remount,size=8G /tmp

# Vérifier
df -h /tmp

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

Correction 3 : Ajouter de l'espace de pagination

Si la restauration consomme toute la mémoire vive, le système ne répond plus. Une mémoire tampon de 4 Go permet d'assurer la sécurité :

# Créer un fichier d'échange de 4 Go
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Rendre permanent
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Vérifier
swapon --show

---

Partie 3 : Processus de restauration et erreurs courantes

Erreur 1 : “Vérification du contenu de la sauvegarde ...” Reste bloqué pendant plus de 20 minutes

À quoi cela ressemble-t-il ?

Vérification du contenu de la sauvegarde .

[bloqué pendant 15 à 30 minutes sans progrès].

Cause première : Il ne s'agit pas d'un blocage, mais d'une lenteur légitime. La fonction tar -tzf lit l'intégralité de l'archive compressée de 4,4 Go, vérifie chaque en-tête de fichier et contrôle l'intégrité du tar. Sur les anciens processeurs (comme Haswell), cette opération peut prendre plus de 20 minutes pour une sauvegarde de 4 Go.

Solution :

1. Pas de panique. Vérifier si tar est en cours d'exécution :

ps aux | grep tar
iostat -x 1 # Vérifier l'activité du disque

2. Utiliser la restauration CLI au lieu de l'interface web (contourne le délai de vérification) :

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

Le --reuid ajuste automatiquement les identifiants des utilisateurs/groupes, ce qui est essentiel lors de la restauration sur différents systèmes.

Erreur 2 : “/bin/tar : Cannot write : No space left on device”

À quoi cela ressemble-t-il ?

/bin/tar : ./seo.grahammiranda.com_mail_users : Impossible d'écrire : Pas d'espace disponible sur le périphérique
/bin/tar : ./esim.grahammiranda.com_virtualmin_ssl_key : Écriture impossible : Il n'y a plus d'espace disponible sur le périphérique

[des dizaines d'autres erreurs de ce type]

/bin/tar : Exit with failure status due to previous errors

La partie déroutante : Vous avez 75 Go de libre, mais le message “Il ne reste plus d'espace sur l'appareil” s'affiche.”

Causes profondes (par ordre de probabilité) :

1. Limite des descripteurs de fichiers atteinte (le plus fréquent)
   • Symptôme : Les erreurs apparaissent 5 à 10 minutes après la restauration, et non au début.
   • Fixer : ulimit -n 65536 (voir ci-dessus)
2. /tmp se remplit (deuxième cas le plus fréquent)
   • Symptôme : Erreurs concernant MySQL ou les fichiers temporaires
   • Vérifier : df -h /tmp lors de la restauration, regarder le remplissage à 100%
   • Fixer : mount -o remount,size=8G /tmp (voir ci-dessus)
3. L'espace disque actuel est épuisé (moins fréquent mais possible)
   • Vérifier : df -h / montre <5GB libre
   • Solution :

# Nettoyer l'échec de la restauration
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/*

# Si la sauvegarde se trouve toujours dans /Files, envisagez de la déplacer
mv /Files/backup_*.tar.gz /mnt/ # Déplacer vers une autre partition si elle est disponible

4. Épuisement des inodes (rare)
   • Vérifier : df -i / montre >90% iUsed
   • Cause : Système de fichiers créé avec trop peu d'inodes
   • Solution : Reformatage du système de fichiers avec plus d'inodes (destructif)

Approche diagnostique lors de la restauration :

Ouvrez un deuxième terminal et surveillez en temps réel :

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

Cela permet de savoir exactement quand et où vous avez atteint la limite.

Erreur 3 : NGINX ne démarre pas après la restauration

Message d'erreur :

nginx[34392] : [emerg] 34392#34392 : open() "/etc/nginx/snippets/block-manager.conf" failed (2 : No such file or directory)
nginx : le test du fichier de configuration /etc/nginx/nginx.conf a échoué

Cause première : La restauration a partiellement échoué, ou certains fichiers n'ont pas été transférés correctement. Les configurations NGINX font référence à des fichiers qui n'existent pas.

Solution :

1. Créer le fichier manquant :

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

2. Tester la configuration de NGINX :

nginx -t

3. Démarrer NGINX :

systemctl start nginx
systemctl status nginx

Si le fichier a besoin d'un contenu réel, vérifiez votre ancien serveur :

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

---

Partie 4 : Solutions avancées et optimisation

Restauration d'un domaine à la fois (approche la plus sûre)

Si la restauration complète continue d'échouer malgré les correctifs, procédez à une restauration sélective :

# Nettoyer les tentatives précédentes qui ont échoué
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Restaurer le domaine principal en premier lieu
virtualmin restore-domain \N- --source /Files/backback
  --source /Files/backup_*.tar.gz \N- --domaine grahammir
  --domaine grahammiranda.com \N-all-features \N
  --all-features \N-all-features \N
  --reuid

Cela permet d'isoler les domaines qui posent problème. Si l'un d'entre eux est restauré avec succès, le modèle fonctionne pour les autres.

Considérations sur la migration de Debian 12 vers Debian 13

J'ai migré de Debian 12 à Debian 13. Bien que généralement compatible, il faut faire attention à :

1. Différences entre les versions de PHP : Debian 12 peut avoir PHP 8.1, Debian 13 a 8.3.
   • Vérifier : php -v sur les deux serveurs
   • Enjeu : Rares problèmes de compatibilité avec les anciennes extensions PHP
   • Fixer : Forcer l'ancienne version de PHP : virtualmin modify-web --domaine exemple.com --php-version 8.1
2. Syntaxe de configuration de NGINX/Apache : Généralement compatible, mais à tester après restauration
   • Test : nginx -t et apache2ctl configtest
3. Compatibilité MySQL/MariaDB : Généralement compatible avec l'avenir
   • Vérifier : mysql --version sur les deux serveurs
   • Différences de format de vidage : Rare, mais les nouvelles Debian peuvent avoir des modes SQL plus stricts.
4. Compatibilité avec les certificats SSL : Pas de problème entre les versions de Debian, mais vérifiez :

certbot certificats # Vérifier les certificats Let's Encrypt

---

Partie 5 : Vérification après la migration

Contrôles essentiels avant la mise en service

Une fois la restauration terminée, vérifiez que tout fonctionne :

# 1. Lister tous les domaines restaurés
virtualmin list-domains

# 2. Tester la connectivité web
curl -I https://yourdomain.com

# 3. Vérifier la fonctionnalité du courrier
mysql -u root -p 'password" -e "SELECT user FROM mysql.user ;"

# 4. vérifier le DNS
dig yourdomain.com @localhost

# 5. Vérifier le module Virtualmin
virtualmin test-domain --domain votredomaine.com

# 6. Recherchez les erreurs dans les journaux
journalctl -f
tail -f /var/log/nginx/error.log

Mise à jour des enregistrements DNS

Une fois que tous les domaines ont été restaurés avec succès :

1. Mise à jour des serveurs de noms du bureau d'enregistrement pour pointer vers le nouveau serveur
2. Contrôle du compte à rebours TTL (devrait être de 5 minutes avec un TTL réduit)
3. Test à partir de plusieurs endroits :

nslookup votredomaine.com
dig yourdomain.com +short

4. Remettre le TTL du DNS à la normale après 24-48 heures :

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

---

Partie 6 : Limites du système Référence

Pour référence future, voici toutes les limites du système vérifiées au cours de cette migration :

# Limites utilisateur/processus
ulimit -a # Toutes les limites
ulimit -n # Fichiers ouverts
ulimit -u # Nombre maximal de processus
ulimit -v # Mémoire virtuelle

# Limites pour l'ensemble du système
cat /proc/sys/fs/file-max # Fichiers ouverts à l'échelle du système
cat /proc/sys/kernel/pid_max # ID de processus maximaux
cat /proc/sys/vm/max_map_count # Limite de la carte mémoire

# Utilisation actuelle des ressources
df -h # Espace disque
df -i # Utilisation des inodes
free -h # RAM et swap
ps aux | wc -l # Processus en cours d'exécution
lsof | wc -l # Descripteurs de fichiers ouverts

# Spécificités du système de fichiers
mount | grep /dev/sda1 # Options de montage
quota -s # Quotas de disque
tune2fs -l /dev/sda1 # Propriétés du système de fichiers

---

Principaux enseignements

1. OVH (et la plupart des fournisseurs) fixent des valeurs par défaut prudentes. Vous devez augmenter les limites des descripteurs de fichiers avant de restaurer les sauvegardes de Virtualmin.
2. Les limites du système sont le véritable ennemi, pas l'espace disque. Même avec 75 Go gratuits, vous obtiendrez le message “Il ne reste plus d'espace sur l'appareil” si /tmp est plein ou que les descripteurs de fichiers sont épuisés.
3. Augmentation /tmp avant la restauration. Virtualmin crée 5-6GB de fichiers temporaires lors de la restauration des sauvegardes. L'allocation par défaut de tmpfs n'est pas suffisante.
4. Utilisez la restauration CLI, pas l'interface web. L'interface Web présente des problèmes de dépassement de délai pour les sauvegardes volumineuses. La restauration en ligne de commande est plus fiable et affiche la progression réelle.
5. La migration de Debian 12 vers Debian 13 fonctionne, mais la même version est plus sûre. Les différences de version mineures posent rarement des problèmes, mais restez dans la même version majeure si possible.
6. Vérifier l'intégrité de la sauvegarde avant de la transférer. Utilisez les sommes de contrôle SHA256 pour vous assurer que le fichier de sauvegarde n'a pas été corrompu pendant le transfert.
7. La planification de la pré-migration permet de gagner des heures. La réduction du TTL DNS, la vérification de la taille des bases de données et la préparation du serveur cible permettent d'éviter la plupart des problèmes.

---

Conclusion

La migration de Virtualmin n'est pas difficile, elle est juste délicate. La plupart des échecs ne sont pas dus à Virtualmin lui-même, mais aux limites cachées du système fixées par les fournisseurs d'hébergement. En comprenant ces contraintes et en appliquant les correctifs documentés ici, vous pouvez migrer plus de 10 sites WordPress d'un serveur à l'autre de manière fiable.

Les erreurs spécifiques que j'ai rencontrées (limites du descripteur de fichier, /tmp épuisement, snippets NGINX manquants) sont reproductibles et courants. Si vous rencontrez l'un d'entre eux, revenez à ce guide - vous y trouverez la solution exacte.

Bonne chance pour votre migration. Que vos sauvegardes se restaurent rapidement et que vos domaines soient mis en ligne sans problème.

---

Bio de l'auteur

Ce guide documente une migration réelle de Virtualmin achevée en février 2026, migrant 10+ domaines de production d'un VPS Debian 12 (France) vers un VPS Debian 13 (Pays-Bas). Les solutions sont testées et vérifiées sur le terrain.