Sauvegarde automatique d’un projet web : méthode et restauration

Sauvegarder automatiquement un projet web ne consiste pas à copier le dépôt Git chaque nuit. Le code, les données, les fichiers envoyés, la configuration et les secrets de reprise n’ont pas le même cycle de vie ni les mêmes droits d’accès. Une stratégie utile définit ce qui doit être récupéré, où les copies sont stockées, qui peut les restaurer et comment prouver qu’elles fonctionnent.

L’objectif n’est pas de produire le plus grand nombre d’archives. Il est de retrouver un état utile après une suppression, une erreur de déploiement, une panne de machine ou une compromission. Commencez par une sauvegarde simple, chiffrée et testée, puis automatisez-la après avoir validé la restauration.

Ce que vous allez apprendre

Vous allez inventorier les éléments d’un projet web, choisir une fréquence adaptée, séparer copie locale et copie hors machine, automatiser une tâche avec des contrôles, puis restaurer une copie dans un environnement isolé. Les outils exacts varient ; la méthode reste valable pour un VPS, une base managée ou un stockage objet.

Prérequis

• Une liste des composants du projet : code, base, uploads, variables de configuration, plan de déploiement.
• Un espace de sauvegarde distinct de la machine de production.
• Un compte de sauvegarde dédié, avec les droits minimaux nécessaires.
• Un environnement isolé ou une machine de test pour les restaurations.
• Une personne responsable de recevoir les alertes d’échec.

Ne placez pas la seule copie de sauvegarde sur le même disque que l’application. Une panne de volume, un chiffrement malveillant ou une suppression administrative peut toucher les deux en même temps.

1. Inventorier les données à récupérer

Séparez le code versionné des données qui changent en production. Git peut aider à retrouver un commit, mais il ne restaure pas une base, les uploads, les paramètres de plateforme ou un secret révoqué. Pour chaque élément, notez sa source, son propriétaire, sa sensibilité et l’impact de sa perte.

Un projet web typique comprend au moins : le schéma et les données de base, les fichiers envoyés, les fichiers de configuration contrôlés, les tâches planifiées et les clés ou procédures nécessaires à la reprise. N’archivez pas aveuglément un dossier complet : vous risquez d’emporter caches, secrets inutiles et données qui n’auraient jamais dû être conservées.

Vérification : simulez une machine vide et demandez : « qu’est-ce qui manque pour remettre le service dans un état cohérent ? ». Chaque réponse devient une entrée de votre plan de sauvegarde ou une dépendance à documenter.

2. Définir fréquence, rétention et objectifs

La fréquence dépend de la quantité de travail perdable. Une base qui reçoit des commandes ou des inscriptions peut nécessiter des sauvegardes plus fréquentes qu’un site statique. La rétention dépend du temps nécessaire pour détecter une corruption ou une suppression. Écrivez ces choix en termes simples : perte maximale acceptable et délai maximal de remise en service.

Conservez plusieurs générations. Une copie récente peut déjà contenir une erreur ; une archive plus ancienne peut être nécessaire. Ne confondez pas rétention longue et accès large : les archives historiques doivent rester protégées, documentées et supprimées selon une politique connue.

Vérification : choisissez deux incidents réalistes, par exemple une suppression de fichiers et une base corrompue. Vérifiez qu’au moins une génération de sauvegarde permet de les traiter sans dépasser vos objectifs annoncés.

3. Séparer les copies et protéger l’accès

Envoyez les sauvegardes vers un stockage distinct du serveur de production. Utilisez un compte réservé à cette tâche, avec une clé limitée et une politique de rotation. Chiffrez les archives lorsque leur contenu le justifie et protégez surtout la clé de chiffrement : une archive chiffrée sans clé récupérable ne vous aide pas, tandis qu’une clé posée dans le dépôt annule une grande partie du bénéfice.

Évitez d’utiliser les mêmes identifiants pour produire l’application, administrer le stockage et effacer les sauvegardes. La séparation limite l’effet d’un compte compromis. Si le fournisseur propose une immutabilité ou un verrouillage de rétention, évaluez-le selon votre besoin de récupération et votre capacité à gérer les suppressions légitimes.

