Transférer un site entre 2 serveurs release 2 OVH

Bon, je sens que ça va être long, il va falloir s’accrocher. Ca fait un bout de temps que je me suis promis d’écrire ce billet tant la question revient de manière régulière sur les forums OVH (tiens, pas plus tard qu’il n’y a pas longtemps, ici). Fainéant que je suis, j’en ai toujours différé la rédaction vu la grosse tartine que cela représente.

Cette fois, j’y vais.

Introduction

C’est parti pour la question à 1000 balles : comment déménager proprement un site d’un serveur en release 2 OVH vers un autre serveur avec cette même distribution ? Le fait de migrer un site d’un serveur à un autre est souvent vécu comme un cauchemar par les admins débutants. Je m’en vais essayer de les rassurer quelque peu en proposant ci-dessous une procédure en 10 étapes (relativement) simples et, je l’espère, décrites avec précision.

Notez bien que, dans les grandes lignes, ces 10 étapes sont valables pour le déménagement d’un site depuis et vers n’importe quel serveur dédié (pas spécialement en release 2). Seulement les détails que je fournis ci-dessous sont, eux, propre à cette distribution.

Pour la suite de ce billet, je pars du principe que :

  • Les 2 serveurs sont installés en release 2 OVH, sans modification majeure.
  • Les quelques commandes SSH décrites ci-dessous sont à passer en shell et en root.
  • J’appellerai le site à déménager monsite.com. Sur les 2 serveurs, il aura comme utilisateur « monsite » et comme répertoire « /home/monsite ».
  • monsite.com est un site type « PHP + MySQL », du genre Prestashop, WordPress, phpBB, Joomla, etc.
  • J’appellerai ns1111.ovh.net le serveur où se trouve actuellement le site en production, et ns2222.ovh.net le serveur vers lequel on souhaite déménager le site.
  • Chaque serveur a son IP propre, pas d’utilisation d’IP failover (ce qui faciliterait considérablement la tâche … pas la peine de faire simple quand on peut faire compliqué :)).

1. Créer l’hébergement sur ns2222.ovh.net

Commençons par créer sur ns2222.ovh.net un hébergement identique à celui existant sur ns1111.ovh.net. Il faut donc aller créer un hébergement pour monsite.com dans OVHm, c’est à dire par là :

Webmin > ovhm > Ovh Virtual Hosting Management > Ajouter un domaine

Autrement dit, là : https://ns2222.ovh.net:10000/ovhm/formulaire_creer_domaine.cgi

Remplissez le formulaire en veillant à indiquer le même mot de passe que sur ns1111.ovh.net, histoire de créer 2 hébergements vraiment identiques sur les 2 serveurs.

Voilà qui devrait avoir créé tout le nécessaire … sauf les boites mails (et les alias) dont nous nous occuperons plus tard. Pas la peine d’aller se balader dans QmailAdmin (pour ceux qui connaissent), ni de s’amuser à créer manuellement les boites mails.

Sans que ce soit une obligation à ce stade (on y reviendra à la fin), vous pouvez d’ores et déjà rendre dans OVHm sur ns2222.ovh.net (Webmin > ovhm > Ovh Virtual Hosting Management) et de cliquer sur le lien « Redemarrer tous les services (pour prendre en compte les changements) ».

2. « Désactiver » le site sur ns1111.ovh.net

L’idée ici est de mettre le site « en maintenance », ou, à tout le moins, de désactiver tous les aspects interractifs et/ou web 2.0 de monsite.com sur le serveur où il est actuellement en production. La plupart des CMS à l’heure actuelle permettent de désactiver un site si on le souhaite. L’affichage public du site est alors remplacé par un message du genre :

Notre site est temporairement indisponible pour cause de maintenance. Nous vous prions de nous excuser pour la gêne occasionnée et vous demandons de renouveler votre visite ultérieurement.

Cette étape est particulièrement importante si le site enregistre des commandes (boutique en ligne) ou bien si son contenu est fréquemment modifié (blog, forum,…). En effet, le futur déménagement du site supposera de changer les DNS du nom de domaine monsite.com. Cela aura pour effet que, pendant une période pouvant aller jusqu’à 48H après le changement de DNS (cette étape sera décrite plus loin), certains visiteurs pourront encore êtres amenés à visiter le site sur ns1111.ovh.net alors que d’autres voient déjà le site sur ns2222.ovh.net. Cette situation un peu exceptionnelle est liée à la fameuse « propagation des DNS » et peut poser de gros problèmes de pertes de données si le site fonctionne à la fois sur ns1111.ovh.net et sur ns2222.ovh.net. Il est donc prudent de désactiver le site sur ns1111.ovh.net. Il est alors possible que, pendant cette fameuse période, certains visiteurs voient le site « en maintenance » pendant quelques heures … mais c’est un moindre mal.

Notez également que cette étape est bien sûr superflue pour les sites statiques ou donc le contenu n’évolue pas : peu importe que certains visiteurs le visitent sur ns1111.ovh.net ou sur ns2222.ovh.net, ils y verront la même chose.

3. Backup de la base sur ns1111.ovh.net

Sauvegardons à présent la base de données du site sur ns1111.ovh.net. Pour ce faire, allons au plus simple, utilisons Webmin. Rendez-vous ici :

