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
Environnement concerné (client/tenant, production ou recette).
Périmètre (produit : Visitor / Meeting / Deskbooking, site si applicable).
Fenêtre cible (date/heure du point de restauration dans la fenêtre de 14 jours).
Contexte (incident, lot d’import, changement), urgence et impact.
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 / DPA → sort des données et purge, preuves d’audit.
Déploiement On‑premise → Pré‑requis & compatibilité, Procédure d’installation.
