Guide · Stratégie de sauvegarde

Établir un plan de sauvegarde : ce qu'il doit contenir

En bref : un plan de sauvegarde fixe par écrit ce qui est sauvegardé, à quelle fréquence, où et pour combien de temps, et qui fait quoi en cas d'urgence. Il transforme des tâches de sauvegarde isolées en une stratégie vérifiable : par votre propre service informatique, par les auditeurs et par l'assureur cyber.

Pourquoi un plan de sauvegarde ?

Sans plan, les sauvegardes grandissent au rythme de l'informatique : ici une tâche pour le nouveau serveur, là un disque USB pour la comptabilité. Que tout soit couvert et que la restauration réussisse dans le délai nécessaire, personne ne le sait alors avec certitude. Le plan oblige à répondre une fois à ces questions de manière complète et consigne les réponses pour qu'elles ne dépendent pas d'une seule personne.

C'est aussi une attente venue de l'extérieur. Le RGPD exige à l'article 32 la capacité de rétablir rapidement les données personnelles après un incident et la vérification régulière des mesures (Sauvegarde et RGPD). NIS2 cite expressément la gestion des sauvegardes parmi les obligations des entités concernées (NIS2 et sauvegarde). Dans l'IT-Grundschutz de l'Office fédéral allemand de la sécurité des technologies de l'information (BSI), le sujet a son propre module, CON.3 « Concept de sauvegarde ». Et les assureurs cyber demandent souvent comment les sauvegardes sont réalisées avant même de signer le contrat.

Les neuf composantes

Un plan complet répond à neuf questions. Pour une petite entreprise, quelques pages suffisent souvent.

ComposanteQuestion cléRésultat
InventaireQuels systèmes, données et services cloud existent, et où se trouvent-ils ?Liste de tous les systèmes avec volume de données et responsable
Objectifs de restaurationQuelle perte de données et quelle interruption sont tolérables pour chaque système ?RPO et RTO par classe de systèmes
ProcédéVolumes entiers, fichiers isolés ou la machine virtuelle complète ? Comment les bases de données restent-elles cohérentes ?Type de sauvegarde et planification par système
EmplacementsCombien de copies, sur quels supports, lesquelles hors site, lesquelles immuables ?Destinations selon la règle 3-2-1
ConservationCombien de temps les versions quotidiennes, hebdomadaires et mensuelles sont-elles conservées ?Schéma de générations et règles d'effacement
ProtectionQui peut lire, modifier et supprimer les sauvegardes ? Où se trouve la clé ?Droits, chiffrement, conservation de la clé
ResponsabilitésQui lit les alertes, qui assure la suppléance, qui décide en cas d'urgence ?Rôles, suppléances, ordre de restauration
TestsÀ quelle fréquence et avec quelle profondeur la restauration est-elle testée ?Plan de tests avec résultats documentés
Preuves et mise à jourComment prouver ce qui s'est passé, et quand le plan est-il revu ?Journaux, rapports, date de révision fixe

RPO et RTO : les deux chiffres les plus importants

L'objectif de point de reprise (RPO) indique combien de travail peut être perdu au maximum : avec une sauvegarde quotidienne à 3 h du matin, jusqu'à une journée. L'objectif de délai de reprise (RTO) indique combien de temps un système peut être indisponible au maximum avant de fonctionner de nouveau. Aucun de ces deux chiffres n'est fixé par l'informatique seule, mais par la direction avec les services métier : combien coûte une journée sans le système de gestion des stocks, combien une matinée perdue en comptabilité ?

Classe de systèmesExemplesRPORTO
CritiqueGestion des stocks, ERP, bases de donnéesquelques heuresmoins d'un jour
ImportantServeur de fichiers, messagerieun jourun à deux jours
D'appuiOrdinateurs portables, systèmes de testd'un jour à une semaineplusieurs jours

Ces valeurs sont des exemples. L'essentiel est qu'elles soient fixées sciemment et confirmées par des tests : un RTO de quatre heures ne vaut rien si, lors du test, la restauration du serveur de bases de données prend six heures.

Emplacements et conservation

Pour les emplacements, la règle 3-2-1, que recommande aussi le BSI, a fait ses preuves : trois copies sur deux supports différents, dont une hors de l'entreprise. Contre les rançongiciels s'ajoutent une copie immuable ou déconnectée et des tests réguliers : la règle 3-2-1-1-0.

La conservation suit généralement un schéma de générations : versions quotidiennes pendant quelques semaines, hebdomadaires pendant quelques mois et mensuelles pendant un an ou plus. De nombreuses versions anciennes aident lorsqu'une attaque ou une erreur est découverte tardivement. Le RGPD fixe une limite supérieure : les sauvegardes contenant des données personnelles ne doivent pas être conservées plus longtemps que nécessaire et doivent ensuite expirer automatiquement.

