Comment cloner un serveur Linux et ses services ?

Nous avons récemment été confrontés à une demande fréquente dans le paysage IT : le rapatriement d'un serveur d'entreprise géré et hébergé par un infogérant. Cette situation, loin d'être isolée, soulève une série de questions cruciales pour la continuité de service et la conformité.

Les défis et questions stratégiques de la migration

Lors du rapatriement d'une infrastructure externalisée, plusieurs interrogations techniques et contractuelles se posent :

• Comment être certain de récupérer toutes les configurations de chaque service ?
• Le serveur actuel est-il une machine virtuelle (VM) ? Peut-on nous l’exporter ? Sera-t-il compatible avec notre hyperviseur si nous souhaitons le virtualiser ?
• L’infogérant en place va-t-il accepter de nous aider à migrer ce serveur ? Quel est le niveau d'assistance que l'infogérant en place est disposé à fournir pour cette transition ? Va-t-il nous aider à migrer ce serveur et être coopératif ?
• Comment limiter la coupure de service pour les utilisateurs et/ou clients ? (downtime)
• Est-il plus malin de faire une fresh install ? En espérant retrouver les mêmes versions des runtimes…

Même si une réinstallation complète peut sembler l'option la plus "propre" sur le plan architectural, le coût et le temps nécessaires peuvent dépasser ceux d'une simple migration. Et il existe probablement d’autres raisons qui vous poussent à vouloir cloner votre serveur au lieu de le réinstaller complètemen (applicatifs propriétaires, configurations complexes non documentées...).

Objectifs d'un clonage de serveur

Notre objectif est de réaliser une réplique exacte d'un serveur source (qu'il s'agisse d'une instance, d'un VPS, d'un serveur dédié ou d'une VM), à chaud, en exploitant l'outil rsync.

rsync est un utilitaire open source et gratuit, prévu pour le transfert et la synchronisation de fichiers.

Notre objectif, avec la méthode que nous détaillons, ci-dessous est de récupérer l'intégralité :

• Des données applicatives.
• Du système d'exploitation et de ses dépendances.
• Des services installés (web, base de données, etc.).

Mon objectif est de récupérer le système, les services, les données de ce serveur et de les réutiliser dans une VM qui va garder le même type de ressources CPU/RAM.

À l’issue de cette manipulation, je pourrai rediriger les DNS qui pointent vers mon service, éventuellement changer des pare-feux pour laisser passer la nouvelle IP de mon serveur et le tour est joué.

Pour mon exemple, il est question d’un serveur web, avec un site en PHP et une base de données, le tout sous Debian 12.8. J’ai un service avec 8 cœurs, 16 Go de RAM, et 50 Go de stockage.

Prérequis

Pour le clonage, il faut se préparer un peu :

• Avoir un accès root ou sudo au serveur à cloner (serveur A)
• Avoir mis en place un serveur de cible (serveur B), réseau paramétré, accessible en SSH depuis le serveur A
• A et B doivent utiliser les mêmes distributions, dans les mêmes versions (exemple : Debian 12.8)
• A et B doivent avoir un système de fichiers identique (ext4, xfs, zfs, btrfs…). Vous pourrez difficilement cloner un serveur en RAID logiciel sur un serveur qui ne l’est pas et inversement.
• Avoir installé rsync sur A et B pour permettre de faire un miroir de A vers B. Sous Debian/Ubuntu :

Préparer le clonage de son serveur

Sur un système Linux, il existe des dossiers qu’il ne faut pas copier. Je pense à /dev qui gère les périphériques et composants de la machine, par exemple. Il y a aussi /sys, /proc dans le même genre, et puis des dossiers ou fichiers pour lesquels on souhaite garder le bon fonctionnement du serveur B en place, comme /etc/fstab pour le montage de mes disques qui peuvent être différents sur B, /etc/mdadm.conf si j’ai du RAID, ou encore la configuration réseau /etc/network, par exemple.

Il y a aussi des dossiers que je ne souhaite pas copier pour d’autres raisons, comme par exemple /home/infogerant ou /tmp.

Je prends le temps de lister ce que je ne veux pas copier, voici une liste prête à copier/coller pour le commun des mortels :

/boot
/dev
/sys
/proc
/etc/fstab
/etc/mtab
/etc/mdadm.conf
/etc/network

Et voici la suite de la liste, avec des choses que je ne souhaite pas copier. Là, c’est à vous de faire votre liste et de l’ajouter à la suite de la première :

/tmp
/backup
/home/infogerant

Je crée un seul fichier que je vais mettre dans /tmp/clonage-exclusion qui contiendra mes deux listes l’une à la suite de l’autre.

Cloner son serveur avec rsync

Tout est fin prêt ! Voici donc venu le moment de faire ma copie.

ATTENTION !
Si j'ai des données qui varient sur le serveur (base de données, cache...), c'est le bon moment pour arrêter mes services proprement, faute de quoi la copie pourrait être incomplète ou corrompue.

J’ai bien fait un systemctl stop mysql ? Alors feu 🔥🔥🔥

