Comment restaurer une sauvegarde SiteGround : Guide technique pour webmasters

En tant que futur(e) webmaster, la gestion des sauvegardes est votre assurance vie professionnelle. Dans votre flux de travail, qu’il s’agisse d’une mise à jour qui fait sauter un hook, d’un conflit de plugins après une maintenance ou d’un nettoyage de malware, maîtriser la restauration est non négociable.

Si vos clients sont hébergés chez SiteGround, vous bénéficiez d’une interface robuste : les Site Tools. Voici comment gérer une restauration dans les règles de l’art.

Le réflexe du webmaster : L’audit avant l’action

Avant de cliquer sur « Restaurer », analysez toujours l’impact. Chez SiteGround, les sauvegardes automatiques sont conservées 30 jours.

Conseil de pro : Avant toute restauration majeure sur un site en production, effectuez une sauvegarde manuelle de l’état « cassé ». Cela peut paraître contre-intuitif, mais cela permet de récupérer des données récentes (dernières commandes WooCommerce, articles de blog publiés le matin même) après avoir restauré une version stable de la veille.

En l’occurrence, il n’est pas toujours indispensable de restaurer une sauvegarde. Il convient avant de recherche la cause du plantage :

• est-ce qu’il y a une maintenance quelconque chez l’hébergeur web ?
• Que dit le journal error.log ?

Bref, investiguez avant de sortir l’artillerie lourde, surtout si côté client, entre la veille (dernière sauvegarde) et le moment du bug/plantage, il y a eu de nombreux travaux sur le ou les sites concernés.

Étape 1 : Accéder à l’environnement Site Tools

Le panneau de contrôle de SiteGround est spécifique par domaine.

1. Connectez-vous à l’espace client.
2. Onglet Websites > Bouton Site Tools du client concerné.
3. Dans la colonne de gauche, naviguez vers Sécurité (Security) > Sauvegarde (Backups).

Étape 2 : Choisir le type de restauration selon l’incident

C’est ici que votre expertise fait la différence. Ne restaurez que ce qui est nécessaire pour minimiser le temps d’arrêt et les pertes de données.

• Restaurer tous les fichiers et bases de données : À réserver aux « White Screens of Death » (WSOD) ou hacks profonds. Attention : si l’hébergement contient plusieurs sites sous le même dossier racine, vérifiez les exclusions.
• Restaurer des fichiers : Idéal si vous avez corrompu un fichier .htaccess, wp-config.php ou un fichier du thème enfant.
• Restaurer les bases de données : L’option chirurgicale. Si le site affiche des erreurs de base de données ou si un réglage d’extension a tout bloqué.
• Restaurer les emails : Utile si votre client a supprimé par erreur des comptes ou des messages critiques.

Étape 3 : Exécution et Monitoring

Une fois la date choisie (priorisez la sauvegarde la plus proche du bug) :

1. Cliquez sur les options (⋮) à droite de la ligne.
2. Lancez la procédure.
3. Temps technique : Comptez entre 2 et 10 minutes.

Validation : Ne quittez jamais l’onglet avant d’avoir vu le message de confirmation « Réussite / Restauration terminée ». Une fois terminé, videz immédiatement le cache serveur (SG Optimizer) et le cache CDN pour vérifier la remise en ligne réelle.

Pourquoi inclure ce service dans vos contrats de maintenance ?

En tant que webmaster indépendant, votre valeur ajoutée ne réside pas seulement dans la création, mais dans la pérennité.

• Sécurité et Sérénité : Un client qui sait que vous maîtrisez la restauration est un client fidèle.
• Analyse Post-Mortem : Après une restauration, identifiez la cause (conflit de version PHP, script obsolète) pour conseiller une mise à jour structurelle.
• Rentabilité : Automatiser et maîtriser ces outils vous permet d’intervenir en quelques minutes sur un ticket d’urgence facturé au forfait ou à l’heure.

Check-list post-restauration (Le protocole pro)

Restaurer n’est que la moitié du travail. Un bon webmaster suit ce protocole pour s’assurer que tout est reparti :

1. Flush du Cache : SiteGround utilise le SuperCacher. Allez dans Site Tools > Speed > Caching et videz tout (Nginx, Dynamic, Memcached). Sinon, vous pourriez voir encore l’ancienne version buggée.
2. Vérification SSL : Parfois, une restauration peut entrer en conflit avec le renouvellement récent d’un certificat Let’s Encrypt. Vérifiez que le petit cadenas est bien là.
3. Le test des formulaires : Testez toujours un formulaire de contact après une restauration. C’est souvent là que les erreurs PHP invisibles se cachent.
4. L’analyse de cause : Pourquoi avez-vous dû restaurer ? Consultez les Error Logs (Statistics > Error Log) pour identifier le fichier coupable et éviter que le bug ne se reproduise demain.

Attention au « Décalage de Données » (Point critique)

C’est le point le plus important à prendre en compte pour les sites avec par exemple travail en équipe et par exemple : des publications nombreuses chaque jour. Si vous restaurez un site e-commerce à « J-1 » à 14h alors qu’il est 16h :

• Vous perdez les commandes passées entre 14h hier et 16h aujourd’hui. Idem pour les articles
• Toujours faire un export CSV des tables wp_orders et wp_users avant de restaurer, pour pouvoir ré-importer les données manquantes après la remise en ligne.

FAQ Technique pour Webmasters