Une sauvegarde n'est pas un archivage : les obligations légales de conservation fiscales et commerciales (en Allemagne, en général huit ans pour les pièces comptables et dix ans pour les livres et les comptes annuels) se remplissent avec un archivage conforme, pas avec les sauvegardes. Les sauvegardes servent à restaurer et expirent à la fin de leur durée.

Clés, droits et responsabilités

Une sauvegarde chiffrée ne vaut que par la conservation de sa clé. Si la clé ne se trouve que sur le serveur qui tombe en panne, la sauvegarde est perdue avec lui. Le plan fixe où la clé est conservée, par exemple dans une enveloppe d'urgence scellée au coffre-fort et en copie dans un second lieu, et qui y a accès.

Les droits sont tout aussi importants : les systèmes protégés ne devraient pas pouvoir supprimer leurs propres sauvegardes, sinon un attaquant disposant de leurs droits le pourrait aussi. Et il doit être clair qui lit les alertes d'erreur, qui assure la suppléance pendant les congés et qui décide en cas d'urgence. L'ordre de restauration (d'abord le réseau et le service d'annuaire, puis les bases de données, ensuite les applications métier) figure dans le manuel d'urgence avec les interlocuteurs.

Tests et preuves

Un plan jamais testé n'est qu'une hypothèse. Des tests de restauration réguliers confirment le RPO et le RTO et révèlent les lacunes, comme un nouveau volume qui n'a jamais été inclus dans la sauvegarde. Chaque sauvegarde, chaque test et chaque effacement devrait être consigné de façon traçable : c'est la preuve face aux auditeurs, aux assureurs et à votre propre direction.

Revoyez le plan au moins une fois par an et à chaque changement important : un nouveau site, une nouvelle application métier, le passage de services vers le cloud ou un changement dans l'équipe informatique.

Liste de contrôle

  • Tous les systèmes, ensembles de données et services cloud comme Microsoft 365 sont recensés, chacun avec un responsable.
  • Le RPO et le RTO de chaque système sont fixés avec la direction.
  • Le type de sauvegarde et la planification sont fixés pour chaque système ; les bases de données sont sauvegardées de manière cohérente.
  • Il existe au moins trois copies sur deux supports, dont une hors site et une immuable ou déconnectée.
  • La conservation est fixée par générations et les sauvegardes expirées sont effacées automatiquement.
  • Les sauvegardes sont chiffrées ; la clé est conservée séparément et accessible en cas d'urgence.
  • Les systèmes protégés ne peuvent pas supprimer leurs sauvegardes.
  • La responsabilité et la suppléance pour les alertes et les urgences sont réglées.
  • L'ordre de restauration figure dans le manuel d'urgence.
  • La restauration est testée régulièrement et les résultats sont documentés.
  • La prochaine date de révision du plan est inscrite au calendrier.

Comment AegisGrid met le plan en pratique

Avec AegisGrid, le plan devient une configuration. Une exécution écrit vers jusqu'à huit destinations : disque local, NAS, votre propre serveur de sauvegarde, un second site ou le stockage cloud. Les planifications tiennent compte des jours fériés de chaque Land allemand et rattrapent les exécutions manquées ; la conservation s'applique par destination, y compris par générations. Les données sont chiffrées sur le système protégé et la clé reste entre vos mains. Sur un stockage WORM du serveur de sauvegarde, chaque sauvegarde est verrouillée contre la modification et la suppression jusqu'à l'expiration de son verrou, y compris vis-à-vis des appareils protégés.

Le serveur de sauvegarde signale les sauvegardes manquantes, restaure régulièrement des sauvegardes à titre d'essai et tient un journal de preuves signé, dont il tire chaque mois un rapport de preuves au format PDF : la preuve que le plan est réellement respecté. Si vous préférez ne pas vous charger vous-même de l'exploitation, vous pouvez la confier à notre sauvegarde gérée.

Questions fréquentes sur le plan de sauvegarde

Un plan de sauvegarde est-il obligatoire ?

Pour la plupart des entreprises, aucune loi n'exige un document portant ce nom. Le RGPD exige toutefois des mesures techniques et organisationnelles appropriées et leur vérification régulière, et NIS2 exige des entités concernées une gestion des sauvegardes. Un plan écrit est le moyen le plus simple de prouver les deux.

Quelle longueur doit avoir le plan ?

Pour une petite entreprise, quelques pages suffisent souvent : la liste des systèmes avec RPO et RTO, les emplacements, la conservation, les responsabilités et le plan de tests. Plus important que la longueur : qu'il soit à jour et qu'en cas d'urgence, une autre personne que son auteur puisse s'en servir.

Existe-t-il un modèle ?

Le module CON.3 « Concept de sauvegarde » du compendium IT-Grundschutz du BSI décrit ce qu'un plan doit contenir et convient bien comme trame. Les neuf composantes et la liste de contrôle de cet article couvrent les points essentiels.

Revoir votre plan ensemble

Nous passons en revue votre plan de sauvegarde avec vous, en anglais ou en allemand, et vous montrons comment AegisGrid le met en pratique.