Webmin > Serveurs > Serveur de Bases de Données MySQL > monsite
Autrement dit : https://ns1111.ovh.net:10000/mysql/edit_dbase.cgi?db=monsite

Cliquez ensuite sur le bouton « Backup Database ». Dans le formulaire qui suit, il suffit de choisir un emplacement pour votre backup. Le nom du fichier est arbitraire, mais je vous conseille de placer votre backup à la racine de l’hébergement du site, soit pour moi : /home/monsite/backupmonsite.sql

Voilà qui va créer un « dump » de votre base de données que nous pourrons importer le moment venu sur ns2222.ovh.net.

4. Copier le site d’un serveur à l’autre

C’est la partie qui parait la plus complexe … en fait il n’en est rien. Nous allons nous connecter par SSH sur ns1111.ovh.net et taper la simple commande suivante :

scp -rp /home/monsite/ root@ns2222.ovh.net:/home/

Cette commande aura pour effet de copier le répertoire /home/monsite/ d’un serveur à l’autre (le mot de passe root de ns2222.ovh.net vous sera demandé au passage). Si vous vous êtes bien débrouillés, le dump de la base MySQL (qui devrait donc se trouver dans /home/monsite/ si vous avez suivi les recommandations du point 3) devrait faire partie du voyage.

5. Copier les boites mails d’un serveur à l’autre

Sur mon serveur en release 2, les boites mails de monsite.com se trouvent dans /home/vpopmail/domains/monsite.com. Je m’en vais donc repasser un coup de « scp » pour les copier d’un serveur à l’autre. Rendez-vous en SSH, toujours sur ns1111.ovh.net et tapez :

scp -rp /home/vpopmail/domains/monsite.com/ root@ns2222.ovh.net:/home/vpopmail/domains/

Notez que le pass root de ns2222.ovh.net vous est une nouvelle fois demandé.

Et hop, voilà toutes mes boites et tous mes alias transférés d’un coup. Elle est pas belle la vie ? 😉

6. Rétablir les bons propriétaires des fichiers

Cette étape est primordiale, ne la zappez pas !

Les deux copies un peu sauvages auxquelles nous venons de nous livrer ont quelque peu chamboulé les propriétaires des fichiers et dossiers sur ns2222.ovh.net. Il est indispensable de rectifier le tir, sans quoi ni le site, ni les boites mails ne fonctionneront correctement sur le nouveau serveur.

Faisons cela avec la commande « chown », rendez-vous en SSH sur ns2222.ovh.net et tapez :

chown -R monsite:users /home/monsite
chown -R vpopmail:vchkpw /home/vpopmail/domains/monsite.com

7. Restaurer la base de données sur ns2222.ovh.net

Il est à présent temps d’importer la base de données sur ns2222.ovh.net. Pour ce faire, comme lors de la création du dump, nous utilisons Webmin … et exactement au même endroit :

Webmin > Serveurs > Serveur de Bases de Données MySQL > monsite
Autrement dit : https://ns2222.ovh.net:10000/mysql/edit_dbase.cgi?db=monsite

Cette fois, cliquez sur le bouton « Execute SQL » puis sur l’onglet « Run SQL from file ». Utilisez alors le petit formulaire pour sélectionner votre fichier « dump » (je ne vais pas vous faire l’insulte de vous rappeler encore une fois où il se trouve) et validez.

Lorsque la page se rafraichit (ça peut durer un moment, surtout si vous avez une grosse base de données), le message de confirmation n’est pas très bavard, c’est normal. Si vous souhaitez vous assurer que votre base a correctement été importée, le mieux est d’aller jeter un coup d’oeil dans PhpMyAdmin :

https://ns2222.ovh.net/phpMyAdmin/

8. « Activer » le site sur ns2222.ovh.net

Il s’agit de l’inverse du point 2 : sortir le site de son mode « maintenance », cette fois sur ns2222.ovh.net.

Il est possible que ce point pose problème car, à ce stade, on n’a toujours pas changé des DNS du nom de domaine. Donc, lorsqu’on visite monsite.com le plus naturellement du monde, on tombe encore évidemment sur ns1111.ovh.net ! Or c’est bien sur ns2222.ovh.net qu’il convient de réactiver le site…

Pour contourner l’obstacle, la release 2 vous offre la possibilité de visiter votre site sur une adresse temporaire :

http://ns2222.ovh.net/~monsite/

Si cela ne suffit pas (problème de .htaccess par exemple), vous pouvez feinter en modifiant le fichier « host » sur votre PC et en forcant le nom de domaine monsite.com vers l’adresse IP de ns2222.ovh.net (je ne développe pas plus que ça, vous trouverez pleins d’infos sur Google à ce sujet).

9. Changer les DNS du nom de domaine

On y est presque, il ne reste plus qu’à changer les DNS de monsite.com … mais avant cela, il convient de gérer correctement le DNS secondaire. Comme vous le savez, un nom de domaine se doit d’avoir 2 serveurs DNS, le primaire et le secondaire. Le DNS primaire d’un nom de domaine hébergé sur un serveur en release 2 est en principe le nom du serveur lui-même. Donc, à ce stade, le DNS primaire de monsite.com est ns1111.ovh.net.

Comme il est obligatoire qu’un nom de domaine ait (au moins) 2 DNS, OVH met à notre disposition un serveur DNS secondaire. A l’heure où j’écris ces lignes, le DNS secondaire pour les serveurs OVH est sdns2.ovh.net (ns.kimsufi.com pour les serveurs Kimsufi).