Je lance la copie de A vers B (depuis le serveur A), idéalement dans un multiplexeur de terminal pour limiter les problématiques si je suis en SSH. J’utilise tmux dans mon cas, qu’on installe avec apt install tmux et qu’on lance avec la commande tmux. Ça permet de pouvoir perdre l’accès à mon terminal et de pouvoir le retrouver avec la commande tmux a (pro tip 😉).

sudo rsync -vPa -e 'ssh -o StrictHostKeyChecking=no' --exclude-from=/tmp/clonage-exclusion / root@adresse.IP.serveur.B:/

sudo : pour avoir accès à tous les fichiers et dossiers. (Optionnel si je suis déjà avec l’utilisateur root.)
-v : activer le mode verbeux. Cette option affichera à l’écran ce qu’il se passe en temps réel. (Optionnel)
-P : est équivalente à --partial --progress. Je mets cette option car ma copie peut être longue et peut être interrompue.
-a : ceci est équivalent à -rlptgoD et indique que je souhaite tout cloner.
-e : me permet d’utiliser un autre logiciel pour le transfert des fichiers (ici SSH).
-o StrictHostKeyChecking=no : ne pas vérifier la destination (optionnel, limite le nombre d’interactions en lançant la commande).
J’aurais aussi pu ajouter :
-p 2222 : pour spécifier un port SSH custom (ici 2222).
-i /root/.ssh/id_rsa : pour donner la clé SSH qui permet de se connecter au serveur cible B.
--exclude-from=/tmp/clonage-exclusion : la liste des choses que je ne souhaite pas cloner.
/ : la base du stockage du serveur A pour indiquer que je veux tout copier. J’aurais aussi pu ne copier que /home et ses dossiers enfants, par exemple.
root@adresse.IP.serveur.B:/ : comment joindre le serveur B (utilisateur@adresse IP:dossier cible. Ici, on copie de / vers / (la racine de chaque serveur).

N’oubliez pas de changer adresse.IP.serveur.B par l’adresse IP à laquelle contacter B (comme 192.168.1.23, par exemple).

Résultat :

Vérifier le bon état de fonctionnement

Sur le serveur B, tout devrait y être. On va donc redémarrer le serveur B et vérifier que tout va bien, qu’il redémarre et que mes services sont démarrés.

Pour PHP 8.2, par exemple : service php8.2-fpm status

Tout est bon ! Je rappelle que sur le serveur B, je n’ai jamais installé PHP du tout, c’est la copie via rsync qui s’est chargée de répliquer les logiciels installés. Notez donc que les identifiants/mots de passe que j’ai configurés sur le serveur B ont été remplacés par ceux du serveur A (y compris les clés SSH autorisées).

💡Astuce : Je teste aussi que les ports sont correctement ouverts et disponibles depuis les serveurs qui doivent contacter le mien avec la commande alive. Cela me fait gagner un temps fou car un port qui répond signifie un service correctement démarré et un pare-feu bien configuré

Il est désormais temps, si je le souhaite, de rediriger les DNS vers mon serveur B et de décommissionner le serveur A !

Avantages et inconvénients de la méthode

Ce clonage impose de prendre quelques précautions en amont :

• Vérifier qu’une fois cloné, les règles de pare-feu soient toujours cohérentes dans la mesure où les IP (publique/privée) du serveur vont changer.
• Vérifier à l’inverse que la nouvelle IP est autorisée sur les autres serveurs à joindre (API, serveur de sauvegarde, NFS…).
• S’assurer que le monitoring du serveur va suivre.
• Être certain d’avoir des accès root ou sudoers sur le serveur A car ils seront nécessaires sur le serveur B.

Il existe aussi des étapes après le clonage comme :

• Effacer les accès de l’ancien infogérant qui a pour le moment toujours accès à mon serveur B.
• Effacer les logiciels que l’infogérant précédent a pu installer pour ses services (son monitoring si jamais, son service de backup, ses scripts et outils qui sont peut-être propriétaires, et pour ça le contacter est une bonne idée).

Mais j’ai aussi de bons retours de cette expérience :

• J’ai cloné un serveur de type inconnu (probablement un VPS) sur une VM, mais j’aurais pu le faire sur un conteneur LXC aussi.
• J’ai cloné ce serveur avec un partitionnement complexe (/home, /boot, /var dans des partitions différentes) sur un seul disque, ce qui convient pour le besoin.
• J’aurais tout à fait pu faire l’inverse de ce qui est dit sur le point précédent !
• J’en ai profité pour réduire la taille du disque (8 Go étaient utilisés sur 50 Go, j’ai donc cloné vers un disque de 15 Go).
• Le temps total de clonage/migration a été inférieur à 1 heure.
• Cette méthode pourrait aussi être utilisée pour un service stateless (une API ou un site vitrine sans base de données par exemple) afin d’en avoir une copie de staging ou dans un but de load balancing.

C’est donc une expérience réussie et fonctionnelle à connaître. Enjoy !