Sur Cachem, on parle régulièrement de NAS, de disques durs, de stockage Cloud et de capacité… mais aussi de performances, de RAID ou encore de prix au To. Il y a un sujet encore plus important : la sauvegarde de nos données. Le risque de perte de données est encore sous-estimé, jusqu’au jour où…

Après le World Backup Day 2026 et mon retour d’expérience de 2024, je (re)détaille aujourd’hui ma stratégie de sauvegarde en 2026 : pourquoi sauvegarder, comment la mettre en place, et surtout comment s’assurer qu’elle fonctionne le jour où vous en avez besoin.

Pourquoi sauvegarder ses données

On va se le dire franchement, nous stockons de plus en plus de choses : des photos de famille, des vidéos, des documents administratifs, des factures, des fiches de paie, des projets personnels ou encore des fichiers professionnels.

Certaines données peuvent être retrouvées, (re)téléchargées… d’autres sont tout simplement irremplaçables. Une panne de disque dur, une mauvaise manipulation ou un incident, ça n’arrive pas qu’aux autres.

Après la naissance de notre premier enfant, ma compagne avait été très claire : « tu te débrouilles comme tu veux, mais aucune photo de la petite ne doit disparaître ». Un coup de pression justifié, un ami avait récemment perdu 2 années de photos…

Contrairement à une idée reçue, le matériel ne prévient pas toujours avant de tomber en panne. Une suppression accidentelle peut être répliquée instantanément sur plusieurs appareils. Un ransomware peut chiffrer les fichiers accessibles sur le réseau, y compris des sauvegardes. Un compte Cloud compromis peut également entraîner une suppression de données.

C’est précisément pour ces raisons qu’il ne faut jamais dépendre d’un seul équipement ou d’un seul service.

Un NAS ne remplace pas une sauvegarde

Arrêtez de penser qu’en s’équipant d’un NAS avec plusieurs disques, vos données sont protégées. Le NAS permet de centraliser ses fichiers, il facilite leur partage et permet d’y accéder depuis plusieurs appareils. Il permet également une certaine continuité de service grâce à une configuration RAID.

Mais le RAID n’est pas une sauvegarde.

Il est possible de continuer à accéder aux données malgré la défaillance d’un disque (ou plusieurs selon la configuration), avec quelques limites. Mais il faut rapidement remplacer le support défaillant. Le RAID ne protège pas contre une suppression accidentelle, un vol, un incendie ou un ransomware.

Cependant, le NAS peut servir de support de sauvegarde comme nous allons le voir plus bas…

Ma stratégie sauvegarde 2026 : NAS, disque externe et Cloud

Mon organisation personnelle repose sur un NAS installé à la maison, un disque dur externe et un service Cloud.

NAS

Mon NAS principal est un Synology DS1823xs+ avec une capacité de stockage d’environ 17 To réparti sur 4 groupes de stockage (SSD et HDD).

Mon NAS a un triple rôle pour toute la famille :

• Centralisation : chaque utilisateur a ses propres fichiers ;
• Partage : chacun peut accéder en local ou à distance ;
• Sauvegarde : Active Backup for Business et Time Machine.

A noter, tout n’est pas centralisé sur le NAS. Mon iMac garde une partie de ses données en local, sauvegardées par Time Machine sur le NAS.

Je répartis les fichiers en 3 grandes catégories :

• Données importantes : Celles qu’il ne faut absolument pas perdre ;
• Données utiles : La perte est gênante mais pas dramatique ;
• Données avec peu de valeur : Je peux éventuellement les retrouver.

Cette distinction est importante et je vous recommande de la faire. Toutes les données n’ont pas besoin du même niveau de protection. Il est inutile de dépenser tout son argent pour sauvegarder des fichiers temporaires. Il faut se concentrer sur ce qui compte vraiment : les documents administratifs, les photos de famille, etc.

Personnellement, les données importantes représentent environ 900 Go. On y retrouve des documents administratifs, des copies de documents personnels et de nombreuses photos.

Snapshot (cliché)

Les NAS Synology proposent un système de snapshot sur les volumes Btrfs. Il s’agit d’une capture à un instant donné des données (une photo). Les snapshots sont rapides à se faire et la restauration est aisée. Ils permettent de revenir rapidement à un état précédent, quasiment instantanément, sans interruption de service. Je ne l’utilise que sur quelques dossiers précis, pas tout le système.

Attention, un snapshot reste sur le NAS : il protège contre une erreur de manipulation, pas contre la perte du NAS lui-même (panne, vol, incendie).