En l’état actuel des choses les DNS de monsite.com sont donc :

ns1111.ovh.net
sdns2.ovh.net

Il va donc falloir changer cela par :

ns2222.ovh.net
sdns2.ovh.net

Si votre nom de domaine est enregistré chez OVH, vous pouvez faire cette opération dans votre manager OVH (https://www.ovh.com/managerv3) :

monsite.com > Domaine & DNS > Serveurs DNS

Si votre domaine n’est pas enregistré chez OVH, ma foi, vous trouverez certainement l’option dans le panel d’administration de votre registar.

OUI MAIS…

Si on se contente de ne faire que ça, notre ami le DNS secondaire (sdns2.ovh.net donc) ne sera pas au courant du changement et il continuera de fonctionner comme avant, c’est à dire d’envoyer le trafic (et les mails) de monsite.com vers ns1111.ovh.net !

Pour corriger cela, rendez vous dans votre manager OVH :

ns1111.ovh.net > Services > DNS secondaire

Puis supprimez le nom de domaine du DSN secondaire.

Restez alors dans votre manager OVH :

ns2222.ovh.net > Services > DNS secondaire

Et cette fois inscrivez le nom de domaine sur le DNS secondaire.

Voilà qui aura pour effet que le DNS secondaire cesse de communiquer avec ns1111.ovh.net et se mette à parler avec ns2222.ovh.net.

IMPORTANT

On approche de la fin, mais n’oubliez pas à l’issue de tout cela, de vous rendre dans OVHm sur ns2222.ovh.net (Webmin > ovhm > Ovh Virtual Hosting Management) et de cliquer sur le lien « Redemarrer tous les services (pour prendre en compte les changements) ». Faites le, même si vous l’avez déjà fait à le fin de l’étape 1.

10. Vérifier les mails pendant 48H

Et bien voilà, figurez-vous que la migration est terminée : votre site a bel et bien été déplacé d’un serveur à l’autre. Mais si, mais si ! Il est possible que cela ne saute pas aux yeux tout de suite car, victime que vous êtes de la propagation des DNS, vous continuez de voir votre site « en maintenance » car vous êtes encore dirigé vers ns1111.ovh.net. De fait, c’est à présent que commence cette période bizarre au cours de laquelle le trafic vers votre site bascule progressivement vers le nouveau serveur. Il n’y a pas grand chose à faire de votre côté, sinon peut-être tenter un ipconfig /flushdns (si vous êtes sous Windows, voir Google pour savoir ce que c’est) ou bien, comme cela a déjà été évoqué plus haut, forcer votre fichier « host ».

Il reste cependant un point quelque peu gênant auquel il faut faire attention. Pendant la propagation des DNS, au même titre que certains visiteurs arriveront encore sur ns1111.ovh.net jusqu’à 48H après le changement des DNS, certains mails eux aussi arriveront peut-être encore sur l’ancien serveur ! Si les boites mails ont une certaine importance à vos yeux et que vos utilisateurs ne peuvent en aucun cas louper de mail, il va falloir veiller au grain ! Donc, pendant les 48H qui suivent le changement des DNS, il va falloir jeter un coup d’oeil régulièrement pour voir si de nouveaux mails ne seraient pas arrivés sur ns1111.ovh.net. Le cas échéant, il est évidemment nécessaire de les copier sur ns2222.ovh.net (reportez vous aux points 5 et 6).

Pinaise, il m’a pris l’après-midi ce billet … mais ouf, ayééé 🙂

53 réponses sur “Transférer un site entre 2 serveurs release 2 OVH”

  1. J’ai été confronté au même cas et j’avais contourné le souci du temps de la propagation DNS via un iptables qui redirigeait depuis le serveur 1 vers le serveur 2. Ce qui a conduit à zéro interruption

  2. Merci d’être passé par ici 🙂

    Tu as raison, j’aurais pu parler d’iptables. D’ailleurs, malgré la taille du pavé ci-dessus, j’ai fait l’impasse sur une série de choses intéressantes. Notamment (mais pas que) mod_proxy ou encore la réduction du TTL de la zone Bind de monsite.com. J’avoue que j’ai eu la flemme … et puis (pour me donner bonne conscience), il faut dire aussi que cela aurait rajouté une couche de complexité à un tuto qui se veut accessible à tous, surtout aux débutants.

    Cela dit, pour revenir à iptables, est-il possible de rediriger tout le trafic d’un seul et unique domaine ? Parce que bon, en imaginant que monsite.com ne soit pas le seul site hébergé sur ns1111.ovh.net, on ne peut évidemment pas envisager de redirection iptables basée sur les ports, sans quoi les autres sites se retrouveraient inaccessibles. Je vais aller fureter, si je trouve un truc, je poste ici.

  3. super tutoriel, merci !

    J’ai un serveur dédié OVH en release 2 et j’avoue que parfois je galère un peu pour la gestion car je n’y connais rien. Alors je me dépatouille avec les conseils trouvés à droite ou à gauche… est-ce que par hasard vous feriez de l’infogérance sous la release 2 d’OVh ?

  4. Ravi qu’il vous convienne 🙂

    Et oui, je peux me charger de quelques tâches d’infogérance sur un serveur en release 2 OVH. Après, tout dépend de ce que vous souhaitez : je ne prétends pas être un cador de Gentoo mais j’ai tout de même quelques kilomètres au compteur avec cette distribution.

  5. Bonjour,

    Dans l’étape 10 vous conseillez de bien surveiller les mails.
    Dans le cas où de nouveaux mails arrivent sur un serveur ou sur l’autre, ou bien que on en envoi, l’étape 5 n’écrasera-t-elle pas les nouveaux mails reçus/envoyés sur ns22222 par les nouveaux reçus/envoyés sur ns11111?

    Dans ce cas, comment pourraient-on fusionner les deux sur ns22222?

  6. Bonjour,

    Aucune inquiétude à avoir à ce niveau : le format « Maildir » (utilisé sur la release 2) veut que chaque mail soit représenté par un fichier et que le nom de ce fichier est généré de manière à être unique. Il n’y a donc aucun risque d’écrasement.

    A vrai dire le seul risque, c’est que certains utilisateurs reçoivent des mails en double exemplaire. Par exemple un utilisateur se connectant sur ns2222 et ayant déjà vidé sa boite. Si on lui (re)copie ses mails en provenance de ns1111, il recevra donc un exemplaire supplémentaire de certains mails qu’il a déjà consultés. Pour éviter cela, il est possible de copier de manière un peu plus fine en copiant mails par mail (fichier par fichier) et/ou en se concentrant sur les mails se trouvant de la répertoire « new » (qui, par définition, n’ont pas encore été consultés).

  7. Bonjour,

    Sympa ce tuto je voulais rajouter une petite astuce pour accelerer le transfert des dns :il suffit dans votre cas de forcer l’ip dans le domaine sur l’ancien serveur donc :
    Vous pouvez même incrémenter 2009101102 + 1
    Mais attention à ce que le numéro sur le nouveau serveur soit bien supérieur !!

    $ttl XXXXXXX
    $ttl 86400
    domaineatranferer.com. IN SOA domaineatranferer.com. postmaster.domaineatranferer.com. (
    2009101102
    21600
    3600
    604800
    86400 )
    IN NS nsXXXXX.ovh.net.
    IN NS sdns1.ovh.net.
    IN MX 10 mail.domaineatranferer.com.
    IN A IP.du.nouveau.serveur
    www IN A IP.du.nouveau.serveur
    mail IN A IP.du.nouveau.serveur
    smtp IN A IP.du.nouveau.serveur
    pop IN A IP.du.nouveau.serveur
    pop3 IN A IP.du.nouveau.serveur
    imap IN A IP.du.nouveau.serveur
    sql IN A IP.du.nouveau.serveur
    mysql IN A IP.du.nouveau.serveur

    Après on peut faire une redirection brut du trafic sur la carte mais c’est un peu plus tendu …

  8. Bonjour,

    Super, merci d’avoir pris le temps d’avoir créé ce tutorial étape par étape.
    Un petit souci, à l’étape 6, j’ai pourtant bien vérifié la syntaxe, j’ai un message d’erreur :
    sur la ligne
    « chown -R monsite:users /home/monsite »
    J’ai l’erreur :
    chown `monsite.com:users’: usager invalide.

    Pouvez-vous m’aider svp ?

    Merci.

  9. Dans la commande « chown -R monsite:users /home/monsite », « monsite » correspond à l’utilisateur système qui a été créé pour ce site. Dans le cadre de la release OVH (à moins que vous n’ayez forcé les choses d’une manière ou d’une autre), il est très improbable que le nom de cet utilisateur termine par « .com ».

    Reportez vous au module OVHm de Webmin pour savoir quel user a été créé : Webmin > OVHm > Liste des domaines gérés par OVHM, puis voyez la colonne « login »

  10. Bonjour Nico,

    Merci beaucoup pour votre réponse rapide. Mon transfert n’est pas fini, mais voici quand même où j’en suis.
    En transférant les fichiers, on ne retrouve pas sous OVHM le site tel qu’on l’avait créé. J’ai d’abord créé le site sous OVHM sur le serveur 2, à l’identique du serveur 1, avec les mêmes mots de passe pour les bases, puis transférer le site…
    La manière de faire n’est-elle pas déjà de recréer les sites et bases sous OVHM avant de les transférer ?

    Merci.

  11. Bonjour Nico,

    Merci pour votre tutorial très efficace. Pourriez-vous me donner des indications pour faire un virtualhost (ou autre), l’idée étant de transférer tout le trafic vers le serveur dès que celui-ci est prêt, sans attendre la propagation DNS. La doc trouvée sur internet n’est pas simple quand on s’y connait peu…

    Merci.

  12. Comme dit quelque part dans les commentaires ci-dessus, il est effectivement possible de rediriger le trafic web … mais cela dépasse le cadre de ce tuto qui se veut accessible à tous.

    Si le coeur vous en dit et que vous souhaitez pousser plus loin les recherches, voyez du côté de mod_proxy (« mod_proxy » dans Google vous amènera tout droit sur la doc). Attention, gardez également à l’esprit que cela ne redirige que le trafic web. Cela ne touche donc pas les mails qui, eux, seront toujours soumis à la propagation des DNS.

  13. Bonjour,

    Merci infiniment, je suis votre tutorial pas à pas pour transférer mes sites OVH.

    Il y a un problème, qui n’est pas de votre fait, mais côté OVH. Je ne suis pas spécialiste, mais il me semble que la manip est bonne.
    Je m’en suis aperçu en tentant de faire un Zonecheck sur mes domaines (http://www.zonecheck.fr/demo), j’avais plein d’erreurs…
    J’ai réalisé que, à ce jour, si vous transférez des domaines qui ont un DNS secondaires sdns1.ovh.net vers sdns2.ovh.net, le changement n’est PAS effectué automatiquement dans OVHM…
    J’ai été obligé de faire manuellement la correction : sur les deux serveurs :
    OVHM > Serveurs > Serveur de noms de domaines BIND > (nomdudomaine.com) > Tous les types d’enregistrements (xx)
    Vérifiez que vous trouvez bien sdns2.ovh.net et non pas sdns1.ovh.net

    Qu’en pensez-vous ?

    Merci.

  14. Effectivement, dans la mesure où OVH change régulièrement de DNS secondaire, cela fait partie des difficultés que l’on peut théoriquement rencontrer sur la release. Si le serveur est à jour (et donc module OVHm également, la dernière version à l’heure actuelle étant la 0.6.6), la zone Bind qui sera créée à la création d’un hébergement contiendra les champs NS suivants : ns2222.ovh.net (votre serveur) et sdns2.ovh.net (l’actuel DNS secondaire mis à disposition par OVH).

    Seulement le problème doit bel et bien rester « théorique » dans la mesure où, si vous transférez un site d’un serveur à un autre, il vous faudra nécessairement supprimer et réinscrire le nom de domaine sur le DNS secondaire d’OVH. C’est l’objet de mon « OUI MAIS… » dans le point 9 du tuto. Concrètement, cela aura donc pour effet de supprimer le nom de domaine de sdns1.ovh.net et de le recréer sur sdns2.ovh.net.

    En clair, si vous transférez un site d’un serveur à l’autre, il n’est pas possible de conserver sdns1.ovh.net en tant que DNS secondaire pour le nom de domaine déménagé.

  15. Bonjour,

    Merci pour ces lignes de commandes, j’ai pu faire les transferts d’un ancien serveur via le nouveau répertoire par répertoire, pour chaque domaine qui se devait d’être concerné.
    Pour les DNS, pas eu besoin, étant donné que les domaines sont sur des IP FailOver, ainsi, je n’ai eu qu’à faire la bascule des IP concernées d’un serveur vers l’autre.

    Moi, qui suis assez allergique à la ligne de commande, j’avoue que ce fut bien simple et sans erreur.

  16. J’en profite pour ceux qui ne le savent pas, l’avantage des IP FailOver est de ne plus s’embêter avec le changement de DNS, quelque soit le domaine. Ainsi, quand vous changer de serveur, il suffit de faire la bascule d’un serveur vers un autre dans l’interface du Manager. A condition, que les deux serveurs soient chez OVH.

    Ainis, le domaine n’est pas derrière l’IP et le DNS du serveur dédié, mais derrières ceux de l’IP FailOver. Une fois que les données d’un domaine ont été transférées (FTP & alias) vers le nouveau serveur, hop, bascule de l’IP, un email de confirmation d’OVH, et les données rattachées au domaine sont instantanément accessibles, sans devoir attendre la propagation des DNS.

  17. Merci beaucoup pour ce tuto ! Sans lui je ne m’en serais probablement pas sorti seul, et j’aurais dépensé les 240 euros d’infogérance proposés par OVH pour la migration! (3 heures de boulot…)

  18. Bonjour,

    Je reviens de nouveau vers vous suite à une nouvelle migration.
    Dans mon cas, mais je pense bien que c’est généralisé, les VPS ne sont pas gérés par le manager v3.
    Dans ce cas le DNS secondaire se configure à l’aide du manager v5.
    La configuration du DNS secondaire se trouve dans « Plus d’action » => « Paramètres avancés » dans la barre d’outils.

  19. Bonjour,
    Tout d’abord, merci beaucoup pour ce tuto, j’ai noté pas mal de chose dans mes archives … 🙂
    Une petite question tout de même …
    A l’étape 4, j’ai environ 6 Go de photos à importer, vaut il mieux tout compresser en une seule archive en .tgz (et ensuite décompresser sur le nouveau serveur)ou alors tout envoyer comme ça l’est pour le moment donc dans un simple dossier ?
    Encore merci beaucoup pour toutes ces explications ! 😉

  20. Pas la peine : 6 Go de données, cela se transfère en 10 minutes de serveur à serveur 😉
    (et puis de toute façon, les photos ça se comprime assez mal, le gain de place/temps est donc assez marginal)

  21. Ok, super ! Merci beaucoup pour ta réponse rapide ! 🙂
    Et bonne continuation à toi, et n’hésite pas à nous faire ce genre de tuto qui sert à pas mal de monde je crois … 😉

  22. Merci pour ce très bon tuto.
    J’ai une question complémentaire.
    Je souhaite installer une copie d’un site (actuellement chez un autre hébergeur) sur le nouveau serveur Gentoo ovh. Mais j’ai des modifications à faire dessus avant de faire pointer le domaine vers le nouveau serveur. Si je créé l’hébergement sur ns2222.ovh.net avec le nom de domaine http://www.monsite.com (étape 1) est-ce que cela va faire un conflit avec le site actuel que je veux laisser un moment encore en production ?
    Merci d’avance

  23. Aucun conflit possible tant que les DNS du nom de domaine n’auront pas été modifiés. Ce serait un peu simple vous ne croyez pas ? Il suffirait que n’importe qui disposant d’un serveur dédié crée un hébergement sur son propre serveur pour votre nom de domaine à vous, et cela suffirait à vous pourrir la vie 😉

  24. Bonjour Nico
    Je te remercie de ta réponse, c’est logique en effet.
    J’avoue avoir encore certains doutes sur les questions de DNS, etc
    Le nom de domaine est géré par les serveurs de l’hébergeur actuel. Est-il obligatoire de modifier cela et d’utiliser les serveurs NS d’ovh ou il suffirait de modifier les valeurs sur les serveurs actuels ?

  25. J’en suis désolé, mais il est malheureusement difficile de répondre à la question car elle est assez confuse.

    Une chose est sûre : comme le site est destiné à changer de serveur (et donc d’IP), il va falloir changer les DNS du nom de domaine ou, à tout le moins, modifier la zone DNS du nom de domaine (si le prestataire le permet) pour faire pointer les différents enregistrements (A, MX, CNAME, etc.) vers la nouvelle IP.

  26. Bonjour,

    Pour ce qui est des mails après avoir testé dans des conditions difficiles je préconiserais quelques modifications.

    Plutôt utiliser rsync dans mes mêmes conditions :

    1) Copie des infos en temporaire
    rsync -alHvzcpog -e ‘ssh’ /home/vpopmail/domains/ledomaine.fr/ root@ns99999.ovh.net:/tmp/ledomaine/

    2) Une fois copiées
    Arret de qmail sur la source
    resynchro pour avoir les dernier mails reçus sur la source.

    Arret de qmail sur la destination
    copy (-rp) vers /home/vpopmail

    3) redémarrage des services qmail

    Mon pb était que la copie était très longue et pour éviter les pbs j’ai su arreter les 2 serveur qmail pendant 2h…

    Cordialement,

  27. Merci à vous de votre intervention et de ces informations supplémentaires. Juste 2 petites réflexions qui me passent par la tête :

    1) « rsync -alHvzcpog » équivaut à « rsync -aHvzc » (pas la peine de faire compliqué quand on peut faire simple ;))
    -H préserve les liens symboliques, à mon avis pas utile dans le cas présent.
    -v ajoute de la verbosité, OK pourquoi pas.
    -z ajoute de la compression pendant le transfert. Ce processus de compression/décompression prend du temps et des ressources. Cela se justifie si la bande passante entre les 2 serveurs est faible, ce qui n’est pas le cas entre 2 serveurs OVH. Pas sûr que, au final, vous sortiez gagnant de la bagarre … à tester.
    -c rajoutera encore du temps de calcul … sans réelle utilité à mon humble avis.

    2) Je n’ai pas bien saisi quels problèmes vous avez rencontrés suite à votre très longue copie, mais il ne faut effectivement pas exclure l’éventualité qu’il faille couper les serveurs Qmail. Auquel cas, il me semble qu’il eût été plus simple de (1) Arrêter Qmail sur les 2 serveurs, (2) rsync simple, sans passer par un répertoire temporaire et (3) redémarrage de Qmail sur les 2 serveurs.

  28. Bonjour,
    Tout d’abord, merci beaucoup pour ce tuto 🙂
    Je souhaite installer une copie mon site actuellement chez ovh (Gentoo release 2) sur le nouveau serveur ovh (Gentoo release 2 aussi).
    Mais j’ai des modifications à faire dessus avant de faire pointer le domaine vers le nouveau serveur.
    je vais zappé étape 2. « Désactiver » le site sur ns1111.ovh.net car je vais utiliser IpFailover pour basculer vers le deuxième serveur en cas de besoin
    c’est possible de faire le copie sans problème
    des recommandations ça sera super
    Merci d’avance

  29. Je ne suis pas certain d’avoir bien compris la question, mais il me semble que la réponse est oui : il n’est pas absolument obligatoire de passer par l’étape « désactiver le site » pour en faire la copie. C’est juste une précaution pour éviter que, pendant la période de propagation des DNS, le contenu du site ne soit modifié par des visiteurs arrivant encore sur ns1111.ovh.net.

    D’autre part, il est vrai que cette étape peut être éventuellement sautée si vous utilisez une IP failover car cette dernière rend la bascule d’un serveur à l’autre presque instantanée. Après, cela dépend du trafic du site : s’il s’agit d’un site à fort trafic, il est possible que son contenu soit modifié entre le moment où vous copiez le site (+ les modifications que vous souhaitez apporter) et le moment où la bascule de l’IP est terminée…

  30. Bonjour Nico,

    Merci beaucoup pour votre réponse rapide.
    Je m’explique en faite l’objectif du deuxième serveur ns2222.ovh.net c’est pour backup et serveur de secours si ns1111.ovh.net down le basculement à l’aide du ipfailover
    1-j’ai pensé suivre ton tuto pour fair la premiere copie du ns1111.ovh.net vers ns2222.ovh.net en gardant le premier serveur ns1111.ovh.net en production
    2-je souhaite faire une sauvegarde quotidienne et incrémentale sur ns2222.ovh.net avec rsync (bien sur à l’aide de ton super tuto « Sauvegarder les données de son serveur avec rsync » )
    => alors mes question:
    1- sur le deuxième serveur ns2222.ovh.net création l’hébergement est inutile? puisque je vais utiliser IpFailover et bien sur sans la désactivation du ns2222.ovh.net
    2-mon raisonnement est juste? cad je fait la la première copie à l’aide du ce tuto et puis je procédé à la mise en place du Sauvegarde les données de son serveur avec rsync en suivant votre deuxième tuto « Sauvegarder les données de son serveur avec rsync »
    des recommandations ça sera super 😉
    merci d’avance

  31. Stop ! Vous êtes en train de confondre transfert des données, backup et haute disponibilité. Le fait que vous souhaitez pouvoir basculer l’IP d’un serveur à l’autre en cas de panne donne a penser que vous vous orientez vers une architecture HA.

    Le but de ce billet est d’expliquer les différentes étapes de la migration d’un site d’un serveur à un autre. Le but de l’autre billet « Sauvegarder les données de son serveur avec rsync » est de mettre en place un backup des données. Aucun des deux n’a pour but d’expliquer la mise en place d’une architecture HA et ils ne sont pas adaptés à cet usage.

    Notez également qu’une architecture haute disponibilité n’a de sens que si (1) les données sont synchronisées en permanence entre les 2 serveurs (pas juste une fois par jour) et (2) la bascule de l’IP failover se fait de manière automatique. Ce genre de chose n’est pas forcément « facile » à mettre en place, ni à maintenir par la suite. Il faut donc vraiment que le jeu en vaille la chandelle … c’est à dire concrètement que le(s) site(s) ne peuvent en aucun cas connaitre d’interruption de service. Les pannes serveurs étant finalement assez rares, un bon backup (permettant de récupérer rapidement les données en cas de panne) suffit largement dans bien des cas.

  32. Merci beaucoup pour votre réponse rapide NICO
    alors là je suis un peut perdu 🙁
    j’ai cru que j’ai trouvé le bon chemin !!
    si je comprends bien je reserve un backup à jours et en cas de panne je fais bascule Ipfailover manuelle afin d’éviter la mis en place d’une architecture HA
    Encore merci beaucoup pour toutes ces explications
    cordialement

  33. OK, alors en résumé : oubliez l’idée d’une bascule d’IP. Mettez plutôt en place un bon backup qui vous permettra de remonter rapidement votre serveur (et vos données), même en cas de défaillance complète.

  34. Génial, merci pour ce tuto. Dire qu’avant je passer une semaine pour uploader mes fichiers (j’ai prés de 20 go à transférer en 512mb/s) et la j’ai tout fait en 10 min !!!

  35. Concernant la bascule des mails.

    Le plus simple : création des mails sur le ks2, positionnement en mx backup (mx100) (mx10 pour le ks1) sur les DNS . Tant que le ks1 fonctionne : le ks2 ne reçoit pas de mail.

    Attendre 2 jousr de propagation DNS (être sur que le ks2 est connu comme mx pour le domaine).

    Transfert des mails du ks1 vers le ks2 : coupure du service mail sur le ks1. Le service mail étant coupé sur le ks1, les mails sont automatiquement envoyé sur le mx 100 (soit ks2).

    Pas de perte d’email.

    Denis

  36. Utile si on souhaite mettre en place une bascule instantanée du service mail, merci de votre intervention 🙂
    (à toutes fins utiles précisons que, dans l’intervention ci-dessus, ks1 = ns1111.ovh.net et ks2 = ns2222.ovh.net)

  37. Bonjour,

    Premièrement, bon article, il m’a permis de me lancer dans le transfert de mon site.. par contre j’ai un petit soucis.. je m’explique..
    Mon serveur1 est en rescue, donc j’ai fais certaines opérations « a la main » .. plutôt qu’en ligne de commande..

    1/ J’ai pris un nouveau serveur
    2/ J’ai créer monsite1.com via Webmin
    3/ J’ai transféré mes fichiers sur le ftp (via ftp) et ma base de données (via le gestionnaire de fichier de webmin).. ok soucis, mon site marche bien.. (enfin, 1 site sur 3 mais j’suppose que c’est dû à la propagation des dns, vu que j’ai fais pareil pour tous..)
    4/ j’ai voulu remettre mes mails d’aplombs et c’est là que ça merdouille..
    J’ai transféré via le gestionnaire de fichier de webmin, ce que j’avais dans /home/vpopmail/domains/monsite1.com/
    Via outloook, j’ai bien les mails, sauf que je ne reçois pas les nouveaux :/
    Via Qmail, je peux gérer le compte.. ça c’est bon.. par contre je ne peux pas le faire pour monsite2.com.. .est ce que c’est dû au fait que la propagation de DNS ne soit pas encore faite pour ce site ? car j’ai fais la même manip et dans Qmail, lorsque j’essaie de gérer le compte de monsite2.com, je me retrouve avec « Login inexistant » :/
    Via SqWebMail, je peux consulter mon compte mail mais pareil, pas de trace des nouveaux messages.. comment ça se fait ?
    Idem, ils ne sont pas sur le serveur1 (qui lui est en rescue)..

    Il y a-t-il une manip particulière pour ré-activer la réception de mail ?
    là je désespère un peu :/

  38. En principe, il suffit de reconstruire correctement le répertoire /home/vpopmail/domains/domaine.com et cela suffit. Attention que cela suppose (1) de copier tous les fichiers/dossiers de ce répertoire depuis le serveur en rescue et (2) de remettre les bons propriétaires/permissions sur les fichiers et dossiers. Pour ce qui est des permissions, il vous suffit de créer un domaine fictif sur le (nouveu) serveur et vous aurez alors un exemplaire « propre » de ce genre de répertoire. Pour ce qui est des propriétaires, la ligne « chown -R vpopmail:vchkpw /home/vpopmail/domains/monsite.com » du tuto devrait suffire.

    Si cela ne fonctionne toujours pas, vous êtes peut-être (encore) victime de la propagation des DNS.

    Si cela ne fonctionne toujours pas au bout de deux jours … alors il va falloir faire des fouilles un peu plus approfondies, notamment dans les logs de votre serveur pour savoir ce qu’il advient des mails qui lui sont envoyés.

  39. Merci de votre réponse, ce qui me dérange c’est la phrase : « vous êtes peut-être (encore) victime de la propagation des DNS » .. Comment en être sur ?
    La propagation de DNS est-elle différente pour les mails et le site ?
    Car le site, pointe bien sur le nouveau serveur.

    J’avais déjà bien recréer le domaine fictif sur le nouveau serveur pour avoir un exemple propre, puis j’avais lancé la ligne de commande pour remettre le bon propriétaire, ça n’a rien changé :/

    En lisant tout et n’importe quoi cette après-midi, j’ai cru entendre parler de MX ? qu’est ce que c’est ? dois-je toucher a quelques choses avec ça ?

    Merci de votre aide au passage 🙂

  40. Désolé, mais je ne vais pas pouvoir continuer de vous aider beaucoup plus loin. D’une part parce que cela commence à virer à l’aide personnalisée (et que ce n’est pas le but de ce billet ni de ses commentaires). D’autre part parce qu’en l’absence de données concrètes et précises sur les domaines concernés, leurs configurations DNS et les logs du serveur, on reste dans le spéculatif et il est bien difficile de vous apporter une aide pertinente par rapport à votre problème précis.
    Bonne continuation néanmoins !

  41. Super tutoriel.
    Dans mes favoris et déjà utilisé 6 fois en 2 ans.
    Tout marche du premier coup, simple et très efficace. Personnellement, je ne change que le champs A plutôt que les dns pour n’avoir aucune propagation.
    En 10 minutes montre en main, le site est déplacé sur un autre serveur et sans mauvaises surprises
    Un grand bravo et un grand merci.

  42. Merci de faire partie des fidèles 🙂

    Cela dit, le fait de ne changer que le champ A dans la zone DNS ne vous épargne en principe pas la période de propagation des DNS.

  43. J’avais une idée vague de ce que pouvait représenter une migration. Cette idée vague est devenu un problème vu que l’on va migrer de serveur et qu’OVH ne propose plus la migration, même si l’on est près à payer.
    Donc, et c’est là où je voulais en venir, ce post m’a rendu mon moral perdu !!
    Une question cependant : on va passer sur une release 3 OVH. Ce tuto est-il toujours d’actualité dans ce cas ?
    Merci encore.

  44. Oui … et non.

    Oui car il reste valable dans ses grandes lignes. La feuille de route que représente les 10 étapes décrites dans ce billet vaut d’ailleurs pour tout transfert de site, qu’importe les distributions ou les panels installés sur les serveurs.

    Et non car le fonctionnement de la Release 3 est un peu différent de celui de la Release 2. C’est particulièrement vrai concernant les boites mail. Autant le transfert des sites et des bases de données ne devraient pas poser de problème en vous conformant strictement au tuto (notez tout de même que je n’ai pas testé). Autant le transfert des boites mails ne fonctionnera pas sur base des commandes ci-dessus. Il y a plusieurs raisons à cela. D’abord parce que les boites mails ne se trouvent pas au même endroit sur la release 3 (les boites se trouvent dans /home/mail/monsite.com). Ensuite parce que les permissions ne sont pas les mêmes (mailboxes:mailboxes et non plus vpopmail:vchkpw). Enfin et surtout parce que le serveur de mail (Postfix) fonctionne avec MySQL sur la Release 3. Il faut donc au minimum créer les boites une par une sur le nouveau serveur à l’aide de PostfixAdmin.

    Prudence donc…

    Attention également que la Release 3 est toujours officiellement en beta à l’heure actuelle. Il s’agit certes d’une beta qui s’éternise et il y a déjà assurément un bon nombre de serveurs en production qui tournent correctement avec cette release. C’est vrai … mais il n’en demeure pas moins que cela reste une beta…

  45. Hello,

    J’avais à l’époque utilisé ton tuto pour migrer mes sites et ça marchait nickel. Je voulais te remercier pour ça car je ne l’avais pas fait.

    Maintenant je souhaite migrer de la Release 2 vers la Release 3. Tu n’as pas envie d’adapter ton tuto 😉

    Merci encore

  46. Euh, non, ce n’est pas à l’ordre du jour 😉

    En fait cela fait déjà un moment que je milite pour Virtualmin à la place de la release OVH (peu importe la version d’ailleurs).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.