Créer son propre système de sauvegarde – Partie 1 : la stratégie avant les scripts

• L’importance des sauvegardes est souvent sous-estimée
• Beaucoup se reposent sur une dépendance au cloud sans vraiment reconnaître leur responsabilité dans la protection des données
• S’appuyer sur de simples copies sans établir de plan de sauvegarde expose à un risque élevé
• Les méthodes de sauvegarde de disque complet ou de fichiers individuels ont chacune leurs avantages et leurs inconvénients
• Une sauvegarde fiable repose essentiellement sur l’usage de snapshots et sur la mise en place d’un stockage externe

---

L’importance des sauvegardes et la réalité du terrain

• Les sauvegardes sont un domaine que beaucoup de gens ne prennent pas vraiment au sérieux
• D’innombrables données sont perdues à cause de mauvaises méthodes ou d’erreurs de conception (par ex. RAID n’est pas une sauvegarde)
• Les données sont un actif essentiel qui doit impérativement être préservé de différentes façons

Le cloud et les idées reçues sur les sauvegardes

• Beaucoup confient toutes leurs données au cloud sans se demander comment elles sont réellement protégées
• Même les grands fournisseurs de cloud appliquent un modèle de responsabilité partagée
  • Ils sécurisent l’infrastructure, mais la protection des données reste à la charge de l’utilisateur
• L’absence de sauvegarde reste un risque fréquent dans les environnements cloud, sur serveurs privés ou avec Kubernetes

L’expérience de l’auteur en récupération de données

• L’auteur a été confronté à de nombreux cas de perte de données : incendie de datacenter, salle serveur inondée, séisme, ransomware, attaque malveillante, erreur d’administrateur, etc.
• Pour les serveurs connectés à Internet (e-commerce, messagerie, etc.), l’intégrité des données et la continuité de service sont toutes deux cruciales
• Une sauvegarde n’est pas une simple copie. Copier des fichiers de base de données en cours d’utilisation augmente fortement le risque d’une restauration impossible

Les questions essentielles pour définir une stratégie de sauvegarde

• « Quel niveau de risque suis-je prêt à accepter ? », « Quelles données doivent être protégées ? », « Quelle durée d’indisponibilité est acceptable en cas de perte de données ? », « Quel espace de stockage est disponible ? »
• Conserver les sauvegardes sur la même machine ne sert à rien si la machine tombe en panne. Une sauvegarde vers un stockage externe est plus sûre
• Il faut aussi prendre en compte des éléments concrets comme la bande passante réseau, la vitesse de restauration ou l’espace de stockage

Sauvegarde de disque complet vs sauvegarde fichier par fichier

Sauvegarde de disque complet

• Avantages
  • Restauration complète possible. Le système peut être rétabli rapidement dans son état précédent
  • Très utile en combinaison avec des systèmes de virtualisation. Proxmox, par exemple, facilite ce type de sauvegarde complète
  • Certaines solutions permettent aussi la restauration de fichiers individuels à partir d’une sauvegarde complète
• Inconvénients
  • Dans le cas des serveurs physiques, un temps d’arrêt est nécessaire
  • Forte consommation d’espace, y compris pour des données inutiles
  • Selon les caractéristiques du système de fichiers, cela peut être lent ou poser des problèmes de compatibilité

Sauvegarde fichier par fichier

• Avantages
  • Possible avec les utilitaires système de base (tar, cp, rsync, etc.)
  • Permet de sauvegarder uniquement les changements, ce qui réduit l’espace et le volume de transfert
  • Offre de la flexibilité pour la restauration individuelle, le déplacement, la compression et la déduplication
  • Peut fonctionner sans interruption du système
• Inconvénients
  • Une simple copie peut demander beaucoup d’espace de stockage
  • Sauvegarder un système de fichiers en activité sans snapshot peut entraîner des incohérences et des erreurs

Sauvegarder à l’aide de snapshots

