Comment migrer son serveur Linux vers un VPS sans interruption

La migration serveur Linux VPS est une operation courante mais sensible : un transfert mal prepare peut couper un service en production, perdre des donnees ou casser des dependances applicatives. Ce tutoriel 2026 detaille une methode pragmatique, du gel de l'ancienne machine jusqu'au basculement DNS, avec des commandes reelles et les points de controle a ne pas negliger.

Preparer la migration serveur Linux VPS avant tout transfert

Une migration serveur Linux VPS reussie se joue surtout en amont. Avant de copier le moindre fichier, il faut cartographier precisement ce qui tourne sur la machine source, documenter les dependances et verifier la compatibilite avec la cible. Cette phase evite 80 % des incidents constates au basculement.

Inventaire de l'existant

Commencez par lister les services actifs, les paquets installes et les ports ouverts. Ces informations servent de reference pour valider la cible.

systemctl list-units --type=service --state=running
ss -tulpn
dpkg --get-selections > packages_source.txt
crontab -l
cat /etc/os-release

Notez egalement la version du noyau, l'architecture CPU et la configuration reseau. Sur un VPS moderne en KVM avec un kernel recent, la plupart des migrations se font sans surprise, mais un passage de Debian 11 a Rocky Linux 9 implique par exemple un changement de gestionnaire de paquets (apt vers dnf).

Choisir la cible et dimensionner

La cible doit couvrir la charge actuelle avec une marge. Les criteres neutres a comparer :

Critere	Impact
CPU dedie vs partage	Stabilite des temps de reponse sous charge
NVMe vs stockage classique	Latence I/O, critique pour bases de donnees
Anti-DDoS inclus	Disponibilite sans configuration supplementaire
Localisation datacenter	Latence vers vos utilisateurs France/UE
Panel et console KVM	Recuperation possible meme sans SSH

Pour un hebergement en Europe avec stockage SSD SAS et une mitigation volumetrique geree cote infrastructure, les VPS Linux OmegaCloud couvrent la majorite des profils applicatifs. La console KVM accessible depuis le panel OmegaCloud est un filet de securite indispensable pendant un basculement.

Figer l'etat et sauvegarder

Avant de copier quoi que ce soit, prenez un snapshot de la machine source si votre fournisseur le permet, puis realisez une sauvegarde exploitable des donnees applicatives.

# Sauvegarde d'une base MySQL/MariaDB
mysqldump --single-transaction --routines --triggers \
  -u root -p --all-databases > dump_all.sql

# Archive des donnees web et configs
tar czf site_data.tar.gz /var/www /etc/nginx /etc/php

Regle de terrain : une migration ne commence jamais tant qu'une sauvegarde restaurable n'a pas ete testee ailleurs. Un dump non teste n'est pas une sauvegarde.

Realiser le transfert des donnees et des services

Le coeur de la migration serveur Linux VPS consiste a reproduire fidelement l'environnement sur la cible, puis a synchroniser les donnees avec un minimum d'interruption. Deux approches cohabitent : la reinstallation propre (recommandee) et la copie integrale.

Securiser l'acces SSH de la cible

Premiere action sur le nouveau VPS : durcir l'acces avant d'y transferer des donnees. Generez une paire de cles et desactivez l'authentification par mot de passe.

# Sur votre poste local
ssh-keygen -t ed25519 -C "migration-vps-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@IP_CIBLE

Puis cote serveur cible, dans /etc/ssh/sshd_config :

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

systemctl restart ssh

Mettre en place le pare-feu

Configurez le filtrage des le depart. ufw suffit pour la plupart des cas, nftables pour les besoins plus fins.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable
ufw status verbose

La protection contre les attaques volumetriques (floods UDP/SYN) est deja assuree au niveau de l'infrastructure OmegaCloud, de maniere transparente. Votre pare-feu local se concentre donc sur le filtrage applicatif et la reduction de la surface d'exposition, pas sur la mitigation DDoS brute.

Transferer les donnees avec rsync

rsync reste l'outil de reference : il transfere en delta, reprend apres interruption et preserve les permissions.

# Copie incrementielle des donnees web
rsync -avzP --delete /var/www/ root@IP_CIBLE:/var/www/

# Configs serveur
rsync -avzP /etc/nginx/ root@IP_CIBLE:/etc/nginx/

Sur la cible, importez la base apres avoir installe le moteur :

apt update && apt install -y mariadb-server
mysql -u root -p < dump_all.sql

Reinstaller les paquets applicatifs

Plutot que de copier les binaires, reinstallez proprement les paquets a partir de l'inventaire. Vous evitez ainsi de trainer des dependances obsoletes.

# Debian/Ubuntu
apt update
apt install -y nginx php-fpm php-mysql certbot python3-certbot-nginx

# Verification des versions
php -v
nginx -v

