Snapshots ZFS, réplication et Cloud Sync

Un snapshot ZFS est une image figée d'un dataset ou d'un zvol à un instant précis, prise en une fraction de seconde et qui n'occupe au départ aucune place. La réplication envoie ces snapshots vers un autre système, de préférence sur un autre site, pour que les données survivent à la perte du NAS lui-même ; Cloud Sync en copie le contenu vers un stockage objet. Ce chapitre explique le fonctionnement et le coût des snapshots, la planification et la rétention, les quatre façons de restaurer, puis la réplication de srv-nas vers l'agence de Marseille et la copie dans le cloud.

Comment fonctionne un snapshot

Le chapitre 3 l'a montré : ZFS n'écrase jamais un bloc. Prendre un snapshot consiste seulement à garder l'arbre de blocs du moment, au lieu de libérer les blocs que les écritures suivantes remplaceront. Rien n'est copié : c'est pour cela qu'un snapshot est instantané, même sur des téraoctets.

Ensuite, à chaque modification, le dataset pointe vers les nouveaux blocs, et le snapshot continue de pointer vers les anciens. Un snapshot occupe exactement la place des blocs qui n'existent plus que dans lui : les données modifiées ou supprimées depuis sa création. Un dataset qui ne fait que grossir, comme les archives de Sorbier où l'on ajoute des PDF sans jamais les modifier, produit des snapshots qui ne coûtent presque rien. Un disque de VM très actif produit des snapshots qui grossissent vite.

Prendre et planifier des snapshots

