Table des matières de l'article :
Certaines migrations sont difficiles en raison de la complexité de l'infrastructure. D'autres le sont à cause du volume important de données, d'une application mal développée, d'une base de données volumineuse ou encore de la nécessité d'intervenir sur des systèmes hérités restés inexploités pendant des années.
Et puis il y a les migrations qui deviennent difficiles pour une raison que, franchement, après tant d'années dans ce métier, nous avons encore du mal à accepter : le manque de collaboration entre les fournisseurs.
Cet article relate un cas réel que nous avons traité ces derniers jours.
Nous ne nommerons pas le client et appellerons ses deux domaines example.com et exampletwo.com , car le sujet de cet article n'est pas le client.
Le problème, ce sont nous, les fournisseurs.
L’objectif est de comprendre ce qui doit se produire lorsqu’une entreprise décide de changer de partenaire technologique et, surtout, ce qui ne doit jamais se produire.
Tout a commencé avec deux WooCommerce très lents
Le client nous contacte car il gère deux sites WooCommerce présentant d'importants problèmes de performance web.
Des temps de réponse élevés, un système dorsal peu réactif et une situation générale qui ont rendu nécessaire l'évaluation d'une infrastructure différente, dont nous avons parlé hier sur notre blog dans cet article.
Après les vérifications initiales, il a été décidé de migrer les services vers Managed Server Srl.
Une situation tout à fait normale.
Quiconque travaille dans l'hébergement sait pertinemment que les clients vont et viennent. Cela nous arrive, cela arrive à nos concurrents, et cela continuera d'arriver.
Il n'existe pas de fournisseur idéal pour chaque projet et pour chaque étape de la vie d'une entreprise.
Un client peut choisir un autre fournisseur d'hébergement parce qu'il recherche des services différents, a besoin d'une expertise plus pointue, modifie son budget, change de gestionnaire ou souhaite simplement essayer quelque chose de nouveau.
Cela fait partie du marché.
Dans ce cas précis, outre les sites web, les comptes de messagerie associés aux deux domaines ont également dû être transférés.
Et c'est là qu'une migration techniquement ordinaire s'est transformée en quelque chose de complètement différent.
La demande était très simple : ne touchez à rien d'autre.
Pour organiser correctement une migration de ce type, vous n'avez besoin de rien de particulièrement exotique.
Nous avions essentiellement demandé deux choses : fournir la sauvegarde des sites et modifier les serveurs de noms du.
Rien d'autre.
Nous n'avons pas demandé la suppression des comptes. Nous n'avons pas demandé la suspension immédiate des services. Nous n'avons pas demandé la suppression des boîtes mail.
Nous ne l'avions pas demandé, et le client ne l'avait pas demandé non plus.
À l'inverse, lors d'une migration, il est essentiel que l'ancienne infrastructure reste disponible pendant la durée strictement nécessaire à la réalisation des synchronisations.
C'est particulièrement vrai pour le courrier électronique.
Un site web peut être copié à un point précis, puis réaligné. En revanche, les e-mails sont en perpétuelle évolution : de nouveaux messages arrivent, les utilisateurs y répondent, déplacent et suppriment des e-mails, envoient des pièces jointes, créent des brouillons et modifient constamment le statut de leurs dossiers.
Une boîte aux lettres est un ensemble de données vivant.
C’est pourquoi une migration IMAP réussie se déroule généralement en plusieurs étapes, en maintenant le serveur source accessible jusqu’à ce que la transition soit terminée.
Stratégie attendue : imapsync
Pour transférer les boîtes aux lettres, nous avions configuré une migration normale via imapsync.
Les administrateurs de serveurs de messagerie connaissent bien cet outil. Son principe de fonctionnement est relativement simple :
SERVER IMAP SORGENTE | | IMAP v imapsync | | IMAP v SERVER IMAP DESTINAZIONE
imapsync Il s'authentifie sur la boîte aux lettres source, lit les dossiers et les messages, puis les réplique vers la destination.
L’un des grands avantages de cette méthodologie est que, du point de vue de la migration, il n’est pas nécessaire de connaître en détail le format dans lequel le serveur source stocke physiquement le courrier électronique.
Le serveur peut utiliser Maildir, mdbox ou un autre système de gestion de fichiers compatible avec son service IMAP.
Du point de vue du client effectuant la migration, nous voyons simplement quelque chose comme ceci :
INBOX Sent Drafts Trash Archive spam
et, bien sûr, les messages associés.
C'est le serveur source qui est responsable de la traduction de son stockage physique en représentation logique exposée via IMAP.
Il existe également une autre caractéristique fondamentale : imapsync peut être effectué plusieurs fois.
Nous pouvons alors effectuer une synchronisation initiale d'une boîte aux lettres de 20 Go, attendre qu'elle soit terminée, puis relancer le processus quelques heures avant le basculement final.
La seconde synchronisation ne nécessite pas forcément de transférer à nouveau toutes les données. Son objectif principal est de récupérer les modifications , c'est-à-dire tout ce qui a changé entre la première copie et la synchronisation finale.
Il s'agit d'une méthode très courante dans les migrations de messagerie électronique, qui permet de réduire considérablement le risque de perte de messages pendant le transfert.
Puis, moins de 24 heures plus tard, les comptes sont suspendus.
L'ancienne infrastructure était gérée par une entreprise opérant dans les secteurs du développement web, du référencement et du marketing web.
Et c'est à ce moment-là qu'un événement s'est produit qui, sur le plan professionnel, nous a beaucoup déçus.
Malgré la demande de ne plus intervenir sur les services pendant la migration, moins de 24 heures plus tard, les comptes ont été suspendus , rendant de fait inaccessibles les boîtes aux lettres IMAP nécessaires à la réalisation des synchronisations.
L'effet technique fut immédiat :
imapsync | X | SERVER IMAP SORGENTE NON PIÙ ACCESSIBILE
À partir de ce moment-là, nous n'avons plus pu effectuer le réalignement normal des boîtes aux lettres.
Et, plus important encore, nous ne pouvions plus récupérer les messages via IMAP arrivés après la dernière copie disponible des données.
Sur ce point, nous tenons à être très clairs : nous ne discutons pas des intentions de ceux qui ont pris cette décision.
Nous ne l'avons certainement pas commandé, pas plus que le client qui a tenté en vain de réactiver son compte.
Nous décrivons ici l'effet technique objectif que nous avons constaté : la suspension du compte a empêché la procédure IMAP de se terminer comme prévu.
À partir de ce moment-là, nous avons été contraints de changer complètement de stratégie.
Deux adresses e-mail certifiées, e-mails, WhatsApp et appels téléphoniques
Ce qui nous a le plus déçus, ce n'était même pas la difficulté technique.
Les problèmes techniques sont résolus. C'est notre métier.
Ce qui nous a paru beaucoup plus difficile à comprendre, c'est l'impossibilité d'établir une comparaison technique directe avec le fournisseur précédent.
Nous avons envoyé deux courriels certifiés , écrit par courriel , communiqué par WhatsApp et essayé de téléphoner.
Et le client aussi.
Malgré des tentatives répétées, nous n’avons pas été en mesure d’établir un dialogue technique direct qui nous permettrait de coordonner la migration.
Et c’est probablement l’aspect sur lequel nous aimerions inviter tous les acteurs du secteur à réfléchir.
Parce qu'un simple coup de téléphone aurait suffi.
Cinq minutes.
« Quand avez-vous fini avec le courrier ? »
« Demain à 18h. »
« Parfait, laissons IMAP activé jusqu’à demain soir. »
Fin.
Pas de guerres. Pas de procédures spéciales. Plus besoin de restaurer manuellement les e-mails à partir d'une sauvegarde.
Nous avions cependant une sauvegarde cPanel.
Heureusement, nous avions une sauvegarde cPanel suffisamment récente.
À ce stade, nous avons commencé à étudier la possibilité de récupérer directement les courriels contenus dans la sauvegarde.
Et c'est là que l'histoire devient techniquement intéressante.
Lorsque nous avons ouvert la structure de la boîte aux lettres, nous avons constaté que nous n'avions pas affaire à un Maildir normal.
Nous nous sommes retrouvés devant Dovecot mdbox.
Maildir et mdbox ne sont pas la même chose.
Sur notre infrastructure, le courrier électronique est géré via Dovecot en utilisant Maildir.
Un Maildir traditionnel possède une structure facilement reconnaissable :
Maildir/ ├── cur/ ├── new/ ├── tmp/ ├── .Sent/ ├── .Drafts/ ├── .Trash/ └── .Archive/
Le concept de base est relativement simple : un message est essentiellement la même chose qu'un fichier.
Si nous ouvrons le répertoire cur/ Nous trouvons des centaines, des milliers, voire, dans les cas les plus importants, des millions de fichiers. Chacun de ces fichiers représente un message.
mdbox fonctionne de manière complètement différente.
Dans la sauvegarde cPanel, nous avons trouvé des structures de ce type :
storage/ ├── dovecot.map.index ├── dovecot.map.index.log ├── m.1 ├── m.2 ├── m.3 ├── m.100 ├── m.305 └── ...
et, en même temps :
mailboxes/ ├── INBOX/ │ └── dbox-Mails/ │ ├── dovecot.index │ ├── dovecot.index.cache │ └── dovecot.index.log ├── Sent/ ├── Drafts/ ├── Trash/ ├── Archive/ └── spam/
Ici, le paradigme change complètement.
Dans mdbox, un fichier comme :
m.305
Ceci ne correspond pas au numéro de courriel 305.
C'est un conteneur.
Il peut stocker plusieurs messages. Dovecot utilise ensuite des cartes et des index pour déterminer l'emplacement de chaque message et la boîte aux lettres à laquelle il appartient.
Parmi les fichiers essentiels, on trouve des éléments tels que :
dovecot.map.index dovecot.map.index.log dovecot.index dovecot.index.cache dovecot.index.log
Par conséquent, il n'était pas possible de prendre trivialement :
m.1 m.2 m.3 ...
et copiez-les dans le nouveau répertoire Maildir.
Du point de vue du format de stockage, cela n'aurait eu aucun sens.
D'une migration à une véritable récupération de stockage
À ce stade, ce qui était censé être une migration IMAP normale s'était transformé en une véritable opération de récupération.
Nous devions faire en sorte que Dovecot interprète correctement l'ancien stockage mdbox et reconstruise logiquement les boîtes aux lettres.
Nous avons ensuite mis en place un environnement de travail séparé.
La première règle dans une telle activité est très simple : ne travaillez pas directement sur la seule copie disponible de la sauvegarde.
Les boîtes aux lettres individuelles ont été copiées dans des répertoires temporaires et toutes les opérations ont été effectuées sur les copies de travail.
Nous avons ensuite utilisé doveadm pour vérifier si Dovecot était effectivement capable de lire les données stockées.
Après avoir géré l'UID, le GID et les permissions de l'utilisateur technique utilisé pour la conversion, nous avons finalement pu interroger une boîte aux lettres mdbox.
Le résultat était quelque chose comme ceci :
Archive Sent Drafts Trash spam INBOX
Ce fut le tournant.
Cela signifiait que Dovecot interprétait correctement :
- je dépose
m.*contenant les messages ; - le fichier
dovecot.map.index; - les index des boîtes aux lettres individuelles ;
- la relation entre les messages, le stockage physique et les dossiers logiques.
La sauvegarde était utilisable.
Problème suivant : mdbox et Maildir ont des mises en page différentes.
À ce stade, nous pouvions lire correctement la source.
Il restait à le transformer.
Nous avons ensuite commencé à utiliser doveadm e dsync Pour convertir du format mdbox au format Maildir :
Dovecot mdbox | | dsync v Dovecot Maildir
Là aussi, cependant, il ne suffisait pas d'indiquer simplement une source et une destination.
L'un des premiers problèmes rencontrés concernait le séparateur de hiérarchie des boîtes aux lettres virtuelles.
En résumé, le stockage source mdbox et le système de destination Maildir++ traditionnel n'utilisaient pas la même représentation de la hiérarchie des boîtes aux lettres.
Le résultat a été une erreur de ce type :
Mail locations must use the same virtual mailbox hierarchy separator
Il était donc nécessaire de rendre l'espace de noms et la mise en page de destination compatibles en utilisant un Maildir avec :
LAYOUT=fs
obtention finale d'une structure cohérente :
utente/ ├── cur/ ├── new/ ├── tmp/ ├── Archive/ │ ├── cur/ │ ├── new/ │ └── tmp/ ├── Drafts/ │ ├── cur/ │ ├── new/ │ └── tmp/ ├── Sent/ ├── Trash/ └── spam/
À ce moment-là, nous avions à nouveau de vrais messages au format Maildir , utilisables sur la nouvelle infrastructure.
Même les actions voulaient se joindre à la fête
Un autre problème est apparu lors de la conversion.
Le pigeonnier de la machine utilisée pour la procédure avait un dos quota-dict.
dsync, tout en écrivant les messages convertis, il a également tenté de mettre à jour les quotas de boîtes aux lettres :
quota-dict: Quota update failed Quota is now desynced
En fonctionnement normal d'un serveur de production, ce comportement serait parfaitement logique.
Lors d'une conversion hors ligne, cependant, non.
Nous ne souhaitions pas mettre à jour le quota d'une boîte mail temporaire en temps réel. Ce qui nous intéressait, c'était la récupération correcte des messages.
Nous avons donc exclu le plugin de quota des invocations utilisées pour la conversion :
mail_plugins=''
et la guérison est complète.
Une fois les boîtes aux lettres placées à leur destination finale, les quotas peuvent être reconstitués via Dovecot avec une procédure de recalcul normale, par exemple :
doveadm quota recalc -u [utente@esempio.com](mailto:utente@esempio.com)
suivi de la vérification appropriée :
doveadm quota get -u [utente@esempio.com](mailto:utente@esempio.com)
Ce qui devait initialement être simple :
imapsync sorgente → destinazione
était désormais devenu :
backup cPanel | v analisi storage | v riconoscimento mdbox | v copia di sicurezza | v lettura indici Dovecot | v ricostruzione mailbox | v gestione UID/GID | v gestione namespace | v conversione mdbox → Maildir | v gestione quota | v importazione | v ricalcolo quote
Tout cela pour réaliser ce que, dans des conditions normales, nous aurions pu transférer via une synchronisation IMAP classique.
La sauvegarde nous a sauvés, mais une sauvegarde est une photographie
Heureusement, nous avons pu récupérer le courriel à partir de la sauvegarde.
Cependant, il existe un problème qu’aucune expertise en ingénierie système ne peut résoudre : une sauvegarde ne peut contenir que ce qui existait au moment de sa création.
La sauvegarde disponible était à jour au 6 août.
Lorsque nous avons dû procéder à la récupération, nous étions déjà le 10 août.
Backup disponibile: 6 agosto Data del recupero: 10 agosto Gap temporale: circa 4 giorni
Une sauvegarde est une photographie.
Vous pouvez connaître Dovecot dans les moindres détails, vous pouvez reconstruire les index, convertir le stockage, réparer les autorisations et interpréter correctement mdbox, mais vous ne pouvez pas récupérer à partir d'un instantané du 6 août quelque chose qui s'est produit les 7, 8, 9 ou 10 août.
Si ces données ne sont pas présentes dans la sauvegarde, elles n'existent tout simplement pas dans cet ensemble de données.
Et c'est précisément pour cette raison que nous avions prévu de l'utiliser. imapsync.
Nous aurions pu utiliser une sauvegarde ou une synchronisation initiale pour transférer la majeure partie des données, puis interroger à nouveau l'ancien serveur pour récupérer tout ce qui avait changé entre-temps.
Autrement dit : le delta.
Mais si le serveur source n'est plus accessible, ce delta ne peut pas être acquis.
Le résultat concret a donc été un manque d'environ quatre jours d'historique de courriels indisponible dans la sauvegarde utilisée pour la récupération.
Et c'est sans doute la partie de toute cette histoire qui nous attriste le plus.
Il ne s'agit pas d'être concurrents
Nous sommes, au moins en partie, des opérateurs sur le même marché que l'autre société.
Il s'agit donc d'entités qui, à certains égards, peuvent être considérées comme concurrentes.
Mais être concurrents ne signifie pas être ennemis.
Au fil des ans, nous avons reçu des dizaines et des dizaines de demandes concernant la migration de clients de serveurs gérés vers d'autres fournisseurs.
Ça arrive.
Lorsqu'un client décide de partir, la chose professionnelle à faire est de remettre ce qui est nécessaire et de permettre au nouveau fournisseur de travailler.
Si un ingénieur système nous appelait demain et disait :
« Je suis en train de migrer l'un de vos anciens clients. Pouvez-vous laisser IMAP disponible pendant encore 48 heures pour finaliser la migration ? »
La réponse techniquement sensée serait :
"Certain."
Non pas parce que nous sommes bons.
Parce que c'est techniquement correct.
Parce que les données appartiennent au client.
Car de l'autre côté, il y a un professionnel qui essaie de faire son travail.
Et parce que, après-demain, ce sera peut-être nous qui devrons l'appeler.
Le client ne doit pas devenir l'otage de la rivalité entre les fournisseurs
Il existe un principe que nous devrions garder à l'esprit plus souvent dans notre secteur.
Lorsqu'un client change de fournisseur, ce changement doit être aussi transparent que possible pour lui.
Il ne devrait pas être nécessaire de l'impliquer dans les discussions techniques entre deux entreprises.
Vous ne devriez pas jouer le rôle d'opérateur téléphonique entre deux fournisseurs informatiques.
Vous ne devriez pas avoir à vous demander ce qu'est un enregistrement MX, un serveur de noms, mdbox, Maildir, rsync, imapsync ou la synchronisation incrémentale.
Nous devrions nous parler.
"De quoi avez-vous besoin?"
"Ce."
"Jusqu'à?"
"Demain."
"D'accord."
Dans bien des cas, cela suffirait amplement.
Notre profonde déception professionnelle
Ce que nous ressentons à la fin de cette histoire, c'est avant tout une profonde déception professionnelle.
Non pas parce que nous devions travailler plus dur.
Nous avons également choisi de devenir ingénieurs système parce que nous aimons résoudre des problèmes complexes.
Et, d'un point de vue purement technique, transformer une sauvegarde cPanel contenant des boîtes aux lettres mdbox en boîtes aux lettres Maildir parfaitement lisibles constituait même un problème intéressant à résoudre.
La déception vient du fait qu'il n'aurait pas été nécessaire de faire tout cela.
Il n'aurait pas été nécessaire de reconstruire l'entrepôt.
Il n'aurait pas été nécessaire de travailler sur les indices Dovecot.
Il n'aurait pas été nécessaire de résoudre les incompatibilités d'espaces de noms.
Il n'aurait pas été nécessaire de convertir mdbox en Maildir.
Il n'aurait pas été nécessaire de gérer les quotas hors ligne.
Et, plus important encore, il aurait été possible d'effectuer la dernière synchronisation des messages.
Il aurait suffi de laisser les comptes disponibles le temps nécessaire pour achever une migration déjà en cours.
Un appel à mes collègues du secteur de l'hébergement et de l'ingénierie des systèmes
Cet article ne se contente pas de relater une mauvaise expérience avec un fournisseur en particulier.
Elle s'adresse avant tout à toutes les entreprises travaillant dans l'hébergement, le développement web, les agences web et l'ingénierie des systèmes.
Travaillons ensemble.
Même lorsque nous perdons un client.
Même lorsque le nouveau fournisseur est un concurrent.
Même lorsque nous pensons que le client fait le mauvais choix.
Nous pouvons le lui expliquer. Nous pouvons nous y opposer. Nous pouvons même être convaincus qu'il reviendra vers nous dans trois mois.
Mais lorsqu'un client décide de migrer, nous veillons à ce qu'il puisse le faire de manière ordonnée.
- Si le nouveau fournisseur demande 48 heures supplémentaires d'accès IMAP, accordez-les-lui.
- Si on nous demande une sauvegarde MySQL, nous la fournissons.
- S'il demande de ne pas éteindre l'ancien hôte virtuel tant que la propagation DNS n'est pas terminée, nous attendons.
- Si vous devez convenir d'une période de transition, parlons-en au téléphone.
- Et surtout, si le client payant ne demande pas l'arrêt du service, n'agissez pas de votre propre initiative.
Car au final, c'est notre travail.
Ne mettez pas d'obstacles sur votre chemin.
Résoudre les problèmes.
Nous y sommes enfin parvenus
Malgré tout, nous avons réussi à récupérer le courriel dans la sauvegarde.
Nous avons interprété le stockage mdbox, vérifié les index Dovecot, reconstruit les boîtes aux lettres, converti les messages au format Maildir et préparé les boîtes aux lettres pour la nouvelle infrastructure.
Les courriels disponibles ont été récupérés jusqu'à l'état de la sauvegarde du 6 août.
On regrette toujours le délai qui s'en est suivi, qu'une synchronisation IMAP normale aurait pu éviter.
Et surtout, une question demeure.
Était-il vraiment nécessaire d'en arriver là ?
Nous ne le pensons pas.
C’est pourquoi, après cette expérience, le message que nous souhaitons transmettre est extrêmement simple :
Chers collègues, nous sommes peut-être concurrents. Mais collaborons et ne nous mettons pas des bâtons dans les roues les uns des autres.
Nous en tirons profit.
Ceux qui viendront après nous en bénéficieront.
Mais surtout, le client en profite, car il devrait être le seul à ne pas avoir à subir les conséquences d'un manque de collaboration entre deux fournisseurs.
