Sauvegardes
Sauvegardes : stratégie complète
RAID contre sauvegarde, SSD en miroir, snapshots, sauvegarde locale sur NAS et hors site chiffrée, règle 3-2-1, périmètre sauvegardé, RPO/RTO, tests de restauration et plan de reprise.
Hypothèse#sauvegarde#securite#rgpd#linuxPublié le 16 sept. 2026Mis à jour le 16 sept. 2026Vérifié le 16 sept. 2026À revérifier le 15 déc. 2026
L'essentiel
- Le RAID protège contre la panne d'un disque ; il ne protège ni contre l'erreur humaine, ni contre le ransomware, ni contre le vol. Il ne remplace pas une sauvegarde.
- Stratégie 3-2-1 : SSD en miroir + snapshots locaux ; sauvegarde quotidienne chiffrée sur le NAS du cabinet ; sauvegarde quotidienne chiffrée hors site (restic ou BorgBackup, dépôt chiffré côté client).
- On sauvegarde les documents (si la Box en est la source), la configuration, la base d'utilisateurs et de permissions, l'historique des conversations, les journaux d'audit, et la base vectorielle si sa réindexation dépasse le RTO. On ne sauvegarde pas les modèles : ils se retéléchargent.
- Cibles proposées (hypothèses) : RPO 24 h, RTO 1 jour ouvré pour une reprise sur machine de remplacement, 4 h pour une restauration de fichiers.
- Un test de restauration mensuel et un test de reprise complète annuel : sans eux, la stratégie n'existe pas.
RAID n'est pas une sauvegarde
| Événement | Miroir de SSD | Snapshot local | Sauvegarde NAS | Sauvegarde hors site |
|---|---|---|---|---|
| Panne d'un SSD | Protège | Non | Protège (après restauration) | Protège |
| Suppression accidentelle d'un dossier | Non (répliquée) | Protège | Protège | Protège |
| Ransomware sur la Box | Non | Partiel (snapshots en lecture seule, sauf root compromis) | Partiel (si le dépôt est en ajout seul) | Protège si dépôt en ajout seul ou rétention |
| Vol ou incendie | Non | Non | Non (même local) | Protège |
| Corruption logicielle de la base | Non | Protège (retour arrière) | Protège | Protège |
| Erreur de mise à jour | Non | Protège | Protège | Protège |
SSD en miroir
La machine candidate dispose de deux emplacements M.2 (donnée constructeur, voir la fiche machine). La question ouverte q-006 porte sur l'opportunité d'un miroir.
| Option | Avantages | Limites | Statut |
|---|---|---|---|
| mdadm RAID 1 + LUKS + ext4/xfs | Mature, indépendant du système de fichiers, reconstruction connue | Pas de détection de corruption silencieuse ; pas de snapshots natifs | Candidat |
| Btrfs RAID 1 (sur deux volumes LUKS) | Sommes de contrôle, auto-réparation depuis la bonne copie, snapshots natifs, intégré au noyau. Btrfs déconseille RAID 5/6 en production, mais RAID 1 n'est pas concerné 3 | Outils de reconstruction moins habituels pour un intégrateur généraliste ; performances en écriture aléatoire des bases à mesurer | Candidat préféré (hypothèse) |
| ZFS miroir | Sommes de contrôle, snapshots, envoi incrémental (zfs send) | Module hors arbre sur la plupart des distributions (licence CDDL) : interaction avec Secure Boot et les mises à jour du noyau ; mémoire | Écarté en V1 sauf si la distribution retenue l'intègre |
| Pas de miroir, SSD unique + sauvegardes | Simple, moins cher | Une panne de SSD = indisponibilité jusqu'au remplacement et restauration (RTO 1 jour au mieux) | Repli |
Points communs : le miroir n'aide pas si les deux SSD sont du même lot et meurent ensemble (préférer deux références ou deux lots) ; la surveillance SMART et une alerte sur disque dégradé sont indispensables ; le remplacement à chaud n'existe pas sur cette machine : une intervention physique est nécessaire.
Snapshots
Avec Btrfs (ou ZFS), un snapshot horaire des volumes de données et un snapshot avant chaque mise à jour donnent un retour arrière rapide. Rétention proposée : 24 horaires, 7 quotidiens, 4 hebdomadaires. Les snapshots sont en lecture seule ; ils ne protègent pas contre un attaquant root sur la machine ni contre la panne du disque : ce sont des points de restauration rapides, pas des sauvegardes.
Sauvegarde locale sur NAS
Le cabinet possède souvent un NAS. La Box y écrit chaque nuit un dépôt restic ou Borg chiffré, avec un compte dédié en écriture seule sur un partage réservé (le compte de lecture des documents et le compte de sauvegarde sont distincts). Si le NAS le permet, le partage de sauvegarde a ses propres snapshots ou un mode « ajout seul » pour résister à un ransomware sur la Box.
Sauvegarde hors site chiffrée
Outils
| Outil | Chiffrement | Déduplication | Backends | Licence | Source |
|---|---|---|---|---|---|
| restic | Chiffrement et intégrité côté client (« cryptography to guarantee confidentiality and integrity ») | Oui | Local, SFTP, REST server, S3, Azure, GCS, B2, rclone | BSD 2-Clause | 1 |
| BorgBackup | Chiffrement authentifié, adapté aux cibles « pas totalement de confiance » | Oui | Local, SSH (serveur Borg) | BSD 3-Clause ; version stable 1.4.5 au 19 juillet 2026 | 2 |
| Kopia | Chiffrement côté client | Oui | Nombreux backends cloud | Apache 2.0 (à sourcer) | Non consulté |
Proposition : restic pour sa souplesse de backends (S3 ou REST server) ; BorgBackup si le dépôt hors site est un serveur SSH du prestataire. Dans les deux cas, le mot de passe ou la clé du dépôt est généré et détenu par le client (enveloppe scellée), pas par le prestataire.
Où héberger le dépôt hors site ?
| Option | Avantages | Implications RGPD et secret professionnel | Statut |
|---|---|---|---|
| Serveur du prestataire (Borg via SSH ou restic REST server) | Maîtrise, coût faible, ajout seul possible | Le prestataire devient hébergeur de données chiffrées : sous-traitance à mentionner au contrat ; il ne peut pas lire sans la clé mais détient la disponibilité ; localisation France à garantir | Candidat |
| Stockage objet chez un hébergeur français (S3 compatible) | Disponibilité, versionnage/verrouillage d'objets contre l'écrasement | Sous-traitant ultérieur à autoriser par le client (art. 28.2) ; données chiffrées côté client ; contrat et localisation UE ; vérifier la qualification (SecNumCloud si le client l'exige) | Candidat |
| Hyperscaler non européen | Disponibilité | Transfert vers un pays tiers même si chiffré : exposition juridique (lois extraterritoriales) ; incompatible avec la position du CNB sur la souveraineté | Écarté |
| Disque externe chiffré déplacé par le client | Aucun tiers | Discipline humaine ; le client oublie ; rotation de deux disques | Complément possible, pas la solution principale |
Le chiffrement côté client avec clé détenue par le cabinet fait du dépôt hors site un ensemble de données illisibles pour l'hébergeur ; cela réduit le risque mais ne supprime pas la qualification de sous-traitance ni l'obligation d'un contrat (voir RGPD) 6.
Ce que l'on sauvegarde
| Donnée | Sauvegarder ? | Fréquence | Commentaire |
|---|---|---|---|
| Documents sources | Oui si la Box est la source ; sinon le NAS est la source et a sa propre sauvegarde | Quotidien | Vérifier qui est « maître » de chaque dossier |
| Base vectorielle (chunks, embeddings) | Oui, pour tenir le RTO ; sinon réindexer | Quotidien | La réindexation complète peut prendre des heures selon le volume (à mesurer) ; les chunks contiennent du texte en clair : même niveau de protection |
| Base de l'interface (utilisateurs, groupes, permissions, conversations) | Oui | Quotidien, avec dump cohérent de la base | Sans elle, les permissions sont perdues : critique |
| Configuration (Compose, reverse proxy, pare-feu, scripts, secrets chiffrés) | Oui | À chaque changement (dépôt Git) + quotidien | Permet de reconstruire la Box |
| Journaux d'audit et d'accès | Oui | Quotidien, en ajout seul | Preuve en cas d'incident ; hors de portée du prestataire |
| Modèles (GGUF) | Non | — | Retéléchargeables ; conserver la liste et les sommes de contrôle ; prévoir le temps de téléchargement dans le RTO (dizaines de Go) |
| Système d'exploitation | Non (image de référence et procédure d'installation) | — | Réinstallation reproductible plutôt que sauvegarde d'image |
| Snapshots | Non (ils sont locaux par nature) | — |
Cibles RPO / RTO
| Situation | RPO cible | RTO cible | Statut |
|---|---|---|---|
| Fichier ou dossier supprimé par erreur | 1 h (snapshot) | 1 h | Hypothèse |
| Panne d'un SSD (miroir) | 0 | 0 (dégradé) puis remplacement sous 5 jours | Hypothèse |
| Corruption logicielle après mise à jour | 1 h (snapshot) | 2 h | Hypothèse |
| Perte complète de la Box (vol, incendie, panne totale) | 24 h | 1 jour ouvré si machine de remplacement disponible ; sinon délai d'approvisionnement (la machine candidate a connu des ruptures de stock) | Hypothèse ; dépendance forte au stock |
| Ransomware | 24 h | 1 à 2 jours ouvrés | Hypothèse |
Ces cibles sont à valider avec le client ; un cabinet peut travailler quelques jours sans l'IA, pas sans ses documents : d'où l'importance de savoir qui est la source des documents.
Tests de restauration
| Test | Fréquence | Procédure | Critère |
|---|---|---|---|
| Restauration d'un fichier depuis le dépôt hors site | Mensuel | Choisir un document au hasard, le restaurer dans un répertoire temporaire, comparer la somme de contrôle | Identique, en moins de 30 min |
| Restauration de la base de l'interface | Trimestriel | Restaurer sur la machine de laboratoire, vérifier les comptes et permissions | Permissions identiques |
| Reprise complète | Annuel | Sur une machine vierge : installation depuis l'image, restauration de tout, réindexation si besoin, tests utilisateurs | Sous le RTO ; rapport écrit |
| Vérification d'intégrité du dépôt | Mensuel, automatique | restic check ou borg check ; alerte en cas d'erreur | Aucune erreur |
| Sauvegarde effectuée | Quotidien, automatique | Alerte si la sauvegarde de la nuit est absente ou en erreur (voir Monitoring) | Alerte reçue en cas de test volontaire |
Plan de reprise
- Qualifier la perte (fichier, base, disque, machine) et choisir le point de restauration (avant l'incident).
- Se procurer la machine de remplacement (stock prestataire ou commande) et les clés (enveloppe scellée : clé de récupération LUKS, clé du dépôt).
- Installer depuis l'image de référence ; appliquer la configuration versionnée.
- Restaurer la base de l'interface, la configuration, les journaux, puis la base vectorielle ou lancer la réindexation.
- Retélécharger les modèles ; vérifier les sommes de contrôle.
- Tests : connexion de trois utilisateurs, permissions par échantillon, une question par dossier, sauvegarde de la nuit suivante fonctionnelle.
- Compte rendu et mise à jour des RTO mesurés.
Récapitulatif
| Couche | Outil proposé | Fréquence | Rétention | Protège contre |
|---|---|---|---|---|
| Miroir SSD | Btrfs RAID 1 (ou mdadm) | Continu | — | Panne d'un disque |
| Snapshots | Btrfs | Horaire + avant mise à jour | 24 h / 7 j / 4 sem | Erreur, corruption, mauvaise mise à jour |
| Sauvegarde locale | restic ou Borg vers NAS | Quotidien | 30 jours | Panne totale de la Box, erreur |
| Sauvegarde hors site | restic ou Borg, dépôt chiffré, hébergement FR | Quotidien | 90 jours + 12 mensuels (hypothèse, à aligner sur les durées de conservation) | Vol, incendie, ransomware |
| Tests | Manuel + automatique | Mensuel / annuel | Rapports conservés | Sauvegarde illusoire |
Questions ouvertes
Ce qu'il reste à tester
- Exercice d'incident : ransomware sur un poste du cabinetUn ransomware exécuté sur un poste utilisateur ayant accès au partage documentaire ne peut ni chiffrer les données de la Box (montage en lecture seule), ni altérer les sauvegardes (dépôt en ajout seul ou hors de portée), et la procédure d'incident permet une reprise sous 2 jours ouvrés avec une notification CNIL préparée dans les 72 heures.À tester
- Test de restauration complète sur machine viergeUne Box complète (système, configuration, base d'utilisateurs et permissions, index, journaux) peut être reconstruite sur une machine vierge en moins d'un jour ouvré à partir de la sauvegarde hors site chiffrée et des clés sous séquestre, sans intervention sur la Box d'origine.À tester
- Valider l'installation reproductibleUne personne compétente en administration Linux mais sans connaissance préalable du projet réinstalle la Box en moins d'une demi-journée à partir de la page Installation et du dépôt de configuration, et obtient le même résultat à la checklist de validation que l'installation initiale.À tester
Sources
- 1restic — dépôt officielGitHubFiabilité hauteProjet restic · publié 2026 · consulté le 16 sept. 2026 · fiche source
- 2BorgBackup — documentation officielleDocumentation officielleFiabilité hauteProjet BorgBackup · publié 2026-07-19 · consulté le 16 sept. 2026 · fiche source
- 3Btrfs — mkfs.btrfs(8), profils RAIDDocumentation officielleFiabilité hauteProjet Btrfs · publié 2026 · consulté le 16 sept. 2026 · fiche source
- 4ANSSI — Guide d'hygiène informatique (42 mesures)Documentation officielleFiabilité hauteANSSI · publié Non daté (page maintenue) · consulté le 16 sept. 2026 · fiche source
- 5CNIL — Guide de la sécurité des données personnelles, édition 2024Documentation officielleFiabilité hauteCNIL · publié 26 mars 2024 (PDF mis à jour 2026-05, contenu non vérifié) · consulté le 16 sept. 2026 · fiche source
- 6CNIL — Sécurité : Gérer la sous-traitanceDocumentation officielleFiabilité hauteCNIL · publié 2024 · consulté le 16 sept. 2026 · fiche source