À la main, avant une opération risquée (une migration, une mise à jour d'application) : Datasets, sélectionner le dataset, widget Data Protection, Create Snapshot. Donne-lui un nom parlant : avant-migration-2026-11-05.

Automatiquement : Data Protection > Periodic Snapshot Tasks > Add.

Le schéma par défaut est auto-%Y-%m-%d_%H-%M. Quand plusieurs tâches portent sur le même dataset avec des rétentions différentes, donne-leur des schémas différents (horaire-…, quotidien-…) : chaque tâche ne supprime que les snapshots qui suivent son schéma.

La politique de Sorbier.

Les archives gardent donc 533 snapshots en permanence. C'est sans problème pour ZFS, qui en supporte des milliers ; au-delà de quelques milliers par dataset, en revanche, l'affichage et la suppression ralentissent.

Restaurer depuis un snapshot

Les snapshots d'un dataset se gèrent dans Datasets, widget Data Protection, Manage Snapshots : la liste affiche chaque snapshot avec sa date et la place qu'il occupe, et permet de le cloner, d'y revenir ou de le supprimer.

Protéger un snapshot précis. Un snapshot peut recevoir une retenue (hold) : tant qu'elle est posée, ni la rétention automatique ni une suppression manuelle ne peuvent le détruire. On l'utilise pour garder le snapshot « avant migration » au-delà de sa durée de vie, ou un snapshot qui sert de preuve après un incident. En ligne de commande, zfs holds liste les retenues.

La réplication ZFS

La réplication envoie les snapshots d'un dataset vers un autre pool, en général sur un autre TrueNAS, avec les commandes ZFS zfs send et zfs receive. La première réplication envoie tout le contenu du snapshot ; les suivantes sont incrémentales : seuls les blocs modifiés entre le dernier snapshot commun et le nouveau voyagent sur le réseau. ZFS sait exactement quels blocs ont changé, sans parcourir les fichiers : répliquer des téraoctets peu modifiés prend quelques secondes.

La destination reçoit une copie exacte : les mêmes fichiers, les mêmes propriétés, les mêmes ACL et les mêmes snapshots (avec sa propre durée de conservation). Le dataset de destination est en lecture seule, pour que personne n'y écrive et ne casse la chaîne incrémentale.

Pousser ou tirer. Une réplication poussée (push) est lancée par la source, qui se connecte à la destination ; une réplication tirée (pull) est lancée par la destination, qui vient chercher les snapshots. Le choix n'a rien d'anodin : la machine qui lance la réplication détient les identifiants de l'autre. En réplication tirée, srv-nas n'a aucun moyen de se connecter à nas-mrs : un attaquant qui prend le contrôle de srv-nas ne peut pas effacer les copies de Marseille. C'est le choix de Sorbier (chapitre 10).

Mettre en place la réplication tirée. Toute la configuration se fait sur nas-mrs (10.30.1.163), le TrueNAS de l'agence de Marseille, qui dispose d'un pool sauvegarde.

1. Préparer les deux systèmes. Sur nas-mrs, créer le dataset parent de destination (sauvegarde). Sur srv-nas, donner un répertoire personnel au compte qui servira à la connexion, activer le service SSH (System > Services) en n'autorisant que les connexions depuis nas-mrs (pare-feu), et lui donner le droit d'exécuter les commandes ZFS.
2. Créer la connexion SSH sur nas-mrs : Credentials > Backup Credentials > SSH Connections > Add, Setup Method Semi-Automatic, TrueNAS URL https://192.168.10.183, compte et mot de passe d'administration de srv-nas, Private Key Generate New. TrueNAS échange les clés et enregistre la clé publique sur srv-nas.
3. Créer la tâche : Data Protection > Replication Tasks > Add. Écran What and Where : Source Location On a Different System, SSH Connection celle créée ci-dessus, Source tank/archives sur srv-nas, Destination sauvegarde/archives sur nas-mrs (le nom est créé en l'ajoutant au chemin), Use Sudo For ZFS Commands coché, Recursive si besoin. Laisser les snapshots suivre le schéma des tâches périodiques de la source.
4. Écran suivant : Replication Schedule Run On a Schedule, chaque nuit à 1 h ; Destination Snapshot Lifetime Custom, 2 ans (Marseille garde plus longtemps que Lyon).
5. Save, puis Run Now pour la réplication initiale. La colonne State affiche l'avancement et donne accès au journal.

Les identifiants Unix des deux côtés. Les ACL voyagent avec les données sous forme d'UID et de GID. Si nas-mrs doit un jour servir les données aux utilisateurs (après un sinistre à Lyon), il doit traduire les comptes du domaine en mêmes identifiants : même réglage IDMAP par défaut (chapitre 6). Note-le dans le plan de reprise.

Cloud Sync : une copie dans un stockage objet

Cloud Sync copie le contenu d'un dataset vers un fournisseur de stockage en ligne, ou en rapatrie un : stockage compatible S3 (OVHcloud, Scaleway, Backblaze B2, Wasabi, Amazon S3…), Azure Blob, Google Cloud Storage, et d'autres. TrueNAS s'appuie sur le logiciel libre rclone.

1. Credentials > Backup Credentials > Cloud Credentials > Add : le fournisseur, le point d'accès S3, la clé d'accès et la clé secrète d'un compte dédié, limité à son compartiment.
2. Data Protection > Cloud Sync Tasks > Add : la connexion, le compartiment et le dossier de destination, le dataset source, la planification.

Pour une sauvegarde versionnée plutôt qu'une simple copie, TrueNAS propose aussi des tâches TrueCloud Backup, qui gardent des instantanés successifs chez le fournisseur partenaire de l'éditeur.

La règle 3-2-1 chez Sorbier

La règle 3-2-1 demande trois copies des données, sur deux supports différents, dont une hors site ; on la complète aujourd'hui par une copie hors ligne ou immuable et des restaurations testées (règle 3-2-1-1-0, détaillée dans le cours Sauvegarde et PRA). Chez Sorbier, pour les archives :

Exercices

Exercice 1 sur 5 Combien coûte un snapshot ? Réussi À revoir

Le dataset tank/partages/linux contient 200 Gio. On prend un snapshot à 9 h. Entre 9 h et 18 h, les serveurs ajoutent 5 Gio de nouveaux fichiers, modifient 2 Gio de fichiers existants et suppriment 3 Gio de fichiers. Quelle place occupe le snapshot de 9 h à 18 h ? Quelle place occupe le dataset (sans le snapshot) ?

Voir la réponseMasquer la réponse de l'exercice 1

Le snapshot retient seulement les blocs qui n'existent plus dans le dataset : les anciennes versions des 2 Gio modifiés et les 3 Gio supprimés, soit environ 5 Gio. Les 5 Gio ajoutés n'existaient pas à 9 h : ils ne concernent pas le snapshot.

Le dataset contient : 200 + 5 − 3 = 202 Gio (les fichiers modifiés gardent à peu près leur taille). Au total, le pool porte donc environ 207 Gio pour ce dataset et son snapshot.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 5 La bonne restauration Réussi À revoir

Pour chaque situation, choisis la méthode de restauration la plus adaptée et justifie.

1. Un commercial a supprimé un dossier de devis dans un partage SMB ce matin.
2. Un rançongiciel a chiffré 40 000 fichiers du partage Archives entre 2 h et 3 h du matin ; rien d'autre n'a été écrit depuis.
3. Antoine veut vérifier si la VM de gestion était déjà en panne avant-hier, sans arrêter la VM de production.

Voir la réponseMasquer la réponse de l'exercice 2

1. Versions précédentes depuis l'Explorateur, sur le dossier parent : l'utilisateur (ou le support) restaure le dossier depuis le snapshot horaire précédant la suppression, sans toucher au reste du partage.
2. Retour arrière (rollback) vers le dernier snapshot antérieur à 2 h, une fois la cause stoppée : c'est la méthode la plus rapide pour annuler 40 000 modifications, et rien de légitime n'a été écrit depuis. Avant cela, cloner le snapshot visé pour vérifier qu'il est sain et prendre un snapshot de l'état chiffré pour l'enquête (chapitre 10).
3. Clone du snapshot du zvol de cette date, présenté à une VM de test isolée (ou importé dans un environnement de test) : on examine l'état passé sans toucher à la production.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 5 Planifier les snapshots Réussi À revoir

Le service comptable veut pouvoir revenir à n'importe quel quart d'heure des deux derniers jours, à n'importe quel jour des trois derniers mois, et à n'importe quelle fin de mois des dix dernières années.

1. Propose les tâches de snapshots (fréquence, rétention, schéma de nom).
2. Combien de snapshots seront conservés en régime établi ?

Voir la réponseMasquer la réponse de l'exercice 3

1. Trois tâches sur le dataset de la comptabilité, avec trois schémas distincts :
   • toutes les 15 minutes (planificateur avancé : minutes */15), rétention 2 jours, schéma quart-%Y-%m-%d_%H-%M ;
   • tous les jours à 23 h 55, rétention 3 mois, schéma jour-%Y-%m-%d_%H-%M ;
   • le dernier jour du mois n'existe pas dans un planificateur cron simple : on prend le 1er de chaque mois à 0 h 05 (l'état de fin du mois précédent), rétention 10 ans, schéma mois-%Y-%m-%d_%H-%M.
2. 4 par heure × 24 h × 2 jours = 192 ; environ 3 × 30 = 90 quotidiens (91 ou 92 selon les mois) ; 12 × 10 = 120 mensuels. Total : environ 402 snapshots.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 5 Pousser ou tirer ? Réussi À revoir

Un prestataire propose de configurer la réplication sur srv-nas, en mode poussé vers nas-mrs, « parce que c'est plus simple : tout se règle au même endroit ». Quel risque cela crée-t-il face à un rançongiciel ? Que réponds-tu ?

Voir la réponseMasquer la réponse de l'exercice 4

En mode poussé, srv-nas détient une connexion SSH et des droits ZFS sur nas-mrs. Un attaquant qui prend le contrôle de srv-nas (compte d'administration volé) peut utiliser cette connexion pour détruire les snapshots et les datasets de Marseille, et donc les deux copies à la fois.

Réponse : configurer la réplication en mode tiré depuis nas-mrs. srv-nas n'a alors aucun identifiant sur nas-mrs ; la compromission du siège n'atteint pas les copies de l'agence. Compléter par des comptes d'administration distincts sur les deux NAS, avec double authentification.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 5 sur 5 Le temps de réplication Réussi À revoir

Le dataset vms/pve-vms voit environ 300 Gio de blocs modifiés par jour. La réplication vers Marseille passe par un lien de 500 Mbit/s, utilisable à 80 %.

1. Combien de temps dure la réplication quotidienne ?
2. Si le lien n'était que de 100 Mbit/s, serait-ce tenable avec une réplication par jour ?

Voir la réponseMasquer la réponse de l'exercice 5

1. 300 × 2³⁰ × 8 ÷ (500 × 10⁶ × 0,8) = 2 576 980 377 600 ÷ 400 000 000 ≈ 6 442 s ≈ 1 h 47 min.
2. À 100 Mbit/s : 300 × 2³⁰ × 8 ÷ (80 × 10⁶) ≈ 32 212 s ≈ 8 h 57 min. La réplication tient dans une nuit, mais sans marge : la moindre journée chargée la ferait déborder sur les heures de travail, et elle occuperait tout le lien. Il faudrait un lien plus rapide, ou ne répliquer à Marseille que les VM critiques.

Tu avais trouvé ?

Oui, j'avais bonPas encore