Sauvegarder son environnement Docker

Corbeille

La corbeille sur un dossier partagé permet de récupérer un fichier qui a été supprimé, un peu comme la corbeille Windows ou macOS. Je l’active sur quasiment tous les dossiers. C’est une protection facile à mettre en place et très efficace. Vous pouvez même limiter l’accès à la corbeille aux seuls administrateurs. J’ai une tâche programmée qui va vider toutes les corbeilles, mais le fichier doit être dans la corbeille depuis plus de 4 jours.

Disque dur externe : sauvegarde locale indispensable

J’utilise un disque dur externe de grande capacité, connecté au NAS par l’intermédiaire d’un dock USB.

J’utilise Hyper Backup de Synology pour cela, avec 5 versions des fichiers conservées. Je lance la sauvegarde tous les 15 jours, manuellement puisque je dois reconnecter le disque à chaque fois. Elle concerne la majorité des fichiers, mais également les paramètres du NAS, les applications, les conteneurs Docker et les sauvegardes des ordinateurs.

Une fois la sauvegarde terminée, le disque est déconnecté et rangé dans un endroit sécurisé chez moi. J’ai fait le choix d’une mallette ignifuge et étanche et j’y mets également quelques documents importants.

L’intérêt du disque externe : il permet de restaurer rapidement une grande quantité de données sans dépendre d’une connexion internet ou d’un Cloud.

Un disque externe constamment connecté au NAS reste potentiellement exposé aux mêmes incidents que le stockage principal. Le déconnecter après la sauvegarde réduit notamment le risque qu’un ransomware puisse également atteindre cette copie. Cette copie hors ligne demande un geste manuel, c’est le prix de sa protection.

Dans les commentaires de mon article de 2024, un lecteur a partagé une astuce : une prise connectée qui n’alimente le disque que la nuit de la sauvegarde, avec éjection automatique en dernière tâche. Je ne l’ai pas encore mise en place.

Cloud : une protection en dehors de la maison

Depuis plusieurs années, j’utilise Cloud Sync de Synology pour envoyer les fichiers importants vers un Cloud distant. Dans mon cas, j’utilise OneDrive avec mon abonnement Microsoft 365.

L’intérêt principal du Cloud, c’est de disposer d’une copie située en dehors de chez soi. En cas de cambriolage, d’incendie ou de destruction du matériel, les données sauvegardées à distance restent disponibles.

Attention, la synchronisation doit être finement paramétrée. Dans mon cas, la tâche est en « Transférer uniquement les modifications locales ». Cela veut dire que le NAS reste maître, une suppression ou une modification côté OneDrive ne touche pas mes fichiers en local. Je n’ai pas coché l’option « Ne pas supprimer les fichiers du dossier de destination lorsqu’ils sont supprimés du dossier source », car cela fait grossir rapidement l’espace de stockage OneDrive (pour rappel 1 To). J’ai en revanche activé la cohérence avancée de Cloud Sync. Cette dernière compare notamment l’empreinte des fichiers entre le NAS et le Cloud. Elle demande plus de ressources, mais renforce le contrôle de la synchronisation.

Cependant, tout n’est pas parfait. Un fichier supprimé ou chiffré par un ransomware sur le NAS peut l’être aussi dans OneDrive. Cloud Sync ne gère pas d’historique de versions, mais OneDrive en propose un pendant 30 jours.

Aussi, je ne confie pas mes données en clair à un Cloud public, je les chiffre avant l’envoi. Il est préférable de garder le contrôle de ses clés de chiffrement et de ne pas considérer un service Cloud comme un espace de stockage magique et infaillible.

Enfin, on peut imaginer 2 NAS installés dans des lieux différents, avec des sauvegardes croisées entre 2 membres d’une même famille ou des amis.

Stratégie 3-2-1 : la base pour protéger ses données

Pour construire une bonne stratégie de sauvegarde, on peut se baser sur la règle du 3-2-1.

Son principe est relativement simple :

• 3 copies des données : les fichiers originaux et 2 copies de sauvegarde ;
• 2 supports différents : un disque dur externe et un Cloud par exemple ;
• 1 copie hors site : une sauvegarde située dans un autre bâtiment ou chez un fournisseur Cloud.

L’objectif est de limiter les conséquences d’un incident localisé. Si le NAS tombe en panne, le disque externe permet de restaurer. Si le domicile est touché par un incendie ou un cambriolage, la copie distante reste disponible.

