Restaurer une sauvegarde : si vous ne l'avez pas testée, vous ne l'avez pas

« Nous avons des sauvegardes quotidiennes. » C'est ce que dit presque tout le monde, et c'est généralement vrai. Ce que l'on sait rarement, c'est si ces sauvegardes peuvent être restaurées, combien de temps cela prend et ce qui se perd en route. On ne le découvre que de deux façons : lors d'un exercice au calme ou le jour où la boutique est hors ligne. La seconde est la plus fréquente.

Cet article ne parle pas du nombre de sauvegardes à faire ni de l'endroit où les conserver, mais de l'étape que presque personne ne franchit : vérifier qu'elles reviennent.

Ce qui échoue lors de la restauration d'une boutique

Voici les problèmes les plus fréquents quand une sauvegarde est utilisée pour la première fois :

• La sauvegarde ne contient que les fichiers, ou que la base de données. L'hébergeur copie le dossier web, mais la base de données est sur un autre serveur et n'est pas incluse. Ou l'inverse : il y a des exports SQL quotidiens, mais les images des produits ne sont pas copiées.
• L'export est tronqué. Il a été généré avec une limite de temps ou de taille et il lui manque les dernières tables. Le fichier existe, il pèse assez lourd et personne ne l'a jamais ouvert.
• La sauvegarde est celle de la boutique déjà infectée. Si le problème est un piratage, les sauvegardes des dernières semaines peuvent contenir la même porte dérobée.
• Seuls quelques jours sont conservés. Quand vous découvrez le problème, la dernière bonne sauvegarde a déjà été supprimée.
• Personne n'y a accès. Les sauvegardes sont dans le panneau d'un hébergement dont le mot de passe appartenait à quelqu'un qui est parti, ou dans un compte de stockage au nom de l'ancienne agence.
• La restauration prend des heures. Une boutique avec un grand catalogue peut avoir des dizaines de gigaoctets d'images. Les télécharger et les renvoyer prend du temps, et personne ne l'avait calculé.
• La boutique restaurée ne démarre pas. À cause de différences de version de PHP ou de MySQL entre le serveur d'origine et le nouveau, de caches qui pointent vers d'anciens chemins ou d'une configuration avec le mauvais domaine.

Ce que doit contenir une sauvegarde de PrestaShop

1. La base de données complète, avec un export cohérent (et non en copiant les fichiers de MySQL à chaud).
2. Tous les fichiers : cœur, modules, thème, img/ avec les images des produits, download/ si vous vendez des produits téléchargeables, upload/ avec les fichiers des clients et les factures si elles sont stockées sur disque.
3. La configuration : le fichier de paramètres avec les clés de l'installation. Sans la clé de cookies d'origine, les anciens mots de passe des clients ne pourront pas être vérifiés.
4. Ce qui vit en dehors du dossier web : tâches planifiées, configuration du serveur, règles de redirection, certificats.

Comment faire un exercice sans toucher à la production

Un exercice consiste à restaurer une vraie sauvegarde ailleurs que sur la boutique, comme si la boutique avait disparu. Inutile d'arrêter quoi que ce soit.

1. Choisissez une sauvegarde au hasard, pas celle d'hier soir. Si vous ne testez que la dernière, vous ne savez pas si celles d'il y a une semaine sont valables.
2. Restaurez-la dans un environnement séparé : un sous-domaine de test protégé par mot de passe, un serveur local ou un hébergement temporaire.
3. Isolez la copie avant de l'ouvrir. Désactivez l'envoi d'e-mails, passez les passerelles de paiement en mode test, bloquez l'indexation et supprimez les tâches planifiées. Une boutique restaurée avec tout activé peut écrire à vos clients ou les débiter.
4. Chronométrez chaque étape : téléchargement, envoi des fichiers, import de la base de données, ajustement du domaine, vidage du cache.
5. Vérifiez qu'elle fonctionne vraiment : page d'accueil, une catégorie, une fiche produit avec images, le back-office, une commande de test jusqu'au bout, les factures d'une ancienne commande, la recherche.
6. Comparez avec la production : nombre de produits, de clients et de commandes, et date de la dernière commande de la sauvegarde.
7. Notez ce qui a échoué et corrigez-le dans le système de sauvegarde, pas dans la sauvegarde.

Deux chiffres que vous devez connaître

L'exercice vous donne les deux réponses qui comptent le jour du problème :

• Ce que vous pouvez perdre : le temps écoulé entre la dernière sauvegarde et le moment de la panne. Avec des sauvegardes quotidiennes, jusqu'à une journée de commandes, de clients et de modifications du catalogue. Si c'est trop, il vous faut des sauvegardes de la base de données plus fréquentes.
• Le temps qu'il vous faut pour revenir : la durée réelle de l'exercice, plus la marge liée à la précipitation et au stress. Si c'est six heures, la boutique sera hors ligne six heures.

Avec ces deux chiffres, vous pouvez décider sur des données concrètes si votre système de sauvegarde suffit ou s'il vous en faut un autre.

Restaurer après un piratage

C'est le cas le plus délicat. Revenir à la dernière sauvegarde ne suffit pas :

• Déterminez quand le problème a commencé et restaurez une sauvegarde antérieure, ou restaurez la plus récente et nettoyez-la en la comparant avec le cœur et les modules d'origine.
• Récupérez les commandes et les clients postérieurs à la sauvegarde depuis la base de données actuelle, en prenant soin de ne pas ramener aussi ce que l'attaquant y a ajouté.
• Fermez la porte d'entrée avant de rouvrir. Sinon, la boutique restaurée sera tout aussi exposée.
• Changez tous les identifiants après la restauration.

Mettez-le par écrit

La procédure de restauration doit être écrite : où se trouvent les sauvegardes, avec quel compte on y accède, quelles étapes suivre, qui s'en charge et qui appeler si cette personne n'est pas là. Le jour où vous en aurez besoin ne sera pas un jour tranquille, et ce qui n'est pas écrit sera oublié. Répétez l'exercice tous les quelques mois et toujours après un changement d'hébergeur, de version de PrestaShop ou de PHP : une sauvegarde qui se restaurait bien sur l'ancien serveur peut ne pas le faire sur le nouveau.

Comment le résoudre dans PrestaShop

Le Hosting plan profesional de Rekire est conçu pour héberger des boutiques PrestaShop. Si vous préférez rester chez votre hébergeur actuel, avec un forfait d'heures de support Rekire, nous examinons vos sauvegardes, faisons l'exercice de restauration dans un environnement isolé (sans e-mail sortant, avec les passerelles en mode test et sans indexation), mesurons le temps nécessaire et ce qui se perd, et vous laissons la procédure écrite pour le jour où vous en aurez besoin.