Checklist pour votre stratégie de backup
Intégrité
- Contenu du zip valide :
- Validation de la taille
- Validation des différences
- Restauration sur un staging
- Automatisation de la restauration
- Validation des pages clefs
Redondance
- 2 outils de backups :
- Outil au niveau du site
- Outil au niveau du serveur
- 3 backups ou plus
- 1 support hors serveur ou plus
Sécurité
- Stockage sécurisé :
- Hors serveur web
- Backups protégés sur le serveur web
- Accès limités
Gouvernance
- Plage de backup :
- Période de bas trafic
- Pas d’overlap entre les différents sites
- Pas d’overlap avec les backups hébergeur
- Fréquence des backups :
- Fréquence du site adaptée à sa donnée
- Fréquence particulière pour la donnée critique
Restauration
- Document interne :
- Procédure de restauration
- Estimation des délais
- Répétitions :
- Ajout à l’onboarding IT
- Utilisation de la procédure pour les stagings
Gouvernance versus RGPD
La gouvernance des données et le RGPD sont deux sujets proches mais ils ne traitent absolument pas un sujet similaire. De ce fait, il est possible d’être totalement conforme au RGPD tout en ayant une gouvernance des données problématique.
RGPD
Le RGPD est là pour informer les utilisateurs de l’usage de leurs données et surtout pour leur donner un droit de regard sur ce qui en est fait.
De ce fait, il est possible de traiter des données avec des services américains ou même chinois si cela a été validé en amont par le client.
Gouvernance des données
La gouvernance des données vise quant à elle à éviter l’ingérence d’une puissance étrangère dans vos données.
Cela peut se faire autant par une coupure d’accès qu’un accès frauduleux.
Ce sujet est particulièrement d’actualité avec les tensions géopolitiques actuelles. Le Cloud Act américain permet aux autorités américaines d’accéder aux données hébergées par des entreprises américaines, même si les serveurs sont en Europe. Une coupure de service – technique, politique ou commerciale – peut rendre vos backups inaccessibles du jour au lendemain.
Vos backups sont votre dernière ligne de défense : ils doivent rester sous votre contrôle, idéalement chez un hébergeur soumis à la législation européenne.
Restauration sur un staging
Un backup qui n’a jamais été testé est un backup qui n’existe pas. L’objectif : automatiser la restauration pour qu’elle tourne sans intervention humaine.
Création du script Ansible
Le playbook couvre l’ensemble de la procédure :
- Récupérer le dernier backup depuis le stockage distant
- Arrêter les services du staging (Apache/Nginx, PHP-FPM)
- Restaurer fichiers + dump SQL
- Adapter la configuration (URLs, credentials, désactivation des emails)
- Vider les caches, redémarrer les services
- Vérifications automatiques (HTTP 200 sur les pages clefs)
Avantage d’Ansible vs un script Bash : gestion des erreurs et idempotence – vous pouvez relancer en cas d’échec partiel.
Création de la cron
- Fréquence : hebdomadaire minimum
- Timing : après la fenêtre de backup (ex: backup à 3h, restauration à 5h)
- Notifications : alerte email/Slack en cas d’échec
- Logs : sortie redirigée vers un fichier daté
Mise en place du uptime
Après chaque restauration, le monitoring vérifie que le staging est fonctionnel. Trois checks minimum :
- Page d’accueil (HTTP 200)
- Page produit/article (base de données restaurée)
- Page de login admin (back-office accessible)
Si un check échoue après la fenêtre de restauration → alerte immédiate. Vous savez que le backup ou la procédure a un problème avant d’en avoir besoin en urgence.