Chez moi, j’ai un copie sur le NAS (copie 1), une sauvegarde sur le disque dur externe hors ligne (copie 2) et OneDrive pour le hors site (copie 3). Mon disque externe est donc à la fois ma deuxième copie et ma copie hors ligne (voir ci-dessous).

Quelle protection contre quel risque ?

3-2-1-1-0 : une copie hors ligne et zéro erreur

La règle 3-2-1 est une excellente base, mais elle n’est pas suffisante. Sa version avancée, le 3-2-1-1-0, ajoute deux exigences qui s’appliquent à vos copies existantes : l’une d’elles doit être hors ligne ou immuable, donc hors de portée d’un ransomware tant qu’elle est déconnectée (chez moi, le disque externe rangé dans sa mallette) et l’ensemble doit atteindre 0 erreur lors des vérifications et des tests de restauration.

En effet, une sauvegarde peut vous sembler parfaitement opérationnelle alors qu’elle contient des fichiers corrompus, incomplets ou impossibles à restaurer.

Vérifier les sauvegardes

Il est important de s’assurer que les fichiers sauvegardés ne sont pas corrompus. Généralement, les logiciels de sauvegarde disposent de vérification d’intégrité, de contrôle des archives et de vérification des données.

Je vérifie mes sauvegardes Time Machine (menu Time Machine, touche Option enfoncée, « Vérifier les sauvegardes »). Dans Hyper Backup, l’option « Vérifier l’intégralité de la sauvegarde » contrôle la cohérence des données. Je recommande au minimum un contrôle par trimestre. Cloud Sync propose une option de cohérence avancée, elle contrôle la synchronisation, mais un test de restauration reste indispensable.

Restaurer quelques fichiers

Une vérification d’intégrité ne prouve pas que vous savez restaurer une sauvegarde. Restaurez un échantillon (quelques dossiers, des photos et documents importants) vers un autre emplacement que l’original. Ensuite, ouvrez les fichiers et vérifiez qu’ils fonctionnent correctement. Faites-le pour chaque copie (disque externe et Cloud). Vous pouvez également tester l’historique de versions côté Cloud (OneDrive en propose un).

Une fois par an ou après chaque changement important (nouveau NAS, nouveau disque…), allez jusqu’à la restauration complète.

Vérifier les sauvegardes distantes

Une copie chiffrée dans le Cloud est une bonne chose, mais elle aussi doit rester accessible et restaurable. Il faut donc vérifier qu’on a toujours les identifiants d’accès, les clés de chiffrement et la possibilité de récupérer les données. Sans la clé de chiffrement, la restauration est impossible…

Si un jour votre NAS ne démarre plus, vous n’aurez peut-être plus en tête vos mots de passe, vos clés de chiffrement ni la procédure de restauration. Conservez-les en dehors du NAS (gestionnaire de mots de passe, copie papier dans la mallette). Notez la procédure de restauration par écrit. Vérifiez qu’une personne de confiance sait où la trouver… Sur un NAS, la sauvegarde ne doit pas dépendre d’une seule personne.

Les données chiffrées par Cloud Sync ne sont pas lisibles directement dans OneDrive. Il faut l’outil Cloud Sync Decryption Tool de Synology.

Bonnes pratiques supplémentaires

Je vous recommande également d’automatiser au maximum vos sauvegardes (ce que je ne fais pas complètement). Une sauvegarde manuelle dépend de votre discipline.

Aussi, essayez de conserver plusieurs versions de vos fichiers. Un historique permet de revenir en arrière après une suppression ou plusieurs modifications.

Que ce soit pour les utilisateurs, mais aussi pour les outils de sauvegarde, utilisez un compte dédié avec un accès restreint. Par exemple, Time Machine sur mon iMac n’a accès qu’au dossier destiné à la sauvegarde et à aucun autre dossier.

Les limites de ma stratégie

Mon disque externe n’est mis à jour que tous les 15 jours. Entre 2 sauvegardes, les modifications ne sont couvertes que par OneDrive (historique limité à 30 jours). Aussi, la mallette est chez moi, comme le NAS, dans des pièces différentes… mais en cas de sinistre majeur, seul OneDrive reste. Enfin, la copie hors ligne dépend de ma discipline. C’est pour cela que j’ai un rendez-vous dans mon agenda pour la sauvegarde.

Une sauvegarde n’a de valeur que si elle fonctionne

Ma recommandation est simple, commencez par identifier les données les plus importantes, mettez en place une sauvegarde locale, ajoutez une copie distante et automatisez les opérations. Enfin, prenez le temps de vérifier régulièrement vos sauvegardes et surtout de tester leur restauration.

