Bati : sauvegardes, restauration et PRA (guide opérationnel 2026)

Bati : sauvegardes, restauration et PRA (guide opérationnel 2026)

Quand votre logiciel métier Bati devient indisponible (incident, erreur de manipulation, corruption de base, problème d’hébergement), le vrai sujet n’est pas seulement de faire des sauvegardes : c’est de repartir vite et sans perdre trop de données.

Ce guide vous aide à cadrer une stratégie réaliste : quoi sauvegarder, à quel rythme, combien de temps garder, comment chiffrer, et surtout comment vérifier que la restauration fonctionne réellement.

Si vous voulez une base d’hébergement simple (HTTPS, instances isolées, backups automatiques, scaling CPU/RAM) : vous pouvez déployer Bati en 1 clic sur adgents.cloud.

1) La base : définir RPO et RTO (avant de parler outils)

Un plan de reprise d’activité commence par deux chiffres, décidés côté métier :

• RPO : combien de données vous acceptez de perdre (ex : “au maximum 1 heure de saisie”).
• RTO : combien de temps vous acceptez d’être à l’arrêt (ex : “le service doit revenir en moins de 2 heures”).

Ces deux objectifs déterminent mécaniquement :

• la fréquence des sauvegardes ;
• le type de sauvegarde (fichiers, base, snapshots) ;
• la façon de restaurer (automatisée ou manuelle) ;
• la nécessité (ou non) d’un environnement prêt à démarrer.

Pour poser un cadre d’hébergement fiable (reverse proxy, persistance, bonnes pratiques), gardez ce socle : Bati : déployer sur adgents.cloud (HTTPS, sauvegardes, perf) — guide 2026.

2) Quoi sauvegarder pour Bati (et ce qu’on oublie souvent)

Sur un logiciel métier, les sauvegardes “efficaces” couvrent généralement :

1. La base de données

• chantiers, devis, factures, historiques, utilisateurs, paramétrage, journaux applicatifs.

1. Les fichiers

• documents joints (PDF, photos, plans), exports, médias.

1. La configuration

• variables d’environnement, secrets, paramètres du proxy, règles réseau.

1. Les dépendances externes

• SMTP, stockage, API tierces : conservez au minimum les accès et la procédure de remise en route.

Si votre Bati est exposé à des risques d’accès (comptes, rôles, 2FA, restrictions IP), complétez avec : Bati : sécuriser l’accès (SSO, 2FA, rôles) + bonnes pratiques.

3) Stratégie simple qui marche : 3 copies, 2 supports, 1 hors site

Une approche robuste consiste à viser :

• 3 copies (production + deux sauvegardes)
• 2 supports différents (ex : stockage principal + sauvegarde sur un autre système)
• 1 copie hors site (pour survivre à un incident majeur)

L’idée n’est pas d’acheter “le meilleur outil” : c’est d’éviter le scénario où un seul incident détruit la production et la sauvegarde (mauvaise config, suppression, compromission).

4) Fréquence et rétention : comment choisir sans surcoût inutile

Partir de vos RPO/RTO donne une méthode concrète :

• Si votre RPO est 1 heure, des sauvegardes quotidiennes ne suffisent pas.
• Si votre RTO est court, il faut une restauration rapide (et des procédures prêtes).

Un schéma de rétention raisonnable côté PME ressemble souvent à :

• plusieurs sauvegardes “courtes” (ex : dernier jour) ;
• une rétention moyenne (ex : 30 jours) ;
• quelques points de reprise long terme (ex : mensuels).

Sur adgents.cloud, vous pouvez mettre en place des sauvegardes automatisées (jusqu’à 1/h) et une rétention longue (jusqu’à 10 ans), ce qui simplifie la mise en conformité et la gestion des incidents.

5) Chiffrement, accès, immutabilité : sécuriser les sauvegardes elles-mêmes

Une sauvegarde non protégée peut devenir un point de fuite (ou une cible de ransomware). Quelques règles pragmatiques :

• Chiffrez au repos quand c’est possible.
• Limitez strictement les accès (principe du moindre privilège).
• Séparez les comptes qui administrent la prod et ceux qui gèrent la sauvegarde.
• Surveillez la taille des dumps/snapshots : une baisse brutale est souvent un signal (sauvegarde incomplète).

6) La partie la plus importante : tester la restauration (sinon ça ne sert à rien)

Une sauvegarde “réussie” n’a de valeur que si elle est restaurable. La pratique recommandée est d’exécuter des tests réguliers :

• restauration de la base sur un environnement isolé ;
• vérification d’un parcours métier (connexion, consultation, création d’un devis factice, génération d’un PDF) ;
• mesure du temps réel de reprise (pour valider le RTO).

Pour éviter de tester “sur votre prod”, créez un environnement séparé. Vous pouvez vous appuyer sur une instance dédiée sur adgents.cloud : Bati sur adgents.cloud (instance isolée, redimensionnement à la demande).

7) Procédure de reprise : qui fait quoi, dans quel ordre

En cas d’incident, le stress fait perdre du temps. Un plan de reprise efficace tient sur une page et répond à :

• Qui décide de déclencher la reprise ?
• Quel est le point de reprise choisi (date/heure) ?
• Quelles sont les étapes exactes (restaurer DB, restaurer fichiers, remettre le proxy, vérifier les accès) ?
• Comment communiquer en interne (équipe, clients) ?

Si vous avez besoin d’optimiser les temps de réponse avant même l’incident, ce guide est complémentaire : Bati : optimiser la performance (DB, cache, assets).

Lancez-vous avec Bati.

Envie de vous lancer avec Bati ? Créez votre site web en quelques clics.

Bati

La solution pour les constructeurs

Déployer Bati

Vidéo (FR) pour comprendre PRA/PCA et se lancer

Pour une explication claire (avec exemples), vous pouvez regarder : .

En résumé

Une bonne stratégie pour Bati, ce n’est pas “avoir une sauvegarde” : c’est définir RPO/RTO, automatiser, protéger les sauvegardes, puis prouver que la restauration marche avec des tests.

Si vous voulez réduire la charge d’exploitation et gagner en sérénité, adgents.cloud vous permet de déployer Bati rapidement, d’ajuster CPU/RAM, et de mettre en place des sauvegardes automatiques avec une rétention adaptée à vos besoins : déployer Bati sur adgents.cloud.