Bonnes pratiques de sauvegarde ZFS

ZFS combine un système de fichiers, un gestionnaire de volumes et du RAID dans une seule pile de stockage. Comme StateWarden opère au niveau bloc/périphérique, protéger un système basé sur ZFS consiste à sélectionner le bon périphérique bloc comme source de sauvegarde. Cet article explique quoi sauvegarder sur les hôtes ZFS, ce que contient une sauvegarde de ZVOL et quelles erreurs de sélection éviter.

1. ZVOL et datasets

ZFS expose deux types d'objets de stockage :

• Les datasets sont des objets de niveau système de fichiers, montés dans l'arborescence de répertoires (par exemple /tank/home). Ils contiennent des fichiers et des répertoires et n'ont aucune représentation sous forme de périphérique bloc.
• Les ZVOL (ZFS Volumes) sont des périphériques bloc créés avec zfs create -V. Un ZVOL sert typiquement de disque de machine virtuelle, de périphérique de support pour une LUN iSCSI ou de volume brut pour une base de données.

Sous Linux, chaque ZVOL apparaît sous deux chemins de périphérique :

• /dev/zvol/<pool>/<nom> - un lien symbolique stable et lisible (par exemple /dev/zvol/tank/vm-100).
• /dev/zd<N> - le périphérique bloc noyau sous-jacent (par exemple /dev/zd0).

Identifiez les ZVOL par leur chemin /dev/zvol/... lors de la configuration des sources de sauvegarde. Le chemin encode le nom du pool et du volume, il reste donc stable d'un redémarrage à l'autre, alors que la numérotation zd peut changer lorsque des périphériques sont ajoutés ou retirés. Dans le Dashboard, les ZVOL apparaissent dans la liste des volumes de l'onglet Stockage & Sauvegardes de l'appareil, aux côtés des autres périphériques bloc.

StateWarden est un agent de sauvegarde au niveau bloc. Il protège les ZVOL directement. Il ne peut pas capturer un dataset monté (une arborescence comme /tank/home), car un dataset n'est pas un périphérique bloc. Si des données à protéger résident dans un dataset, migrez-les vers un système de fichiers placé sur un ZVOL.

2. Recommandation : sauvegardez le ZVOL

Pour chaque exécution de sauvegarde sur un ZVOL, StateWarden utilise les snapshots ZFS natifs pour obtenir une source cohérente. Le copy-on-write de ZFS rend la création de snapshot pratiquement instantanée et ne met pas en pause les écritures sur la couche de stockage. La sauvegarde capture donc une image exacte et figée du volume au niveau bloc, prise à un instant unique.

Ce qu'une sauvegarde de ZVOL vous apporte :

• Une image du contenu du volume à un instant donné, dédupliquée et compressée sur le nœud de stockage comme toute autre sauvegarde au niveau bloc.
• Une granularité de restauration par volume : vous pouvez restaurer un seul ZVOL sans toucher au reste du pool.

Ce qu'elle ne vous apporte pas :

• La sémantique fichier au niveau dataset. La sauvegarde contient les octets bruts du périphérique bloc - c'est-à-dire le système de fichiers écrit à l'intérieur du ZVOL par l'invité ou l'application. Elle ne contient ni la hiérarchie de datasets du pool ni les métadonnées de niveau ZFS.
• L'historique des snapshots ZFS. Les snapshots locaux du ZVOL ne sont pas transférés vers le nœud de stockage. La sauvegarde est une image au niveau bloc, pas un flux de réplication ZFS. Une restauration reproduit le volume tel qu'il était au point de sauvegarde, pas la chaîne de snapshots locaux, ni les clones, ni les propriétés ZFS comme recordsize ou compression.

3. Ne sauvegardez pas les disques membres du pool

N'ajoutez pas les disques physiques qui composent un pool ZFS (par exemple /dev/sdc) à une politique de sauvegarde. C'est le même principe que pour les volumes physiques LVM et les membres de RAID logiciel (voir Bonnes pratiques de sauvegarde LVM).

Un pool répartit (striping) ses données sur ses vdevs par groupes de transactions (TXG). Sauvegarder les disques membres individuels d'un pool actif capture chaque disque à un état de groupe de transactions différent. À la restauration, les disques ne peuvent pas être assemblés en un pool cohérent, et le résultat est une corruption. Notez que la redondance ZFS (miroir, RAIDZ) est un mécanisme de disponibilité, pas une sauvegarde : sélectionnez les ZVOL et laissez les disques membres du pool non assignés.

4. Charges VM et bases de données sur ZVOL

Une sauvegarde de ZVOL par snapshot est cohérente en cas de crash (crash-consistent) : l'image capturée correspond à l'état que vous verriez après une coupure de courant inopinée. Les systèmes de fichiers et bases de données modernes récupèrent automatiquement de cet état, mais une cohérence de type crash n'est pas une cohérence applicative. Les tampons conservés en mémoire par l'application ne font pas partie de l'image.

Pour les charges qui doivent être cohérentes au niveau applicatif, mettez-les en quiescence autour de la fenêtre de sauvegarde :

• Machines virtuelles : utilisez l'agent invité de l'hyperviseur ou le mécanisme de gel du système de fichiers pour que l'invité vide ses systèmes de fichiers au moment de la sauvegarde, et planifiez les sauvegardes pendant les périodes de faible E/S invité.
• Bases de données : coordonnez le mécanisme natif de vidage (flush) ou de sauvegarde à chaud de la base (par exemple un flush-with-read-lock) avec la planification des sauvegardes, ou acceptez la cohérence de type crash et vérifiez-la par des restaurations de test régulières.

La règle générale : la couche de stockage fige les blocs ; rendre l'état de l'application propre à cet instant relève de la responsabilité de la charge de travail.

5. Interaction avec la compression et la déduplication

La compression ZFS (compression=lz4 et similaires) est transparente au niveau bloc. Les lectures d'un ZVOL renvoient le contenu logique, décompressé ; le pipeline de sauvegarde voit donc les mêmes octets que ceux écrits par l'invité ou l'application. Deux conséquences pratiques :

• La compression ZFS sur le ZVOL n'améliore ni ne dégrade les taux de déduplication et de compression côté sauvegarde. Fondez vos estimations de stockage sur les données de la charge elle-même, pas sur les chiffres de compressratio du pool.
• Les données déjà compressées ou chiffrées au-dessus de la couche bloc - archives, fichiers multimédias, bases de données à compression interne ou chiffrement de disque côté invité - réduisent les taux de déduplication et de compression, exactement comme sur tout autre type de volume.

6. Applicabilité de Smart CBT

Smart CBT sous Linux repose sur le suivi des modifications dm-era et ne s'applique pas aux ZVOL. Les ZVOL sont snapshotés nativement pour la cohérence et lus intégralement pendant la sauvegarde ; l'efficacité de stockage provient de la déduplication au niveau bloc plutôt que du suivi des blocs modifiés. Le Dashboard indique l'état CBT de chaque volume ; voir Smart CBT : sauvegardes incrémentales pour les indicateurs d'état et le comportement de repli.

7. Liste de contrôle récapitulative