Assopilot : backups & PRA (restauration, RPO/RTO, tests) — guide 2026
Un bon plan de reprise ne se limite pas à “avoir des sauvegardes” : il faut savoir jusqu’à quel point vous acceptez de perdre des données (RPO) et en combien de temps vous devez être de retour (RTO) — puis prouver que c’est faisable avec des tests.
Si vous cherchez un hébergement prêt pour la production (HTTPS, sauvegardes automatiques, scaling), commencez par Assopilot sur adgents.cloud.
1) Définir vos objectifs (RPO, RTO) en partant du métier
- RPO (Recovery Point Objective) : la perte de données maximale acceptable (ex: “on peut perdre 1h”).
- RTO (Recovery Time Objective) : le temps maximal acceptable pour remettre le service en ligne (ex: “on doit repartir en 4h”).
Pour une PME, l’erreur fréquente est de viser un RPO/RTO très ambitieux… sans mesurer le temps réel de restauration (base + fichiers + vérifications).
Pour cadrer la gouvernance et les accès pendant les opérations, vous pouvez aussi lire Assopilot : comptes, rôles et sécurité.
2) Lister ce qu’il faut réellement sauvegarder (pas seulement la base)
Pour Assopilot, on retrouve généralement 4 familles à protéger :
- Base de données (PostgreSQL/MySQL selon votre déploiement)
- Fichiers applicatifs : pièces jointes, exports, médias, répertoires “uploads”
- Configuration et secrets : variables d’environnement, clés, comptes techniques
- Éléments d’infra : reverse proxy, certificats, règles firewall, tâches planifiées
Objectif : pouvoir reconstruire un environnement propre, sans dépendre d’une personne qui “sait où c’est”.
3) Choisir une stratégie de sauvegarde qui tient vos objectifs
Une stratégie simple et robuste consiste à combiner :
- Snapshots fréquents pour réduire le RPO
- Rétention longue pour se protéger d’une corruption détectée tard
- Sauvegardes chiffrées + comptes dédiés
- Isolation des sauvegardes (pour résister à un ransomware)
Sur adgents.cloud, vous pouvez activer des backups automatiques (24h par défaut, jusqu’à 1 par heure) et ajuster la rétention selon le niveau de risque.
Vous pouvez comparer la logique avec ce qui se fait sur d’autres apps : PrestaShop : stratégie de sauvegardes + restauration (PRA) (les principes restent les mêmes : base + fichiers + test).
4) Préparer la restauration : le runbook qui vous fait gagner des heures
Le jour où ça arrive, vous voulez une procédure courte, exécutable, et reproductible. Exemple de déroulé :
- Isoler l’incident (couper accès, arrêter l’instance si besoin)
- Choisir un point de restauration (en fonction du RPO et du contexte)
- Restaurer la base
- Restaurer les fichiers (uploads, documents)
- Remettre les secrets/config puis redémarrer
- Vérifier (login, création d’un enregistrement, export, envoi email si concerné)
5) Tester : la seule façon de savoir si votre PRA marche
Un test utile n’est pas forcément long :
- Mensuel : restauration “à blanc” sur un environnement isolé, vérification fonctionnelle basique
- Trimestriel : test plus complet (plusieurs scénarios : erreur humaine, corruption, compromission)
- Après changement majeur : nouvelle version, migration de base, modification des volumes
Pendant le test, mesurez deux choses :
- temps total jusqu’à un service utilisable (votre RTO réel)
- âge réel des données restaurées (votre RPO réel)
Pour une explication claire des notions RPO/RTO côté PRA, cette vidéo est une bonne mise en contexte : 
.
Conclusion : une stratégie simple, prouvée, et compatible avec la croissance
Si vous devez prioriser :
- fixer RPO/RTO réalistes
- protéger base + fichiers + secrets
- automatiser + conserver assez longtemps
- tester et mesurer
Pour héberger Assopilot avec HTTPS, backups automatiques et possibilité d’adapter CPU/RAM quand l’activité augmente : Assopilot sur adgents.cloud.