Si votre stack utilise des conteneurs, embarquez vos images via un registre et relancez-les sur la cible :

docker compose pull
docker compose up -d
docker ps

Gerer les certificats TLS

Avant le basculement DNS, Let's Encrypt ne pourra valider le domaine que si celui-ci pointe encore vers l'ancienne machine. Deux options : copier les certificats existants depuis /etc/letsencrypt, ou generer de nouveaux certificats juste apres le changement de DNS. La copie est plus sure pour eviter toute coupure HTTPS.

rsync -avzP /etc/letsencrypt/ root@IP_CIBLE:/etc/letsencrypt/

Valider, basculer et securiser apres migration

La derniere etape d'une migration serveur Linux VPS est souvent bâclee : on bascule le DNS puis on espere. Une validation methodique avant et apres le switch fait la difference entre une migration invisible et une interruption de service.

Tester avant basculement

Forcez la resolution locale vers la nouvelle IP sans toucher au DNS public, en editant votre fichier hosts de poste de travail :

# /etc/hosts (Linux/macOS) ou C:\Windows\System32\drivers\etc\hosts
IP_CIBLE  exemple.com www.exemple.com

Parcourez ensuite le site, testez les formulaires, les connexions base de donnees, les taches planifiees et les envois d'emails. Verifiez les logs en temps reel :

journalctl -u nginx -f
tail -f /var/log/php*-fpm.log

Reduire le TTL puis basculer le DNS

Quelques heures avant la migration, abaissez le TTL des enregistrements concernes (par exemple 300 secondes). La propagation sera ainsi quasi immediate au moment du basculement. La gestion DNS depuis le panel permet d'ajuster les enregistrements A/AAAA sans attendre.

Etape	Action	Delai conseille
1	Baisser le TTL a 300s	J-1
2	Geler les ecritures source	H-0
3	Rsync final + import delta	H-0
4	Modifier enregistrement A/AAAA	H-0
5	Surveiller logs + remonter TTL	H+1

Pour un dernier passage incrementiel juste avant le switch, relancez rsync : seuls les fichiers modifies seront transferes, ce qui reduit la fenetre d'indisponibilite a quelques secondes.

Durcir la machine apres migration

Une fois le trafic bascule, finalisez la securisation. Installez fail2ban pour bloquer les tentatives de brute force SSH et applicatives.

apt install -y fail2ban
systemctl enable --now fail2ban
fail2ban-client status sshd

Checklist post-migration :

• Authentification SSH par cle uniquement, mot de passe desactive.
• 2FA active sur le panel de gestion.
• Pare-feu ufw/nftables actif et audite.
• Certificats TLS valides et renouvellement automatique teste (certbot renew --dry-run).
• Sauvegardes planifiees et snapshots configures.
• Monitoring CPU/RAM/SSD/reseau en place.

Automatiser les migrations futures

Pour eviter de refaire manuellement ces etapes, capitalisez via l'API et les integrations OmegaCloud : provisioning automatise, webhooks et pipelines CI/CD avec GitHub Actions ou GitLab CI permettent de reconstruire un environnement de maniere reproductible. Une configuration decrite en code (gestionnaire de config + scripts d'installation) transforme la prochaine migration en simple execution de pipeline.

Pour aller plus loin sur l'administration systeme et le reseau, la documentation officielle reste la reference : Source.

Conclusion

Migrer un VPS Linux n'a rien de risque lorsque chaque etape est preparee : inventaire, sauvegarde testee, transfert incrementiel, validation via le fichier hosts et basculement DNS a TTL reduit. En durcissant l'acces des le depart et en automatisant ce qui peut l'etre, vous transformez une operation redoutee en procedure maitrisee et repetable. La rigueur prime toujours sur la vitesse.

FAQ

Combien de temps dure une migration serveur Linux VPS en production ?

La preparation (inventaire, sauvegarde, installation cible) prend le plus de temps, souvent quelques heures. Le basculement reel, lui, se limite a quelques secondes ou minutes si vous avez reduit le TTL DNS et effectue un rsync incrementiel final. La fenetre d'indisponibilite depend surtout du volume de donnees ecrites entre la copie initiale et le switch.

Comment eviter toute coupure HTTPS pendant la migration ?

Copiez le dossier /etc/letsencrypt depuis l'ancienne machine vers la nouvelle avant le basculement DNS. Les certificats restent valides puisqu'ils ne dependent pas de l'IP. Verifiez ensuite le renouvellement automatique avec certbot renew --dry-run une fois le DNS bascule.

Faut-il copier le systeme entier ou reinstaller proprement ?

La reinstallation propre est preferable : vous repartez d'un OS a jour, sans dependances obsoletes ni fichiers residuels. Reproduisez l'environnement a partir de votre inventaire de paquets et ne transferez que les donnees applicatives et les configurations. La copie integrale ne se justifie que pour des setups legacy difficiles a reconstruire.