ZFS : ce qu’un snapshot protège, et ce qu’il ne protège pas

01. Inventorier datasets et snapshots

zfs list
zfs list -t snapshot -o name,creation,used,refer

Identifiez le dataset de l’application et les éventuels datasets enfants. La portée doit être explicite : une capture d’un parent n’inclut pas automatiquement chaque enfant sans l’option appropriée. Notez l’heure et l’état applicatif associés au point conservé.

Un snapshot représente un état du système de fichiers. Une base de données ou une application distribuée peut demander une coordination supplémentaire pour une reprise correcte. Vérifiez les recommandations du logiciel concerné.

02. Faire un essai sur un dataset de test

zfs snapshot tank/test@avant-maintenance
zfs list -t snapshot

Cet exemple suppose que tank/test existe et ne contient que des données de test. Après la capture, modifiez un fichier de test puis étudiez sa récupération dans la documentation de votre plateforme. Ne lancez pas un rollback global pour récupérer un seul fichier sans comprendre quelles modifications seraient perdues.

03. Surveiller la place retenue

Les snapshots retiennent des blocs nécessaires aux états anciens. Une forte activité peut donc faire croître l’espace conservé, même lorsque l’on supprime des fichiers dans l’état courant. Définissez une durée de rétention et une alerte de capacité avant de multiplier les captures.

La suppression des snapshots est une décision de rétention. Inventoriez les dépendances, les clones et les transferts éventuels avant de retirer un point. Gardez les points nécessaires à la dernière chaîne de reprise validée.

04. Ajouter une copie hors du pool

La perte du pool peut emporter les données et leurs snapshots. Une stratégie de sauvegarde doit donc ajouter une copie indépendante. Étudiez la réplication ZFS et ses contrôles d’intégrité, puis testez la récupération depuis le système destinataire sans accéder à la source.

Vérifiez également la séparation des droits : un même compte capable de supprimer les données et toutes les copies constitue une dépendance commune. La stratégie 3-2-1 aide à repérer ces points communs.

05. Retrouver pools, datasets et clones dans le wiki

L’ancien article ZFS décrivait aussi la structure des pools, miroirs, RAID-Z, quotas, réservations et clones. Avant une modification, séparez la topologie des vdevs de l’organisation des datasets. Une réserve de capacité, un quota et une redondance de disque répondent à des problèmes distincts.

La perte d’un vdev de données indispensable peut compromettre le pool. N’ajoutez pas un disque comme nouveau vdev en pensant étendre automatiquement la redondance existante. Les possibilités d’extension dépendent de la version et de la topologie : vérifiez-les avant toute écriture. Un clone et son snapshot d’origine ont aussi des dépendances à examiner avant suppression.

06. Séparer ZFS sous Solaris et OpenZFS

Le wiki décrivait ZFS dans son contexte Solaris. Les évolutions Oracle ZFS et OpenZFS ne sont pas automatiquement interchangeables. Vérifiez les versions et fonctionnalités activées avant d’importer un pool sur une autre plateforme ou d’organiser un transfert.

Conservez un inventaire des fonctionnalités et testez la réception sur la destination prévue. Un exemple de zfs send décrit une méthode de transfert ; la compatibilité et la restauration applicative restent à vérifier.