• Lorsque la cible de sauvegarde est un système de fichiers actif, les données peuvent changer entre le « début » et la « fin » de la sauvegarde, ce qui casse la cohérence des données
• Pour des bases de données ouvertes comme MySQL ou l’historique d’un navigateur, une simple copie des fichiers peut rendre la restauration impossible
• Pour garantir une sauvegarde cohérente, il faut d’abord exploiter la fonction de snapshot du système de fichiers
• Méthodes représentatives
  • Snapshots natifs du système de fichiers (systèmes prenant en charge BTRFS ou ZFS)
  • Snapshots LVM : risque de gaspillage d’espace et possibilité d’interruption du système lors de la suppression d’un snapshot
  • DattoBD : quelques problèmes de stabilité peuvent parfois survenir, mais il peut être utilisé avec UrBackup par exemple

Méthodes de sauvegarde : Push vs Pull

• Push : la machine à sauvegarder se connecte au serveur et lui envoie les données
• Pull : un serveur de sauvegarde central se connecte à chaque serveur pour effectuer la sauvegarde
• Du point de vue de la sécurité, la méthode Pull est plus sûre, car le serveur de sauvegarde bloque les connexions entrantes externes et n’accède aux clients qu’en cas de besoin
  • Afin d’éviter la suppression des données de sauvegarde en cas d’intrusion ou de ransomware, les snapshots du serveur de sauvegarde lui-même sont également conservés séparément sur une longue durée

Principales caractéristiques du système de sauvegarde recommandé

• Restauration immédiate et traitement rapide
• Stockage sur un support externe (tout en conservant des snapshots locaux pour un rollback immédiat)
• Il est recommandé de ne pas utiliser de cloud commercial comme Google Drive ou Dropbox. Les données doivent rester sous son propre contrôle
• Gestion efficace de l’espace grâce à la compression et à la déduplication
• Le nombre de composants supplémentaires nécessaires au fonctionnement doit être minimal

Suite prévue de la série

• L’auteur prévoit de présenter différents scénarios de sauvegarde, les serveurs qu’il utilise réellement, les principaux réglages, ainsi que divers logiciels et technologies
• Le prochain article expliquera comment construire un serveur de sauvegarde basé sur FreeBSD

[GN⁺]

Commentaires Hacker News

• Pour les machines dont les sauvegardes doivent impérativement fonctionner en mode « push », il faut limiter l’accès à leur propre espace uniquement ; et surtout, le serveur de sauvegarde doit conserver pendant un certain temps ses propres snapshots du système de fichiers pour des raisons de sécurité. Ainsi, même dans le pire des cas où la charge de travail est compromise, puis accède au serveur de sauvegarde et efface les sauvegardes dans le cadre d’un rançongiciel, il reste des snapshots sur le serveur. Ma méthode préférée consiste à autoriser les clients à n’écrire que de nouvelles sauvegardes, sans jamais pouvoir supprimer quoi que ce soit ; les suppressions sont traitées par une procédure séparée (manuelle ou via cron, par exemple). Ce fonctionnement peut être mis en place avec rsync/ssh grâce à la fonctionnalité de commande autorisée dans .ssh/authorized_keys

  • J’utilise les deux approches. Il faut bien conserver les sauvegardes à deux endroits, mais c’est aussi l’architecture à double sauvegarde que je visais dès le départ. Les sources poussent leurs sauvegardes vers un emplacement intermédiaire, puis le dépôt principal vient les tirer depuis là. L’emplacement intermédiaire a une faible capacité et conserve des snapshots, mais le stockage principal et les sources ne s’authentifient jamais directement entre eux : chacun ne peut authentifier que l’emplacement intermédiaire, sans authentification réciproque. Ainsi, même si un ou deux de ces trois emplacements sont compromis, les autres ont de fortes chances de rester sûrs. Les sauvegardes de certificats sont traitées complètement à part pour qu’elles ne se retrouvent jamais toutes sur des serveurs connectés à Internet. Les données vraiment critiques sont doublées avec en plus une sauvegarde hors ligne. La séparation de l’architecture rend la validation réelle des sauvegardes un peu pénible, mais le stockage de sauvegarde vérifie périodiquement ses checksums et envoie les résultats à l’hôte intermédiaire, qui les compare aux hash générés par l’hôte source afin de détecter les corruptions. Avec ce réglage, on obtient une sorte de sauvegarde « soft offline » où la source ne peut pas directement endommager les snapshots de sauvegarde eux-mêmes

  • Une autre possibilité consiste à utiliser un conteneur séparé ou un utilisateur dédié aux sauvegardes. Avec systemd-nspawn, par exemple, on peut s’en servir comme d’une sorte de jail chroot légère, et il est possible d’y bloquer complètement l’exécution de rm. On peut créer un chroot simplement avec pacman/pacstrap, puis le gérer via systemd-nspawn/machinectl. Cette approche est flexible, car elle permet, un peu comme systemd au quotidien, de gérer le contrôle d’accès, les restrictions de chemins de fichiers, les limites mémoire/CPU, l’autorisation d’accès à certaines plages IP seulement, le détail des conditions de démarrage, etc. On peut aussi exploiter des sous-volumes BTRFS et, si nécessaire, isoler complètement le système avec systemd-vmspawn. importctl est aussi très pratique pour automatiser la réplication

  • Je préfère une approche en mode pull où « le serveur de sauvegarde n’a absolument aucun privilège sur les serveurs à sauvegarder ». Même si le serveur en production se fait compromettre son accès root, le système de sauvegarde n’est pas affecté

  • J’utilise rclone copy pour les sauvegardes, avec uniquement une clé API qui n’a pas le droit de supprimer des objets. Avec une synchronisation comme rclone sync, on risque d’effacer des choses, donc cette méthode est plus sûre

  • J’aimerais que syncoid propose aussi une option où « le client ne peut copier que les snapshots/sauvegardes et où les suppressions sont gérées directement par le serveur de sauvegarde ». Aujourd’hui, il faut donner des droits de suppression, ce qui est frustrant

