Passer au contenu principal

Sauvegarder & restaurer les données (SaaS / On‑prem)

Référentiel des sauvegardes et de la restauration pour la suite Hamilton Apps. Cette fiche précise la politique en SaaS (fréquence, rétention, supervision), les responsabilités On‑prem, et la procédure de demande de restauration.

Mis à jour il y a plus de 2 mois

1) Politique de sauvegarde — Offre SaaS

  • Données applicatives : sauvegarde quotidienne avec rétention 2 semaines.

  • Serveurs virtuels (VM) : sauvegarde quotidienne avec rétention 2 semaines.

  • Duplication & supervision : toutes les sauvegardes sont dupliquées dans un local sécurisé (chez l’hébergeur) et supervisées pour détection immédiate d’anomalies.

  • Restauration & PRA : les restaurations sont opérées dans le cadre du PRA, selon le SLA associé à l’offre SaaS.

Remarque : les environnements de production client ne sont pas hébergés dans les locaux d’Hamilton Apps (hébergement datacenter partenaire).


2) Portée & principes

  • Cible : bases de données applicatives et images VM de l’environnement SaaS.

  • Chiffrement & sécurité : sauvegardes stockées en environnements durcis, accès restreints et tracés.

  • Conservation : au‑delà de la rétention opérationnelle, les copies sont purgées conformément aux politiques en vigueur.


3) Demander une restauration (SaaS)

Quand l’utiliser ? perte de données applicatives, erreur de manipulation, rollback après incident.

Informations à fournir dans le ticket

  1. Environnement concerné (client/tenant, production ou recette).

  2. Périmètre (produit : Visitor / Meeting / Deskbooking, site si applicable).

  3. Fenêtre cible (date/heure du point de restauration dans la fenêtre de 14 jours).

  4. Contexte (incident, lot d’import, changement), urgence et impact.

  5. Validation d’interruption éventuelle (action planifiée hors‑heures si requis).

Étapes (côté Support/Hébergement)

  • Analyse de faisabilité → plan de restauration → exécution dans la fenêtre convenue → vérifications post‑reprise (accès, intégrité, envois mails/SMS, intégrations Graph/contrôle d’accès).

  • Transmission d’un compte‑rendu avec horodatage et périmètre restauré.

Pour ouvrir un ticket : utiliser le portail Support décrit dans l’article « Contacter le support ».


4) Bonnes pratiques — Client On‑prem

  • Responsabilité : le client est responsable de la mise en œuvre et du maintien de sa politique de sauvegarde/restauration.

  • Plan de sauvegarde recommandé :

    • Sauvegardes SQL régulières (stratégie adaptée RPO/RTO), stockage chiffré et hors‑site.

    • Sauvegarde de l’application et des fichiers associés.

    • Tests de restauration périodiques et documentés.

  • Procédures : documenter rôles, fenêtres, jeux de sauvegarde, et validation en recette avant production.


5) RPO/RTO — méthode de cadrage

  • RPO : perte de données admissible (ex. 24h ↔ sauvegarde quotidienne).

  • RTO : délai de reprise visé (dépend des scénarios PRA et des fenêtres d’intervention).

  • Aligner fréquence de sauvegarde, redondance et procédures avec les objectifs fixés.


6) Checklist avant Go‑Live

  • Politique SaaS/On‑prem validée (fréquence, rétention, stockage).

  • Jeux de sauvegarde réalisés & test de restauration réussi.

  • RPO/RTO définis et approuvés par la MOA.

  • Procédure de demande de restauration rédigée (canal Support, informations requises).

  • Journalisation & traçabilité activées (preuves d’accountability).


Pré‑requis

  • SaaS : disposer des droits pour ouvrir un ticket et valider une fenêtre d’intervention.

  • On‑prem : SQL Server supporté, stockage de sauvegarde sécurisé/chiffré, accès sortants si intégrations (SMTP, Microsoft Graph, SMS), procédures PRA locales.


Liens croisés

  • Disponibilité & continuité → PRA/PCA, supervision, modes dégradés.

  • Conformité & sécurité → politiques de sauvegarde, durcissement, supervision.

  • RGPD / DPAsort des données et purge, preuves d’audit.

  • Déploiement On‑premisePré‑requis & compatibilité, Procédure d’installation.

Avez-vous trouvé la réponse à votre question ?