Aller au contenu principal

2 articles tagués avec « tests »

Voir tous les tags

Migrer un site cPanel vers un VPS sans interruption

· 7 minutes de lecture
Customer Care Engineer

Publié le 10 septembre 2026

Migrer un site cPanel vers un VPS sans interruption

Pour migrer un site cPanel vers un VPS sans panne surprise, traitez le DNS comme le basculement final, pas comme la première tâche. Préparez le serveur de destination, copiez le compte, testez-le sur la nouvelle adresse IP, réduisez le TTL DNS, puis modifiez les enregistrements uniquement après validation des contrôles de l'application, du courrier et du SSL. Le site reste disponible pendant que le travail se fait en arrière-plan.

Pour le site d'une petite entreprise, un compte d'agence ou une boutique avec des commandes en direct, la migration consiste moins à déplacer des fichiers qu'à préserver le comportement du service. Les versions de PHP, les autorisations de base de données, les tâches cron, le routage des e-mails, les redirections et les règles de pare-feu doivent tous arriver dans un état validé et fonctionnel. Les fichiers sont généralement la partie facile. Ce sont les petits réglages cachés autour d'eux qui donnent des cheveux gris aux migrations.

Étude de cas sur la récupération de sauvegarde : retour 6 heures en arrière

· 7 minutes de lecture
Customer Care Engineer

Publié le 10 juillet 2026

Étude de cas sur la récupération de sauvegarde : retour 6 heures en arrière

À 02:14 UTC, la vitrine a cessé d’écrire les commandes dans la base de données. À 02:19, le site servait encore des pages en cache, mais le passage en caisse relevait déjà de la fiction. Cette étude de cas sur la récupération de sauvegarde décrit ce qui s’est passé ensuite sur un VPS de production pour une petite entreprise d’e-commerce, ce que nous avons restauré, ce que nous n’avons pas restauré aveuglément, et pourquoi le service était de nouveau stable avant l’aube.

Le client utilisait une pile assez standard pour une boutique en ligne en croissance : Nginx, PHP-FPM, MariaDB, Redis, et un panneau de contrôle utilisé par deux employés non administrateurs système. Le trafic n’était pas énorme, mais le timing était douloureux. Une campagne promotionnelle avait fait grimper le volume de commandes, les écritures en base de données atteignaient un pic, et un problème de stockage au niveau du système de fichiers a commencé à corrompre les tables actives de la base de données. Rien de dramatique au sens hollywoodien du terme, mais suffisamment sérieux pour que chaque minute compte.

La première tâche n’était pas la restauration. La première tâche consistait à empêcher la propagation des dégâts. Nous avons placé l’application en mode maintenance, préservé l’état actuel du disque pour analyse, et vérifié si la réplication, les snapshots ou les dumps logiques nous donnaient le point de récupération le plus propre. C’est plus important qu’on ne veut bien l’admettre. Une récupération rapide, c’est bien. Une récupération rapide vers des données endommagées, c’est juste une déception plus rapide.