• Un nombre étonnamment élevé de gens ne prennent pas les sauvegardes au sérieux, aussi bien dans les petites que dans les grandes entreprises. Même une société réalisant 1 milliard d’euros de chiffre d’affaires annuel, pour laquelle je fais du conseil, n’avait pas de vraies sauvegardes internes et dépendait uniquement de copies de disques effectuées irrégulièrement par son hébergeur de datacenter. Ils n’avaient jamais testé eux-mêmes une restauration. Il y a peu, une erreur utilisateur a complètement détruit la base de données de production, et comme la dernière sauvegarde datait de 4 jours, il a fallu reconstituer toutes les transactions intermédiaires. Pourtant, malgré cet incident, personne n’a semblé choqué et tout a repris comme si de rien n’était

  • Ils pensent sans doute que ce n’est pas grave tant que ce n’est pas réellement fatal pour l’activité

  • Rendre les exigences de sauvegarde exagérément complexes est aussi quelque chose que je vois souvent

  • C’est peut-être lié à des questions juridiques ; en cas de litige ou d’obligations légales de conservation, les sauvegardes peuvent parfois devenir un risque en elles-mêmes

  • C’est un effet pervers des politiques de reprise après sinistre validées pour les audits SOC2. Dans une entreprise où j’ai travaillé, on a examiné les politiques de reprise après sinistre de toutes les équipes — toutes approuvées SOC2 — et on est finalement arrivés à la conclusion qu’en cas de véritable incident majeur, il serait plus rapide de fermer l’entreprise et rentrer chez soi que de restaurer normalement

  • Si la perte de 4 jours complets de données en base de production est réelle, j’aimerais savoir si les clients ne se sont pas mis en colère. À cette échelle, ça semble devoir causer un impact énorme, donc je serais curieux de savoir comment ils ont géré ça en pratique