Il n’existe pas de solution miracle, mais il existe des méthodes éprouvées et accessibles à tous. L’essentiel est de ne pas découvrir, le jour d’une panne, que l’on n’avait pas réellement de sauvegarde.

À vous de jouer : le plan d’action en 6 points

Maintenant, c’est à vous ! Voici votre plan d’action :

• Triez vos données en 3 catégories ;
• Appliquez la règle 3-2-1 sur vos données critiques ;
• Faites en sorte qu’une de vos copies soit hors ligne ou immuable ;
• Chiffrez les copies qui quittent votre domicile ;
• Conservez vos clés, mots de passe et la procédure de restauration en dehors du NAS ;
• Planifiez un test de restauration dans votre agenda et faites-le vraiment.

La meilleure sauvegarde, c’est celle qui fonctionne le jour où vous en avez besoin.

Et vous, quand avez-vous restauré vos données pour la dernière fois ?

En partenariat avec TerraMaster Rushes vidéo, textures haute définition, caches de simulation, scènes 3D, fichiers EXR, exports successifs… Dans les métiers de l’animation, des VFX et de la postproduction, les besoins en stockage se comptent rapidement en dizaines de téraoctets. Et lorsque plusieurs artistes doivent accéder aux mêmes données, les disques externes et le stockage […]

- Contient des liens affiliés Amazon -

Au départ, mon stockage était franchement bordélique. Ma bibliothèque Plex vivotait sur un vieux Synology, avec plusieurs SSD externes branchés au Mac mini, posés là au petit bonheur, avec les films rangés à plat et chaque disque qui traînait ses propres conventions et ses trous.

Je vous en avais d'ailleurs déjà parlé, et ça marchait, mais c'était un peu le foutraque, et surtout impossible à automatiser proprement, parce qu'une chaîne d'acquisition sérieuse exige un rangement carré jusqu'au moindre fichier.

D'où la grande décision de remettre tout ça à plat. L'objectif ? Consolider la médiathèque sur du matériel récent, séparer une bonne fois deux mondes qui n'ont rien à faire ensemble, les médias d'un côté et les sauvegardes de l'autre, et déléguer le plus gros de la configuration à Claude Code, l'assistant de codage d'Anthropic, piloté à distance depuis mon Mac mini.

UGREEN m'avait proposé depuis quelque temps de tester les deux NAS de sa gamme GT, j'ai donc accepté. Puis j'ai acheté mes disques une fortune, on y reviendra. Pour Plex, mon choix s'est porté sur le plus costaud de la gamme, un DXP4800 GT quatre baies sous AMD Ryzen.

Sa vraie raison d'être, c'est le débit. Ses deux ports réseau 10 Gbit confiés à des contrôleurs Aquantia ont craché 9,30 Gbit par seconde dès le premier flux en direct, soit le maximum théorique, sans une seule retransmission. Sur ce terrain, il est clairement irréprochable.

Sous le capot, on trouve un Ryzen Embedded R2514 à quatre cœurs, 8 Go de DDR4 extensibles à 64 Go, quatre baies qui se manipulent sans outil dont deux acceptent des SSD U.2 NVMe, plus deux emplacements M.2, le tout jusqu'à 144 To. Il tourne sous UGOS Pro, un système bâti sur une base Debian très peu verrouillée, avec un vrai SSH administrateur, Docker, et une plateforme x86 ouverte où l'on peut installer à peu près tout ce qu'on veut.