Vérification : contrôlez que le compte applicatif ne peut pas effacer les archives et que le compte de sauvegarde ne peut pas déployer le code. Vérifiez l’accès à une archive avec un compte de restauration autorisé, sans afficher de contenu sensible dans les journaux.

4. Automatiser avec des contrôles

Une tâche planifiée doit produire un résultat observable : date, durée, volume, identifiant d’archive et statut, sans y inclure données personnelles ou secrets. Échouer silencieusement pendant plusieurs semaines est plus dangereux qu’une sauvegarde manuelle connue comme absente. Ajoutez une alerte lorsque la tâche échoue, lorsqu’aucune sauvegarde récente n’existe ou lorsque la taille change de manière anormale.

Testez les erreurs : stockage indisponible, quota atteint, clé révoquée ou export de base échoué. La tâche doit signaler l’échec et éviter de remplacer une dernière archive saine par un fichier vide. Si vous utilisez un script, versionnez le script sans ses secrets et relisez ses droits d’exécution.

Vérification : forcez une erreur de destination dans un environnement de test et confirmez que l’alerte est reçue. Vérifiez aussi qu’une archive réussie est lisible et que son intégrité peut être contrôlée.

5. Restaurer dans un environnement isolé

La restauration est le test principal. Créez une copie isolée, restaurez la base et les fichiers sans activer les webhooks, emails ou tâches de production, puis vérifiez les données attendues. Utilisez des variables de test pour empêcher toute notification réelle. Mesurez le temps nécessaire et notez les étapes manuelles : elles révèlent souvent une dépendance oubliée.

Après le test, vérifiez que les permissions de fichiers, les migrations, les comptes de service et les URLs d’environnement sont cohérents. Une archive peut être intacte tout en redémarrant avec les mauvais identifiants ou les mauvaises destinations.

Vérification : effectuez au moins une restauration de bout en bout sur un calendrier défini. Le rapport doit indiquer l’archive utilisée, le temps pris, les écarts et l’action corrective éventuelle.

Problèmes fréquents et solutions

La sauvegarde contient seulement le code. Ajoutez l’export de la base et les fichiers persistants, puis testez leur restauration. Le code seul ne reconstitue pas l’état utilisateur.

Les archives remplissent le disque. Appliquez une rétention explicite, surveillez le quota et contrôlez la suppression des anciennes générations avec un compte séparé.

Une archive est créée mais inutilisable. Vérifiez les permissions, le chiffrement et la clé de restauration. Automatisez une vérification d’intégrité, mais conservez le test de restauration complet.

Une restauration envoie des emails réels. Isolez le réseau ou remplacez les variables de messagerie avant tout démarrage de l’environnement restauré.

FAQ

Un snapshot de VPS suffit-il ?

Il peut compléter la stratégie, mais il ne remplace pas forcément un export de base, des copies hors machine et un test de restauration. Vérifiez ce qu’il couvre réellement et sa durée de conservation.

À quelle fréquence sauvegarder ?

Selon la perte de données acceptable et le rythme de modification. Définissez cet objectif avec le propriétaire métier, puis mesurez si l’automatisation le respecte.

Faut-il sauvegarder les secrets ?

Il faut surtout prévoir comment récupérer les secrets nécessaires sans les exposer dans une archive banale. Utilisez un gestionnaire ou une procédure séparée avec accès restreint.

Comment savoir qu’une sauvegarde est bonne ?

La preuve la plus forte est une restauration réussie dans un environnement isolé, complétée par des contrôles d’intégrité et d’alerte.

Peut-on automatiser avec un cron ?

Oui si le job est surveillé, protégé et testable. Le planificateur est moins important que les droits, la destination, l’alerte et la restauration.

Conclusion

Une sauvegarde automatique utile est séparée de la production, protégée, observable et restaurée régulièrement. Pour un projet web, commencez par l’inventaire des données et le test de reprise ; l’automatisation vient ensuite pour rendre cette discipline régulière.

Sources et limites

Sources primaires : CISA — Data Backup Options, OWASP Backup and Recovery et NIST SP 800-34. Les exigences de conservation et de chiffrement dépendent de vos données et de votre juridiction. Ce guide ne remplace pas un plan de continuité ou une obligation réglementaire.