Changez d’hébergeur en 7 étapes
Publié le 10 September 2007, par Babozor dans la catégorie Administration serveur, Matériel, OutilsJe suis très content de mon hébergeur (j’y suis depuis maintenant quelques années, je ne me souviens plus, mais 3 ou 4 ans minimum), mais il arrive des fois ou pour nous même ou un client nous devons changer de plateforme d’hébergement. Prix, disponibilité, capacité, bande passante, peu importe les raisons, voici donc comment faire pour changer de plateforme d’hébergement de façon sûre et indolore pour vos utilisateurs/clients.
1. Sauvegarde
Sauvegardez toutes vos données: fichiers, base de données, configuration machine, plugins, etc… Sauvegardez les sur votre disque dur (et éventuellement multipliez les support de sauvegarde, on ne sait jamais)
2. Votre nouveau compte
Ouvrez votre nouveau compte chez votre nouvel hébergeur, généralement l’ouverture de votre compte est quasi immédiat.
3. Transfert de données
Transférez vos données (fichiers, base de données, configuration, etc…) sur votre nouvelle plateforme d’hébergement, installez les applications dont vous avez besoin, etc…
4. Bloquage actions utilisateurs
C’est une étape importante (omise dans l’article de EssentialKeystokes), bloquez les actions utilisateurs, tels que commentaires, édition, etc… toutes les actions ayant une incidence sur la base de donnée ou les fichiers doit être bloqué, pour éviter une divergence importante entre vos deux plateformes d’hébergement qui co-existent. Vous pouvez laisser un message d’alerte à vos clients/utilisateurs (du type “machin déménage, les articles restent lisibles, mais les commentaires sont désactivés, cette situation sera réglée sous 24h, d’avance merci, blablabla…”)
5. Redirection Nom de domaine
Maintenant que vous avez répliqué votre service sur votre nouvel hébergement, il est de rediriger vos noms de domaines sur votre nouvel hébergement. En général c’est une action simple, qui peut être réalisé sur l’interface d’administration de votre registar (en indiquant les nouvelles adresses DNS de votre nouvel hébergeur). La transmission de ces données et la propagation de ces nouvelles adresses DNS prend entre 15 minutes et 24 heures. Durant la période de transition, vos visiteurs seront redirigés soit sur l’ancien ou le nouvel hébergement (peu importe, mais personne ne sera perdu).
A noter, ici on voit le réel intérêt à séparer registar et hébergeur, en cas de changement d’hébergeur, comme ici…
6. Tests
Testez votre nouveau site sur sa nouvelle plateforme (même si les DNS ne sont pas propagés, utilisez alors le sous domaine que votre nouvel hébergeur a du mettre en place pour vous), testez toutes les fonctionnalités pour vous assurer que tout a bien été transféré et installé correctement.
7. Suppression / résiliation
Supprimez tous vos fichiers de votre ancien hébergeur et résiliez votre contrat. Faites bien attention de bien supprimer tous les fichiers, pour vous en assurer faites un tour via FTP (SSH si cette fonctionnalité était présente) et directement via HTTP… pour être sûr qu’aucun de vos fichiers ne trainent sur leur serveur.
Source: Essential Keystokes via LifeHacker (j’ai adapté cet article intéressant mais légèrement incomplet, avec un étape importante manquante: le bloquage des actions utilisateurs)
Changez d’hébergeur est une phase délicate, mais pas très compliquée, un peu de méthode et normalement tout devrait bien se passer. Une des erreurs principales est de ne sauvegarder qu’une partie des données et d’oublier certains éléments (principalement la base de donnée ou les fichiers annexes comme des plugins pour wordpress par exemple). Mais à part cela rien de sorcier.
Et vous c’est quoi votre expérience de changement d’hébergeur?
le 10 September 2007 à 13h04
Hmmm j’aurais placé le point N°4 en top de la liste… Quid des modifications apportées par les utilisateurs entre le moment de la sauvegarde et du transfert vers le nouvel hebergeur.
J’ai déjà vue une propagation de DNS prendre 48 heures… Cette technique fonctionne très bien à condition que notre base ne subisse aucune modification pendant 48 heures. Ce qui n’est pas toujours le cas.
Dans le cas ou la plateforme doit rester en production, j’aurais ajouté ces étapes :
1) Utiliser un nouveau nom de domaine qui pointe vers le nouveau server (éventuellement utilisé des sous-domaines), attendre la propagation et bloquer les requêtes qui modifient les données sur ce nouveau server.
5) faire une redirection (grâce aux deux DNS) des pages de l’ancien server vers le nouveau et débloquer les requêtes du nouveau
6) Rediriger le nom de domaine.
Pour les applications sensible qui ne peuvent être bloquée trop longtemps (ou qui contiennent un grand nombre de données de données : genre 5 heures pour transférer les données)
La sauvegarde et le transfert doivent se faire en continue. Tant que l’ancien server est actif, un script doit dupliquer les données insérées, modifiées ou supprimées vers les nouveaux servers.
On peut éventuellement faire un script du genre (pour chaque table)
- Locker la table
- Bufferiser toutes les nouvelles requêtes sur cette table
- Copier les données de la table vers le nouveau server
- Delocker la table
- Flusher les données bufférisées sur les deux servers en maintenant le buffer sur toutes les requêtes qui concernent cette table
Bien sur, cela risque de causer des problèmes sur les contraintes de clef étrangère pendant l’étape qui consiste a copier les données…
On peut également envisager le transfert en deux temps (a condition que les modifications portent exclusivement sur la base de données) :
1) on déplace uniquement le server apache. L’ancien server et le nouveau pointent toujours sur la même base de données (sur l’ancien server). On attend la propagation des DNS (quelque soit le server du lequel on tombe, on utilisera toujours la même DB)
2) on migre la base (la aussi, ca dépend du besoin de disponibilité de la base) et on fait pointer le nouveau server vers la nouvelle base de données.