La plupart des migrations n'échouent pas pendant la copie. Elles échouent dans les vingt minutes qui suivent le changement DNS, quand la moitié d'internet parle encore à l'ancien serveur et que l'autre moitié est déjà passée à la suite — et que les deux machines acceptent des écritures. Les fichiers sont arrivés intacts, le site se charge, et pourtant des commandes atterrissent dans deux bases de données qui ne seront jamais réconciliées. Éviter cela n'a presque rien à voir avec la vitesse de transfert et presque tout à voir avec la séquence : ce que vous changez en premier, ce que vous gelez, et ce que vous laissez tourner jusqu'à être certain.
Ce que signifie vraiment l'absence d'interruption
Autant être précis, car l'expression recouvre deux promesses très différentes, qui coûtent des efforts très différents. Décider laquelle vous achetez est la première vraie décision de la migration.
S'il faut en sacrifier une, sacrifiez la disponibilité. Une page de maintenance de quatre minutes, ça s'explique. Des données divergentes, ça ne se répare pas, parce qu'il ne reste aucune autorité pour dire quelle copie était la bonne.
Notez, avant de commencer, le plus long gel des écritures que vous puissiez tolérer. Quatre minutes, trente secondes, zéro. Ce seul chiffre décide de tout ce qui suit — si un export puis restauration suffit, si vous avez besoin de réplication, ou si vous avez besoin d'un proxy devant tout l'ensemble. Choisir l'outillage avant de choisir le chiffre, c'est exactement comme ça que les migrations récoltent leurs surprises.
Faites l'inventaire avant de faire la copie
Un serveur accumule des choses que personne n'a documentées : une tâche cron ajoutée pendant un incident, une règle de pare-feu pour l'adresse d'un partenaire, une clé API collée dans un fichier de service. La copie ne les emportera pas, et vous les découvrirez une par une pendant la quinzaine qui suit. Une demi-heure d'inventaire maintenant élimine presque tout ça.
Ce qui écoute
Lancez ss -tulpn et rendez compte de chaque socket en écoute. Chacune est un service qui doit exister sur la nouvelle machine, et chaque port inexpliqué mérite d'être compris avant que vous ne le reproduisiez — une migration est un bon moment pour remarquer ce qui tourne depuis 2023.
Ce qui tourne sur un timer
crontab -l pour chaque utilisateur, root compris, systemctl list-timers, et tout planificateur interne à l'application elle-même. Les timers sont, de loin, la chose la plus fréquente à survivre à une migration en double exemplaire, et les doublons sont pires que les absences.
Ce qui n'est pas sur le disque
Les enregistrements DNS, le DNS inverse de votre adresse, les règles de pare-feu, les clés API détenues par des tiers, les cibles de webhook, et toute liste blanche ailleurs qui nomme votre IP actuelle. Rien de tout ça ne vit dans le système de fichiers que vous êtes sur le point de copier.
Ce que l'application suppose
Des chemins absolus codés en dur, un nom d'hôte dans un fichier de configuration, l'emplacement d'un socket de base de données, une adresse dans une directive bind. Ce sont les choses qui cassent silencieusement — le service démarre, puis ne fonctionne pas.
Écrivez tout ça dans un fichier conservé sous contrôle de version, pas dans l'historique défilant d'un terminal. Vous le relirez trois fois pendant la bascule, dont une fois à un moment où vous ne penserez pas clairement.
Choisissez la destination sur les critères que vous ne pourrez plus changer ensuite
Les caractéristiques techniques s'ajustent ; quelques propriétés ne s'ajustent pas, et celles-là méritent d'être décidées délibérément tant que vous avez encore le choix. Puisque vous déménagez de toute façon, c'est le moment le moins coûteux que vous aurez jamais pour corriger une contrainte que vous contourniez jusqu'ici.
- L'emplacement, parce qu'il fixe à la fois la latence vers vos utilisateurs et le droit applicable. /locations liste les régions et leurs caractéristiques d'aller-retour ; choisissez-en une qui tombe en panne indépendamment de celle que vous quittez.
- L'assise juridique, si la raison du déménagement est que votre fournisseur actuel transmet les plaintes plus vite qu'il ne transmet les paquets. /offshore-hosting expose ce que la juridiction contrôle vraiment, et ce qu'elle ne contrôle pas.
- L'identité de facturation, parce qu'un hébergeur qui exige des documents avant d'accepter un paiement possède, par construction, un dossier sur vous. /no-kyc-vps et /pay-with décrivent l'alternative — un solde rechargé en crypto, aucune carte, aucun nom rattaché à la machine.
- La marge, parce que migrer deux fois est le résultat que personne ne prévoit. /vps liste les offres, et /guides propose la méthode de dimensionnement si la machine actuelle n'a en réalité jamais été mesurée.
- IPv6 et une IPv4 propre, car une adresse recyclée peut arriver en portant la réputation de quelqu'un d'autre — vérifiez-la avant que ça ne devienne un problème de mail.
Baissez d'abord le TTL DNS, plusieurs jours à l'avance
C'est la seule étape de préparation qu'on ne peut pas précipiter à la fin, parce que son effet est conditionné par une horloge que vous ne contrôlez pas. Le TTL de vos enregistrements indique aux résolveurs combien de temps mettre une réponse en cache. S'il est réglé sur un jour, un résolveur qui a interrogé il y a une heure continuera d'envoyer les utilisateurs vers l'ancien serveur pendant les vingt-trois heures suivantes, quoi que vous publiiez.
- 1
Relevez le TTL actuel
dig +noall +answer yourdomain.com affiche le temps de cache restant ; interroger directement votre serveur de noms faisant autorité avec dig @ns1.example.net yourdomain.com affiche la valeur configurée. Notez-la — elle fixe la durée de votre période d'attente.
- 2
Ramenez-le à 300 secondes
Baissez le TTL sur chaque enregistrement qui va changer : A, AAAA, et tout MX ou CNAME pointant vers la machine. Cinq minutes, c'est assez court pour rendre la bascule confortable, et assez long pour ne pas marteler vos serveurs de noms.
- 3
Laissez passer l'ancien TTL, puis attendez encore
Le nouveau TTL court n'atteint un résolveur qu'une fois que l'ancien, plus long, a expiré. Attendez au moins une période complète de l'ancien TTL — un jour si c'était un jour — avant de considérer le TTL bas comme effectif. Commencer tôt ne coûte rien et offre à toute la bascule sa marge de manœuvre.
Certains résolveurs ignorent votre TTL et mettent en cache selon leur propre minimum de toute façon, et une fraction des clients met en cache pour toute la durée de vie du processus. Prévoyez une longue traîne de trafic qui continue d'atteindre l'ancienne adresse pendant des heures après un changement pourtant parfaitement exécuté. Ce n'est pas une raison pour sauter le travail sur le TTL — c'est la raison pour laquelle l'ancien serveur doit rester vivant après coup.
Construisez le nouveau serveur, ne clonez pas l'ancien
Le réflexe, c'est d'imager le disque actuel et de le restaurer ailleurs. C'est le mauvais choix, pour la même raison qu'en restauration : un clone au niveau bloc reproduit fidèlement la dérive de configuration, les paquets orphelins, le service à moitié configuré que quelqu'un a abandonné, et toute persistance laissée par un précédent intrus. Cela vous enferme aussi dans l'ancienne version de la distribution.
Construisez la nouvelle machine à partir d'une image de base à jour, installez les services depuis un script, et ne copiez que les données. Le script est le vrai livrable — c'est lui qui transforme la prochaine migration en une après-midi plutôt qu'en une quinzaine, et qui permet de reconstruire après un incident sans faire d'archéologie.
- Provisionnez, mettez à jour et durcissez avant que quoi que ce soit d'autre n'y touche : SSH par clés uniquement, un pare-feu en refus par défaut, des mises à jour de sécurité automatiques. /guides propose la version d'une heure de cette checklist.
- Installez les mêmes versions majeures du runtime et de la base de données qu'en production. Une migration est un mauvais moment pour aussi faire passer PostgreSQL de 14 à 17 — ne changez qu'une chose à la fois, pour qu'un échec n'ait jamais qu'une seule explication possible.
- Recréez les utilisateurs et les groupes avec les mêmes identifiants numériques avant de copier les fichiers, ou corrigez la propriété à la main ensuite. Transférer avec --numeric-ids garde les numéros intacts ; les faire correspondre aux bons noms, c'est à vous de le faire.
- Ajoutez la nouvelle adresse à chaque liste blanche qui nomme actuellement l'ancienne — API de partenaires, pare-feu de bases de données gérées, passerelles de paiement, votre propre monitoring — pendant que les deux adresses sont encore valides.
Installez les services, puis arrêtez-les et désactivez-les. Un serveur web qui démarre au boot et répond sur la nouvelle adresse sera trouvé par des scanners, indexé sous le mauvais nom d'hôte, et — pire — servira sans problème une copie à moitié remplie de votre site à quiconque la résout trop tôt. Rien sur la nouvelle machine ne doit répondre publiquement tant que vous n'en avez pas décidé autrement.
Copiez les fichiers en deux passages
Un seul transfert d'un système de fichiers actif n'est qu'un instantané d'une cible mouvante. Deux passages résolvent le problème proprement : le premier est long et s'exécute contre un système actif, le second est court et s'exécute pendant le gel, et seul le second doit être rapide.
Lancez le premier passage quand vous voulez — plusieurs jours à l'avance ne pose aucun problème. Il transporte le gros du volume : le répertoire des fichiers envoyés, le spool de mail, les volumes de conteneurs, les années de médias accumulés. Il sera obsolète au moment de la bascule, et c'est exactement à ça que sert le second passage.
- Utilisez rsync -aAXH --numeric-ids --info=progress2 par SSH : -a pour les attributs habituels, -A pour les ACL, -X pour les attributs étendus, -H pour les liens physiques, qui comptent si quoi que ce soit sur la machine déduplique.
- Excluez ce qui ne doit pas voyager : /proc, /sys, /dev, /run, les répertoires temporaires, le cache de paquets et les journaux dont vous n'avez pas besoin. Copier des interfaces noyau fait perdre du temps au mieux, et bloque le transfert au pire.
- Ajoutez --delete uniquement sur le second passage. Sur le premier, c'est inoffensif ; sur le second, ça supprime les fichiers qui ont été supprimés sur la source depuis, ce qui est précisément la dérive que vous essayez d'éliminer.
- Copiez la configuration système de façon sélective plutôt qu'en bloc. Vous voulez vos vhosts de serveur web, vos unités systemd et la configuration de votre application — pas la table des systèmes de fichiers, la configuration réseau ou l'identifiant machine de l'ancienne machine.
- Générez une clé SSH jetable pour le transfert, autorisez-la sur la destination, et supprimez-la une fois la migration terminée. Une clé de migration qui traîne depuis deux ans est un identifiant dont plus personne ne se souvient avoir délivré.
Entre les passages, vérifiez plutôt que de supposer. Lancer le second passage avec --dry-run affiche exactement ce qu'il changerait : une liste de quelques centaines de fichiers récents est saine, et une liste de quarante mille signifie qu'une exclusion est mal réglée ou que quelque chose réécrit des horodatages sans raison.
Déplacez la base de données sans perdre d'écritures
C'est ici que se dépense le budget de gel, et la bonne technique est entièrement déterminée par le chiffre que vous avez noté au départ. Les trois options ci-dessous sont toutes correctes — pour des chiffres différents.
Quel que soit votre choix, l'ancienne base de données doit cesser d'accepter des écritures avant que la nouvelle ne commence à en accepter. Pas juste après — avant. Le chevauchement où les deux sont inscriptibles est la fenêtre de split-brain, et c'est le seul échec de tout ce guide sans récupération propre : deux historiques divergents, et aucun moyen de les fusionner qui ne passe pas par la relecture des lignes à la main.
Exportez le schéma et les données séparément quand le jeu de données est volumineux. Restaurer le schéma en premier permet de vérifier tôt la structure, les index et les permissions sur le nouveau serveur, ce qui transforme le chargement des données en une seule longue opération que vous pouvez démarrer pendant le gel en étant déjà certain qu'elle aboutira.
Émettez le certificat TLS avant la bascule, pas après
Le certificat sur le nouveau serveur doit être valide à l'instant où arrive le premier utilisateur. Découvrir le contraire signifie que chaque visiteur tombe sur un écran d'avertissement du navigateur, et si vous envoyez des en-têtes HSTS — ce que vous devriez faire — ils n'ont aucun moyen de passer outre. Il y a deux façons de disposer d'un certificat fonctionnel avant que le DNS ne pointe où que ce soit de nouveau.
- Copiez celui qui existe déjà. Tout le répertoire d'état ACME, ou juste le certificat et la clé, où que votre client les conserve. Il est valide immédiatement, parce que la validité n'a rien à voir avec le serveur qui détient le fichier, et le renouvellement reprend normalement une fois le DNS déplacé.
- Émettez-en un nouveau avec un challenge DNS-01, qui prouve le contrôle du domaine par un enregistrement TXT plutôt que par une requête HTTP vers l'adresse actuelle. Ça fonctionne avant la migration, avant la bascule, et pour les wildcards, ce que HTTP-01 ne peut absolument pas faire.
- Ne tentez pas de validation HTTP-01 sur le nouveau serveur avant la bascule. Le challenge est récupéré sur le port 80 à l'adresse du nom de domaine, le domaine pointe encore vers l'ancienne machine, et la validation échoue à chaque fois.
Vérifiez-le sans toucher au DNS en résolvant le nom d'hôte vers la nouvelle adresse pour une seule commande : curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — en substituant la vraie adresse. Cette seule ligne est la vérification la plus précieuse de toute la migration. Elle sollicite le vrai vhost, le vrai certificat et la vraie pile applicative sur la nouvelle machine, et c'est comme ça que vous trouvez l'erreur de configuration pendant que la trouver ne coûte encore rien.
Si le serveur envoie du mail, commencez plus tôt
Le mail est la partie d'une migration qui échoue des jours plus tard, silencieusement, et dont on attribue la faute à autre chose. Une nouvelle adresse n'a aucune réputation d'envoi et a pu hériter de celle de quelqu'un d'autre, et chaque enregistrement d'authentification que vous publiez est lié à l'adresse que vous quittez.
- Vérifiez la nouvelle adresse sur les principales listes noires avant de vous y engager. Une IP recyclée avec un passé mérite d'être échangée tant que l'échanger ne coûte encore rien.
- Réglez l'enregistrement DNS inverse de la nouvelle adresse sur le nom d'hôte de votre mail. Les serveurs destinataires vérifient que la résolution directe et inverse concordent, et l'absence d'un PTR suffit à elle seule à être classée comme spam.
- Ajoutez la nouvelle adresse à SPF avant la bascule, et retirez l'ancienne ensuite — les deux listées pendant le chevauchement, pour que le mail s'authentifie depuis le serveur qui l'a réellement envoyé, quel qu'il soit.
- Copiez les clés privées DKIM plutôt que d'en générer de nouvelles, pour que le sélecteur déjà publié dans le DNS continue de valider. Régénérer signifie republier, et republier a son propre délai de propagation.
- Réchauffez progressivement la nouvelle adresse si vous envoyez un tant soit peu de volume. Un serveur qui n'a rien envoyé de toute son existence et qui se met soudain à émettre dix mille messages est, pour un destinataire, indiscernable d'un hôte compromis.
La bascule
Tout ce qui précède n'était que de la préparation, pour que cette partie soit courte, ordonnée et réversible. Faites-la à votre véritable minimum de trafic plutôt qu'à 3h du matin par superstition — vérifiez vos propres statistiques. Ayez le retour en arrière déjà écrit avant de commencer, parce que le moment où vous en aurez besoin est celui où vous aurez le moins envie de le rédiger.
- 1
Gelez les écritures sur l'ancien serveur
Mode maintenance, un utilisateur de base de données en lecture seule, ou une erreur sur les chemins d'écriture au niveau du proxy inverse. Les lectures continuent d'être servies par l'ancienne machine pendant tout ce temps — c'est ce qui garde le site en ligne pendant que les données se déplacent.
- 2
Désactivez tous les timers sur l'ancien serveur
Commentez les crontabs, arrêtez les timers, arrêtez les workers de la file d'attente. À partir de ce moment, l'ancienne machine ne doit plus rien traiter, sinon les tâches s'exécuteront deux fois : deux factures, deux e-mails, deux livraisons de webhook.
- 3
Lancez le delta final
Le second passage de fichiers avec --delete, puis l'export final de la base de données ou le rattrapage de la réplique. C'est le court des deux, quelques minutes tout au plus, parce que le premier passage a déjà déplacé le volume.
- 4
Vérifiez le nouveau serveur sur son vrai nom d'hôte
En utilisant l'astuce --resolve vue plus haut, sollicitez une page qui lit dans la base de données, une connexion, et un chemin d'écriture. Confirmez que le nombre de lignes correspond à la source. Faites tout ça avant que le DNS ne change, pendant que revenir en arrière ne coûte encore absolument rien.
- 5
Basculez le DNS et démarrez les services
Mettez à jour A et AAAA vers la nouvelle adresse, puis activez et démarrez l'application et ses timers sur le nouveau serveur. Le trafic commence à arriver dans un délai d'un TTL, et continue de se déplacer pendant l'heure qui suit.
- 6
Gardez l'ancien serveur au service des lectures
Laissez-le allumé, en lecture seule, pendant au moins vingt-quatre heures. Les clients avec un cache périmé continueront d'y atterrir, et un ancien serveur en lecture seule renvoie des pages légèrement obsolètes plutôt qu'une connexion refusée — la différence entre une migration invisible et une migration visible.
Le chevauchement est aussi le terrain de la technique la plus propre. Plutôt qu'une bascule DNS brutale, reconfigurez l'ancien serveur en proxy inverse vers le nouveau, à la fin de l'étape cinq. Chaque retardataire qui résout encore vers l'ancienne adresse est transféré de façon transparente, la bascule cesse entièrement de dépendre de la propagation DNS, et vous démantelez le proxy dès que le trafic qu'il reçoit tombe à zéro. Transmettez X-Forwarded-For pour que vos journaux et vos limites de débit continuent de voir les vraies adresses des clients.
Les 48 premières heures
La migration n'est pas terminée quand le site se charge. Elle est terminée quand plus rien ne dépend de l'ancienne machine, et trouver ces dépendances est un exercice actif, pas un jeu d'attente.
- Surveillez le journal d'accès de l'ancien serveur. Chaque requête qui y arrive encore est une dépendance non migrée — une adresse codée en dur dans une intégration partenaire, un client mobile avec un cache périmé, une sonde de monitoring dont personne n'a la charge. Le journal est la liste des tâches restantes.
- Confirmez que les timers ont réellement tourné sur le nouveau serveur. Pas qu'ils sont activés — qu'ils ont tourné, à l'heure prévue, avec le résultat attendu. Une tâche cron qui ne fait silencieusement rien ressemble exactement à une tâche cron qui fonctionne.
- Testez réellement le renouvellement du certificat avec un dry-run, plutôt que de découvrir dans soixante jours que votre client ACME a tenté de renouveler contre un serveur qui ne reçoit plus le challenge.
- Vérifiez le flux de mail de bout en bout dans les deux sens, y compris tout ce que l'application envoie automatiquement. Les réinitialisations de mot de passe sont la victime classique, parce que personne ne les teste avant qu'un utilisateur en ait besoin.
- Prenez une sauvegarde du nouveau serveur et restaurez-la quelque part. Une machine neuve sans sauvegarde vérifiée est une position pire que celle que vous avez quittée ; /guides développe cet argument en détail.
- Remettez le TTL DNS à sa valeur normale une fois en confiance. Le laisser à 300 secondes pour toujours est un petit coût permanent en requêtes et en latence, pour plus aucun bénéfice.
Mettre l'ancien serveur hors service
La dernière étape est celle qu'on saute, et c'est la seule qui a une conséquence sur la confidentialité. L'ancien disque contient vos clés, votre base de données, les données de vos clients et vos journaux, et résilier le service n'efface rien de tout ça — ça libère simplement le volume dans un pool où le prochain locataire reçoit tout ce que la politique d'effacement du fournisseur a laissé derrière.
- Attendez que l'ancien journal d'accès se taise avant de toucher à quoi que ce soit. Résilier pendant qu'un fournisseur de paiement envoie encore des webhooks vers l'ancienne adresse, c'est exactement comme ça qu'une migration devient un incident une semaine plus tard.
- Faites tourner plutôt que simplement supprimer : chaque identifiant détenu par l'ancien serveur — clés API, mots de passe de base de données, clés de déploiement, la clé de migration temporaire. Partez du principe que tout ce qui a vécu sur une machine que vous ne contrôlez plus est compromis, parce qu'à terme, ça l'est.
- Écrasez les données avant de libérer le volume. Effacez de façon sécurisée les répertoires sensibles, ou remplissez l'espace libre avec un seul gros fichier aléatoire avant de le supprimer. Imparfait sur un disque virtualisé, et largement mieux que rien.
- Prenez une archive finale de tout ce dont vous pourriez avoir besoin comme référence — journaux, configuration, l'historique du shell qui documente ce qui a réellement été fait — et stockez-la chiffrée quelque part qui n'est ni l'un ni l'autre des deux serveurs.
- Résiliez le service seulement après que le nouveau a survécu à un cycle de facturation complet et à un test complet de sauvegarde et restauration. Ce mois de chevauchement est l'assurance la moins chère de tout le processus.
Un calendrier que vous pouvez copier
Rien ici n'est difficile pris isolément. Si les migrations tournent mal, c'est parce que les étapes se retrouvent compressées en une seule soirée, où le TTL n'a pas expiré, le certificat n'a pas été testé et le retour en arrière n'a pas été écrit. Étalé sur une semaine, chaque jour ne représente que vingt minutes de travail.
Comment les migrations tournent vraiment mal
Pas à cause de la copie. À cause des choses qui n'ont jamais été sur le disque, et des choses qui ont tourné deux fois.
- Les deux serveurs qui écrivent en même temps — la fenêtre de split-brain, et le seul échec ici sans réparation propre. On l'évite par l'ordre des opérations, pas par l'outillage : arrêter l'ancien, puis démarrer le nouveau.
- Des timers qui tournent sur les deux machines, ce qui fait que les clients reçoivent tout en double exemplaire. Désactivez les anciens avant la synchronisation finale, pas après.
- Un TTL qui n'a jamais été baissé, qui transforme une bascule de cinq minutes en une traîne d'une journée entière que personne n'avait prévu de surveiller.
- Une propriété de fichiers qui part de travers parce que les identifiants numériques diffèrent entre les machines, si bien que l'application démarre puis ne peut plus écrire dans son propre répertoire d'upload.
- Un certificat qu'on comptait régler après la bascule, qui se heurte à un en-tête HSTS qui ne laisse aux visiteurs aucun moyen de continuer.
- Une adresse codée en dur quelque part que vous ne contrôlez pas — une intégration partenaire, une règle de pare-feu, un enregistrement DNS pour un sous-domaine dont vous aviez oublié l'existence.
- Résilier l'ancien serveur le jour même du déménagement, ce qui supprime la voie de retour en arrière exactement au moment où les statistiques disent que vous en aurez le plus besoin.
Combien de temps prend une migration de VPS ?
Le travail représente typiquement quelques heures étalées sur une semaine, et la partie visible par l'utilisateur se compte en minutes. Le gros du transfert et la réduction du TTL ont lieu plusieurs jours à l'avance pendant que tout reste en ligne ; la bascule elle-même se résume à une synchronisation delta finale, un changement DNS et une passe de vérification. Un site avec quelques gigaoctets de données et une base de données modeste tient confortablement dans une bascule de trente minutes, avec un gel de moins de dix minutes.
Puis-je migrer sans aucune interruption ?
Oui, pour les lectures — l'ancien serveur continue de répondre jusqu'à ce que le DNS bascule, et le transformer ensuite en proxy inverse élimine même la traîne de propagation. Les écritures sont le cas le plus difficile : un court gel est de loin le moyen le plus simple de garantir qu'aucune n'est perdue, et la réplication réduit ce gel à quelques secondes. Un gel véritablement nul sur les écritures exige que l'application écrive dans les deux bases de données pendant le chevauchement, ce qui est atteignable mais ajoute un mode de défaillance dont la plupart des sites n'ont pas besoin.
Faut-il cloner le disque ou reconstruire le serveur ?
Reconstruire. Un clone transporte la dérive de configuration, les paquets orphelins et toute persistance laissée par une compromission passée, et il vous enferme dans l'ancienne version de la distribution. Installer depuis un script et ne copier que les données vous donne une machine propre plus une recette reproductible — ce qui rend aussi la prochaine reconstruction rapide.
Qu'advient-il de mon adresse IP et de mon classement dans les moteurs de recherche ?
L'adresse change ; le domaine, non, et les liens, le classement et l'historique suivent le domaine. Gardez les URL identiques, gardez l'ancien serveur qui répond pendant le chevauchement pour qu'aucun robot d'indexation ne voie jamais d'erreur de connexion, et le changement devient effectivement invisible pour les moteurs de recherche. Changer de pays peut légèrement déplacer les métriques sensibles à la latence, donc choisissez sur /locations une région proche de votre audience réelle.
Comment migrer une base de données sans perdre de données ?
Arrêtez les écritures sur la source avant de démarrer les écritures sur la destination — cet ordre des opérations est toute la garantie. Pour les petits jeux de données, gelez, exportez avec pg_dump ou mysqldump --single-transaction, restaurez, et basculez. Pour les plus gros, répliquez à l'avance et promouvez la réplique au moment de la bascule pour que le rattrapage ne prenne que quelques secondes. Vérifiez en comparant le nombre de lignes sur les tables qui comptent avant d'envoyer le moindre trafic.
Puis-je déménager vers un hébergeur offshore sans lui donner mon identité ?
Oui. Un hébergeur qui facture depuis un solde crypto n'a ni carte ni adresse de facturation à rattacher à la machine, donc le compte derrière le serveur ne détient rien sur vous. La migration elle-même est techniquement identique — les mêmes passages de fichiers, le même export, la même bascule DNS. /offshore-vps explique comment le modèle fonctionne, et /pay-with couvre le volet paiement.
Quand est-il sûr de résilier l'ancien serveur ?
Une fois que son journal d'accès est resté silencieux pendant au moins une journée, que chaque identifiant qu'il détenait a été renouvelé, et que vous avez pris une sauvegarde du nouveau serveur et l'avez restaurée avec succès quelque part. Un mois supplémentaire d'un petit VPS est l'assurance la moins chère de tout le processus — c'est la différence entre un retour en arrière et un incident.