Le seul vrai bémol, c'est son moteur vidéo un peu daté, qui ne tient que deux flux Plex 4K transcodés en même temps et ignore l'AV1, donc pour une grosse médiathèque partagée à plusieurs, mieux vaut lui donner des fichiers déjà au bon format, ou transcoder sur une autre machine, ce qui est mon cas avec le Mac mini. Pour le stockage, j'ai récupéré 4 disques 28 To sur Amazon , à un prix que je n'ose même pas vous donner (660 euros pièce, et au moment où j'écris cet article leurs prix ont bondi à 780 euros).

Le gros morceau, c'était la migration, faire passer 36 To et 22 000 fichiers du Synology vers ce nouveau NAS. Perso je n'ai pas fait grand-chose, Claude Code s'est occupé de tout ça en SSH, en passant par les API de Plex, Radarr et Sonarr.

Derrière Plex tourne d'ailleurs toute une chaîne, Radarr et Sonarr, Prowlarr pour les sources, une seedbox Whatbox et Seerr.

Pour l'anecdote, le plus gros problème ça a été de régler les problèmes posés par les fichiers avec des accents. Près de 17 000 fichiers (de vidéos de vacances bien sûr) au chemin accentué devenaient injouables sur l'Apple TV alors que l'iPhone les lisait sans broncher, parce que Plex sur Mac jongle entre deux façons de coder un accent en Unicode quand le partage NFS strict d'UGOS n'en accepte qu'une seule à l'octet près.

Bon, maintenant on ne va pas se mentir, il y a eu des ratés avec l'IA, comme la disparition de près de 800 fichiers effacés par un bug des scripts, sans corbeille ni snapshot, mais comme le volume tourne en Btrfs et qu'il restait de la place, Claude a gelé le volume, remonté des centaines d'états internes du système de fichiers et rapatrié plus de 98 % des fichiers. Les pertes sont au final négligeables. C'était évitable, mais je n'ai pas été assez vigilant.

Ce socle sauvegarde même le code de Selene Racer, mon jeu de course de rovers sur la Lune hébergé dans le cloud sur lequel je bosse en ce moment ( vous pouvez le tester ici , il se joue dans n'importe quel navigateur, sur ordi ou téléphone), et dont les sources atterrissent sur le NAS via Dropbox. Quant au NAS deux baies qui encaisse Time Machine, les archives et les sauvegardes, c'est son petit frère le DXP2800 GT, que je teste sur Mac4ever .

Si comme moi vous n'êtes pas super fort en code et en réseau, et que vous avez suffisamment de sauvegardes de vos données, confier votre vie numérique à une IA et à un NAS de ce type est donc tout à fait envisageable, et c'est même assez chouette à mettre en place.

Les DXP4800 GT et le DXP2800 GT sont disponibles sur Amazon, et je vous les recommande les yeux fermés.

Un conteneur qui plante, ça se relance. Une base de données corrompue ou un volume effacé par erreur, ça ne se rattrape pas sans une sauvegarde. Pourtant, j’ai constaté à plusieurs reprises que la plupart des installations de Docker, la sauvegarde se résume à « ça fonctionne… ça devrait aller ». Aujourd’hui, je vous propose un petit guide, générique, qui peut s’appliquer à de nombreuses distributions Linux (Ubuntu Server, Debian, Fedora…) mais aussi sur un NAS.

Sauvegarde Docker

Un environnement Docker se décompose en 3 éléments :

• La configuration : les fichiers docker-compose.yml et .env, il ne pèse que quelques octets ;
• Les données : ce sont les volumes et bind mounts contenant les bases de données, les fichiers envoyés, les configurations d’application générées à l’exécution ;
• Les images : elles se (re)téléchargent depuis un registre, peu d’intérêt les sauvegarder (sauf retour arrière instantané).

Il est important de ne pas confondre ces catégories. Il ne sert à rien de sauvegarder l’intégralité de /var/lib/docker. Ça prend de la place pour rien et complique la restauration.

Étape 1 : Configurations de côté

Chaque stack (ou Projet Docker) repose sur des fichiers texte : docker-compose.yml, .env et parfois un Dockerfile. Ces derniers décrivent comment tout est imbriqué. Regroupez-les dans un dossier (ex : docker-configs), avec un sous-dossier par stack. Ce dossier sera ensuite inclus dans la sauvegarde automatisée (voir ci-dessous), comme les volumes de données.

Vous pouvez également mettre en place un dossier sous Git, même un simple dépôt local. Cela permettra de garder un historique des modifications et de revenir en arrière en cas d’erreur de configuration.

L’objectif, c’est de pouvoir recréer une stack entière (projet docker) en question de minutes… Sur un NAS Synology, les fichiers de configuration sont généralement logés dans /volume1/docker

Étape 2 : Identifier les volumes

Passons aux données et plus précisément leurs volumes. Pour cela, vous pouvez taper :

docker volume ls

Pour chaque volume, il faut se poser la question : s’il disparait demain, est-ce que je perds quelque chose d’irremplaçable ? Je vous recommande les dossiers utilisateurs, les bases de données (voir ci-dessous) et la configuration de votre application. Il n’est pas nécessaire de sauvegarder un cache ou des fichiers temporaires.

Pour retrouver le chemin réel d’un volume, il faut taper :

docker volume inspect <nom_du_volume>

Recherchez Mountpoint qui devrait ressembler à cela : /var/lib/docker/volumes/monVolume

Étape 3 : Choisir un outil de sauvegarde de volumes

Pour un homelab, il existe plusieurs possibilités :

• docker-volume-backup : il s’agit d’une image docker qui monte vos volumes, les archives en .tar.gz puis envoie le résultat vers un stockage local, WebDAV, Dropbox, SFTP, S3… la référence ;
• Restic ou Kopia : outils de déduplication, de chiffrement et de gestion du versioning (plusieurs points de restauration dans le temps).

Pour démarrer, docker-volume-backup suffit largement. Relativement simple, vous y mettrez les informations de chaque projet Docker et bien sûr le Mountpoint correspondant pour vos données. Restic et Kopia demandent pas mal de configuration, mais ce dernier (Kopia) dispose d’une interface graphique embarqué, ce qui peut faciliter son utilisation.

Cas particulier

Y’a toujours une exception qui confirme la règle : la base de données en fonctionnement. Si techniquement la sauvegarde avec docker-volume-backup sera OK, la base données posera des soucis lors d’une restauration.

2 solutions sont possibles :

• Dump avant archivage : pg_dump pour PostgreSQL, mysqldump pour MySQL/MariaDB génère un fichier texte (exportation brute de son contenu et de sa structure), indépendant de l’état du volume, via cron ;
• Arrêt du conteneur : plus simple à automatiser, mais implique une coupure de service temporaire pour la sauvegarde.

Dans docker-volume-backup, tout conteneur portant l’étiquette docker-volume-backup.stop-during-backup=true sera arrêté avant le lancement de la sauvegarde, puis redémarré une fois celle-ci terminée.

A noter également que de nombreuses applications (Immich, Home Assistant, Jellyfin…) proposent des systèmes de sauvegarde internes.

Étape 4 : automatiser et stocker ailleurs

Une sauvegarde qui reste sur le même disque/SSD que les données originales n’est pas une sauvegarde ! C’est une copie qui disparait avec la panne de votre PC. Dans l’idéal, il faudra créer un tâche planifié (cron) qui déclenche le script ou le conteneur de sauvegarde à intervalle régulier (une fois par jour par exemple) vers un NAS ou un autre machine distante.

Étape 5 : tester vos sauvegardes

Une erreur fréquente consiste à penser qu’une sauvegarde fonctionne… sans jamais l’avoir testée. Une sauvegarde corrompue ou incomplète, ça arrive ne sert à rien. Prenez le temps de vérifier régulièrement vos fichiers. Ouvrez-les, restaurez-les, assurez-vous qu’ils sont exploitables.

Le seul à faire, c’est reconstruire une stack/projet sur une machine vierge ou une machine virtuelle, à partir du dossier de configuration et de l’archive du/des volumes pour les données. Si l’opération échoue, alors il est nécessaire de revoir votre procédure de sauvegarde. Planifiez ce genre de test au moins une fois tous les trimestres.

Synology et Docker

Synology utilise docker à travers l’outil maison Container Station. Ce dernier fait tourner les projets (stack) directement sur le NAS dans /volume1/docker avec un sous-dossier par projet. Généralement, on y retrouve la configuration et les données côte à côte. Il est important de noter que Container Manager ne propose aucune fonction de sauvegarde.

Pour cela, il est possible d’utiliser Hyper Backup par exemple… mais vous aurez le même souci au niveau de vos bases de données.

Les Snapshots Btrfs apporteront une réponse. En effet, si le snapshot est « quasi instantané » même pendant une écriture, cela sera comparable à une coupure de courant brutale. Heureusement, les systèmes de base de données (PostgreSQL, MySQL/MariaDB) sont conçus pour se remettre de ce genre de situation grâce à des mécanismes de récupération internes. Cependant, un snapshot n’est pas une sauvegarde propre de la base de données. Pour les données importantes, je vous recommande de créer un dump. A noter que la problématique (snapshot au niveau système de fichiers/hyperviseur) reste la même pour QNAP, Asustor, Proxmox, etc.

En synthèse

Vous l’aurez compris, la sauvegarde d’un environnement Docker n’est pas forcément complexe… mais il faut faire attention. Il y a 3 grandes familles de données à sauvegarder pour un projet Docker : la configuration, les données et l’image (optionnelle). L’outil docker-volume-backup sera idéal pour la majorité des utilisateurs. Cependant, il faudra être vigilant si votre projet contient une base de données. Aussi, regardez dans vos applications favorites s’il n’existe pas un système de sauvegarde intégré

Les utilisateurs avancés regarderont du côté des applications Restic ou Kopia.