• Merci pour le partage. Cela fait 10 ans que je développe des logiciels de sauvegarde et de reprise après sinistre, et le proverbe qui revient toujours est : « je ne recommanderais jamais à un ami de construire lui-même sa solution de sauvegarde/reprise après sinistre ». Il y a énormément de pièges faciles à rater dans la mise en place d’une solution BCDR. Je voulais partager quelques points clés : une sauvegarde n’est pas une « reprise après sinistre ». Lors d’un vrai incident, il faut pouvoir restaurer immédiatement en quelques minutes ou quelques heures pour préserver la confiance dans l’activité. Le temps de reprise (RTO) et le point de reprise (RPO) sont essentiels. Une simple réplication de fichiers en mode copie rsync n’est pas une sauvegarde à un instant T, puisque le système de fichiers continue d’évoluer. Une vraie sauvegarde ponctuelle nécessite des sauvegardes « crash consistent » ou « application consistent » ; dans le second cas, les applications importantes doivent avoir écrit leur état sur disque et être mises en pause pendant la sauvegarde. Des fonctionnalités comme Microsoft VSS servent précisément à cela. Il ne faut jamais faire aveuglément confiance ni à une copie rsync, ni même à des sauvegardes crash-consistent. La loi de Murphy s’applique toujours au stockage, donc il faut impérativement des sauvegardes à plusieurs endroits (stratégie 3-2-1). D’expérience, tous les types de disques finissent par tomber en panne. Les SSD NVMe > SSD > HDD sont certes plus endurants dans cet ordre, mais aucune exception. J’aurais encore beaucoup à dire, mais il se fait tard, donc je m’arrête là

  • L’analogie 3-2-1 est une approche de l’ancien monde. Aujourd’hui, comme les emplacements de conservation sont pratiquement illimités, les snapshots locaux, la réplication distante et les sauvegardes doublées ou triplées selon différentes méthodes sont encore plus importants. J’utilise des snapshots de base avec zfs, plus Borg en complément, et avec cette combinaison on couvre à peu près n’importe quel sinistre

  • Ce proverbe m’a rappelé une phrase similaire que j’avais entendue lors d’un concert d’Alice in Chains. Une solution BCDR est un symbole de confiance entre entreprises. Ces systèmes protègent des volumes de données de l’ordre de dizaines à centaines de milliers de milliards, et si j’étais CTO, je ne confierais jamais les sauvegardes de l’entreprise à une approche open source. Les dépenses IT des entreprises augmentent généralement par paliers en fonction de la valeur des actifs et des stratégies anti-vendor lock-in. D’expérience, en matière de protection contre les rançongiciels, l’immuabilité (immutability) et les sauvegardes WORM sont essentielles, et j’ai vu de nombreux cas problématiques dans l’IT publique pour cause de non-conformité réglementaire. Les fournisseurs BCDR mettent souvent les rançongiciels en avant comme argument commercial, mais la véritable immuabilité se démontre dans la réplication des données à travers plusieurs espaces. C’est là que la stratégie 3-2-1 révèle toute sa valeur. J’aimerais bien entendre d’autres avis sur les principes de sauvegarde

  • Si vous utilisez un NAS, mieux vaut éviter d’avoir des disques durs du même fabricant et du même modèle des deux côtés

  • Je suis totalement d’accord avec « il faut absolument des sauvegardes à plusieurs endroits (3-2-1) ». Mais pour la plupart des particuliers, le « 1 » (hors site) est irréaliste en pratique, et au final il n’y a plus vraiment de raison de faire ses sauvegardes soi-même à moins d’utiliser un service de sauvegarde. Je ne connais personne autour de moi qui accepterait d’héberger et d’administrer un ordinateur allumé 24 h/24 en dehors de ma ville

  • Le passage « il ne faut jamais faire confiance à une copie rsync ou même à des sauvegardes crash-consistent » mène finalement à la conclusion que, puisque tous les systèmes/services peuvent être reconstruits via des outils d’infrastructure, il suffit de sauvegarder activement les bases de données et les stockages de fichiers/objets. Sauvegarder des VM entières de manière compliquée n’a pas vraiment de sens

• C’est un article proprement écrit, mais il manque un point : un très bon système de sauvegarde doit avoir une procédure de restauration claire et rapide. J’ai vu à plusieurs reprises des cas où tout le monde était rassuré parce que « les sauvegardes fonctionnaient bien », puis, lors de la restauration, seule une partie pouvait être récupérée, ou bien cela prenait plusieurs jours, causant des pertes énormes. L’outil restic permet des sauvegardes par snapshots avec déduplication au niveau fichier, ce qui est utile quand on n’a pas de système de fichiers à snapshots comme ZFS. Et pour les sauvegardes en mode « push », un rançongiciel peut aussi supprimer les sauvegardes ; le mode « pull » est donc préférable. Si on reste en push, mieux vaut utiliser un support en lecture seule (Blu-ray, etc.) ou au minimum disposer d’un auto-snapshot/ZFS permettant une restauration à un point dans le temps

  • Même si un rançongiciel peut supprimer des sauvegardes push, ce n’est pas un problème si les permissions du serveur sont bien limitées. Borg et Restic permettent un mode append-only via ssh, et en local je fais tourner des disques de sauvegarde hors ligne comme dernière ligne de défense. Voir la méthode concrète ici

  • Je me demande si, avec le mode append-only de restic et un pruning périodique exécuté uniquement côté serveur, on peut se passer du mode pull. Il me semble que c’est la méthode officielle recommandée par restic contre les rançongiciels

  • La « vitesse de restauration » dépend vraiment des besoins ; si la restauration de mes photos de famille prend 6 mois, ça me va très bien

  • Au lieu d’un support en lecture seule, un serveur push avec permissions limitées peut aussi faire l’affaire. Par exemple, en autorisant uniquement scp via ssh, dans un environnement chroot, avec une rotation quotidienne des dossiers de sauvegarde, même un rançongiciel ne peut pas supprimer les anciennes données. Ma procédure de sauvegarde utilise justement un serveur ssh limité à chroot + scp, en plus de supports en lecture seule

• Je n’ai pas forcément besoin d’un système de sauvegarde séparé ; il me suffirait d’une méthode standardisée pour regrouper efficacement 25 ans de photos d’une famille de 4 personnes (téléphones, appareils photo, téléchargements, scans, etc.). Jusqu’ici, je n’ai pas trouvé de solution vraiment satisfaisante

  • J’utilise Immich sur un NAS, et je sauvegarde chaque jour les médias ainsi qu’un dump de la base Immich vers AWS S3 Deep Archive. Immich couvre largement les fonctionnalités de Google Photos, et si on ajoute les photos/scans du bureau sur le NAS, Immich les importe automatiquement. Pour un utilisateur HN, la configuration n’est pas difficile

  • En plaisantant, je demanderais si « 25 ans de photos » est une unité de mesure nord-américaine, mais en réalité cela montre bien qu’un système de sauvegarde est indispensable. J’utilise syncthing en mesh sur gnu/linux/windows/android, je snapshotte régulièrement les archives sur deux VM Debian, puis je fais une sauvegarde secondaire avec borgbackup. Le RPO est de 24 heures, mais on peut le réduire si besoin. En revanche, cette configuration convient mal aux appareils Apple, car syncthing n’y fonctionne pas en arrière-plan. Dans mon cas, j’ai 500 Go de photos et encore des dizaines à centaines de Go de documents divers, mais les sauvegardes différentielles restent efficaces

  • Les téléchargements et les scans, si ce n’est pas vraiment important, sont de toute façon des données qu’on finira par jeter. Je synchronise téléphone/appareil photo avec Nextcloud, et je fais fonctionner les sauvegardes uniquement sur mon réseau domestique. Ensuite, le NAS effectue une sauvegarde quotidienne avec vérification de l’état, et la dernière étape consiste à utiliser soit une sauvegarde cloud fiable, soit un disque dans une autre maison. Comme ça, on a aussi une deuxième sauvegarde

  • Des solutions auto-hébergées comme PhotoPrism ou Immich sont utiles pour la déduplication des photos ainsi que la recherche/le tagging. Pour la sauvegarde cloud, on peut utiliser Backblaze B2 + Cryptomator avec un stockage chiffré et un script d’upload DIY, pour environ 1 dollar par To et par mois

  • J’utilise syncthing ; Android n’est pas officiellement pris en charge, mais avec une version forkée ça fonctionne bien. En complément, je recommande ente.io ou un auto-hébergement Immich pour la sauvegarde des photos. Pour les documents, mieux vaut gérer cela séparément avec quelque chose comme paperless ngx

• Dirvish est un wrapper léger autour de rsync qui mérite vraiment d’être essayé. Il offre d’excellentes fonctions de rotation, d’incrémental, de rétention, de scripts avant/après traitement, etc. Il me sauve la vie de mes données depuis plus de 20 ans. Il s’accorde d’ailleurs très bien avec les points soulevés dans l’article. Site officiel de dirvish, site officiel de rsync

  • Je serais curieux de savoir en quoi dirvish est plus simple ou meilleur que rsync seul

• J’ai aussi une méthode assez paresseuse qui couvre quand même les pannes matérielles et les vols : stockage temporaire interne sur le desktop, disque externe à la maison, disque externe hors site (tous des Samsung T7 Shield). Je fais une copie quotidienne avec robocopy /MIR du temporaire ou du travail, une sauvegarde hebdomadaire sur l’externe, puis j’échange le disque externe hors site une fois par mois

  • Les disques externes devraient impérativement venir au minimum de lots différents, ou mieux encore être de modèles différents. Quand ils sont du même modèle et du même lot, ils ont souvent une forte probabilité de tomber en panne en même temps, surtout lorsqu’on leur impose une grosse charge pendant une restauration

• Le timing est bon, donc je partage ma configuration archlinux et ma stratégie de sauvegarde : scripts d’automatisation config/sauvegarde, couche d’automatisation borg

  • J’automatise avec python + borg les snapshots de 51 block devices d’un SAN, les sauvegardes de 71 systèmes de fichiers, ainsi que la synchro S3. La restauration a été testée en conditions réelles hors site, jusqu’au démarrage des VM, et tout a fonctionné. L’automatisation reste encore complexe et inachevée, donc la restauration est lente, mais c’est une solution montée à très faible coût. Borg est vraiment puissant ; n’importe qui peut tenter ce genre de chose, et au final c’est très économique

• Mes données vraiment précieuses représentent moins de 100 MiB, donc je fais des sauvegardes deux fois par semaine en tar + compression + chiffrement sur quelques chemins sélectionnés, avec rotation sur seulement quelques mois. J’en garde des copies à l’intérieur et à l’extérieur de chez moi, et cela ne demande presque aucun contrôle ni maintenance. Quelques lignes de script sh suffisent pour automatiser tout cela sans souci

  • Si je mourais soudainement demain, il faudrait se demander quelles données vaudraient vraiment la peine d’être restaurées par ma famille et mes descendants. Plutôt que des centaines de milliers de fichiers, quelques photos, vidéos et textes vraiment essentiels suffiraient peut-être

  • Ce commentaire m’a vraiment fait réfléchir à ce qui constitue mes données les plus précieuses. Mes photos font au moins plusieurs Go même compressées, alors que mes contacts et d’autres choses moins importantes sont petits. Pour le reste, je peux globalement accepter de perdre. Il faudrait que je conserve mes clés de récupération de manière plus sûre, même si, paradoxalement, mes comptes les plus importants n’ont pas de clé de récupération. Rien que les photos approchent des 2 To (les peines du photographe amateur)

• La difficulté principale en matière de cohérence des sauvegardes, c’est qu’il est pratiquement impossible de sauvegarder des données applicatives de manière cohérente sans interruption de service. Avec un snapshot disque, on finit forcément par capturer un instant où un service est en plein milieu d’une écriture, ce qui augmente fortement le risque de restaurer un état corrompu. Les dumps de base de données atténuent en grande partie ce problème, mais ils doivent souvent être faits depuis l’extérieur du service, donc potentiellement au milieu de requêtes en cours. Si quelqu’un a de l’expérience ou des bonnes pratiques sur ce point, je suis preneur

  • En général, les bases de données sont assez robustes sur ce point, donc prendre un snapshot disque à n’importe quel moment reste suffisant pour une sauvegarde. Ce qui m’inquiéterait davantage, ce sont des situations particulières comme des caches sans batterie ; mais dans les architectures cloud modernes, ce n’est presque plus un problème

  • La stratégie dépend aussi de l’existence d’autres états applicatifs à capturer en plus de la base (par exemple, faut-il aussi sauvegarder le cache ?). pg_dump/mysqldump permettent effectivement de faire des snapshots sûrs d’une base en production, mais c’est parfois lent et cela génère de gros dumps. Pour éviter ce problème sur de grosses bases PostgreSQL, j’ai déjà utilisé une réplique en lecture seule dédiée aux sauvegardes, en arrêtant la réplication juste avant la sauvegarde puis en la relançant ensuite