ZFS sur Linux : snapshots, clones et RAID-Z en pratique

ZFS intègre nativement deux fonctionnalités qui en font un système de fichiers de référence pour les infrastructures de production : les snapshots instantanés basés sur le mécanisme Copy-on-Write, et RAID-Z, son implémentation de la parité distribuée. Si l’article ZFS sur Linux — Installation et gestion avancée couvre la mise en place initiale, cet article se concentre sur ces deux mécanismes en profondeur, avec les cas d’usage réels en production.

Les snapshots ZFS sont instantanés (quelques millisecondes), consomment initialement zéro espace disque supplémentaire, et peuvent être répliqués à distance de manière incrémentale. RAID-Z, quant à lui, offre une protection contre les pannes disque sans les effets de bord du RAID logiciel traditionnel (write hole notamment). Voyons comment exploiter ces deux fonctionnalités au quotidien.

Snapshots ZFS — Fonctionnement et commandes essentielles

Un snapshot ZFS est un pointeur vers l’état d’un dataset à un instant T. Grâce au Copy-on-Write, ZFS ne copie les blocs que lorsqu’ils sont modifiés — le snapshot initial ne coûte donc rien en espace disque. Plus les données changent, plus le snapshot grossit.

Créer et gérer les snapshots

# Snapshot simple d'un dataset
zfs snapshot tank/data@2026-04-28

# Snapshot récursif (dataset + tous ses enfants)
zfs snapshot -r tank@2026-04-28

# Lister tous les snapshots avec espace consommé
zfs list -t snapshot -o name,used,referenced,creation

# NAME                        USED   REFER  CREATION
# tank/data@2026-04-27       320M   12.1G  Mon Apr 27 02:00
# tank/data@2026-04-28       148M   12.4G  Tue Apr 28 02:00

# Lister les snapshots d'un dataset spécifique
zfs list -t snapshot tank/data

Accéder et restaurer des données

# Les snapshots sont directement accessibles en lecture dans .zfs/snapshot/
ls /srv/data/.zfs/snapshot/

# Restaurer un fichier spécifique sans rollback complet
cp /srv/data/.zfs/snapshot/2026-04-27/config.conf /srv/data/config.conf

# Rollback complet du dataset à un état antérieur
# Attention : détruit tous les snapshots plus récents
zfs rollback tank/data@2026-04-27

# Rollback en forçant la destruction des snapshots intermédiaires
zfs rollback -r tank/data@2026-04-27

# Supprimer un snapshot obsolète
zfs destroy tank/data@2026-04-20

# Supprimer tous les snapshots d'un dataset (avec confirmation)
zfs list -t snapshot -o name tank/data | tail -n +2 | xargs -n1 zfs destroy

Clones — snapshots modifiables pour les environnements de test

# Créer un clone (dataset modifiable basé sur un snapshot)
# Zéro espace consommé au départ — les blocs sont partagés
zfs clone tank/data@2026-04-28 tank/data-staging

# Vérifier
zfs list -o name,used,origin tank/data-staging
# NAME              USED  ORIGIN
# tank/data-staging  0B   tank/data@2026-04-28

# Rendre le clone indépendant du snapshot source (promotion)
# Utile pour transformer un environnement de test en production
zfs promote tank/data-staging

Réplication ZFS — Sauvegarde distante incrémentale

La commande zfs send | zfs receive permet de répliquer des datasets entre machines de manière efficace. C’est la base de toute stratégie de sauvegarde sérieuse avec ZFS : les données sont transmises sous forme de flux binaire compressé, y compris les métadonnées.

# ── Envoi initial complet ─────────────────────────────────────────────────────
# -c = compression réseau (recommandé)
zfs send -c tank/data@2026-04-28 | 
  ssh backup-host "zfs receive backup/data"

# ── Envoi incrémental (le plus utilisé au quotidien) ──────────────────────────
# -i = seulement les différences entre deux snapshots
zfs send -ci tank/data@2026-04-27 tank/data@2026-04-28 | 
  ssh backup-host "zfs receive -F backup/data"

# ── Réplication récursive (dataset + tous ses enfants) ────────────────────────
zfs send -Rc tank@2026-04-28 | 
  ssh backup-host "zfs receive -F backup"

# Vérifier la bonne réception côté serveur de backup
ssh backup-host "zfs list -t snapshot backup/data"

Important : un snapshot sur le même pool n’est pas une sauvegarde. Une défaillance du contrôleur, du boîtier ou du pool détruit snapshots et données simultanément. Toujours répliquer vers un hôte physiquement séparé.

Automatisation avec Sanoid

Sanoid est l’outil de référence pour automatiser la gestion des snapshots ZFS avec des politiques de rétention configurables (horaire, journalière, mensuelle). Il fonctionne via un timer systemd et s’intègre parfaitement avec syncoid pour la réplication automatique.

# Installation
sudo apt install sanoid -y

# /etc/sanoid/sanoid.conf
[tank/data]
  use_template = production
  recursive = yes

[tank/vm-disks]
  use_template = production

[template_production]
  hourly  = 24      # conserver 24 snapshots horaires
  daily   = 30      # 30 journaliers
  monthly = 3       # 3 mensuels
  autosnap  = yes   # création automatique
  autoprune = yes   # suppression des anciens selon la politique

# Activer le timer systemd
sudo systemctl enable --now sanoid.timer

# Vérifier les snapshots auto créés
zfs list -t snapshot -o name,creation | grep "autosnap"

# Réplication automatique avec syncoid (inclus dans sanoid)
syncoid tank/data backup-host:backup/data

RAID-Z — Choisir le bon niveau de protection

RAID-Z est l’équivalent ZFS du RAID 5/6, mais sans le write hole (risque de corruption lors d’une panne pendant une écriture en RAID classique), grâce au Copy-on-Write. Trois niveaux existent selon le nombre de disques toléré en panne :

# RAID-Z1 — 3 disques, 1 tolérance (non recommandé en production)
zpool create tank raidz /dev/sdb /dev/sdc /dev/sdd

# RAID-Z2 — 4 disques, 2 tolérances (standard production)
zpool create tank raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Double vdev RAID-Z2 en parallèle (meilleures performances en écriture)
zpool create tank 
  raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde 
  raidz2 /dev/sdf /dev/sdg /dev/sdh /dev/sdi

# Ajouter un disque de spare (remplacement automatique en cas de panne)
zpool add tank spare /dev/sdj

# Vérifier l'état détaillé du pool
zpool status -v tank

Optimisations selon le workload

# Compression LZ4 — quasiment transparente en CPU, gain 20-40% d'espace
zfs set compression=lz4 tank/data

# Adapter le recordsize selon le type de données
zfs set recordsize=16K  tank/postgres    # PostgreSQL (pages 8K)
zfs set recordsize=128K tank/mysql       # MySQL InnoDB
zfs set recordsize=128K tank/docker      # Docker layers
zfs set recordsize=1M   tank/archives    # Fichiers volumineux, backups

# Désactiver l'atime (réduit les écritures parasites)
zfs set atime=off tank/data

# Tuning de l'ARC (cache RAM ZFS) — limiter à 75% de la RAM disponible
RAM_BYTES=$(awk '/MemTotal/{print $2 * 1024}' /proc/meminfo)
ARC_MAX=$(( RAM_BYTES * 3 / 4 ))
echo "options zfs zfs_arc_max=$ARC_MAX" | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

Maintenance et surveillance

# Scrub mensuel — vérification d'intégrité de toutes les données
zpool scrub tank

# Planifier via cron (1er du mois à 2h du matin)
echo "0 2 1 * * root /sbin/zpool scrub tank" | sudo tee /etc/cron.d/zfs-scrub

# Surveiller l'état en temps réel
zpool status -v

# Statistiques du cache ARC
cat /proc/spl/kstat/zfs/arcstats | grep -E "^(hits|misses|c |size)" | 
  awk '{printf "%-20s %sn", $1, $3}'

# Résumé complet ARC (si arc_summary installé)
arc_summary | head -40

Pièges courants

• Ne pas utiliser dedup — nécessite ~5 GB de RAM par To de données uniques indexées. La compression LZ4 apporte des gains similaires à un coût nul.
• Swap sur ZFS — ne jamais placer le swap sur un zvol ZFS. En cas de pression mémoire, ZFS lui-même a besoin de RAM pour fonctionner, créant un deadlock. Utiliser une partition dédiée ou tmpfs.
• RAID-Z non extensible — impossible d’ajouter un disque à un vdev RAID-Z existant (contrairement à un miroir). La taille des vdevs est figée à la création : prévoir large.
• Import simultané sur deux systèmes — risque de corruption grave (split-brain). Toujours exporter le pool avant de le déplacer ou de le partager entre machines.
• Taille des vdevs RAID-Z — ZFS recommande des vdevs de largeur 3-9 disques en RAID-Z1/Z2. Au-delà, la reconstruction en cas de panne prend trop de temps et augmente le risque d’une seconde panne.

À lire également

• ZFS sur Linux — Installation et gestion avancée — le point de départ indispensable avant d’approfondir snapshots et RAID-Z
• Installation et Configuration des Conteneurs LXC sur Linux — ZFS et LXC forment un duo puissant : clonage instantané de conteneurs via snapshots ZFS
• Docker sur Debian/Ubuntu : Installation, Configuration et Utilisation — configurer le backend de stockage ZFS pour Docker
• Analyse de la mémoire sur Linux — vmstat, free, smem — surveiller et dimensionner la RAM allouée à l’ARC ZFS

Références

• Ubuntu — Using ZFS Snapshots and Clones (documentation officielle)
• ZFS Snapshots for Backup and Data Protection on Linux
• HowToForge — ZFS Snapshots, Clones and Replication
• FreeBSD Handbook — ZFS (référence exhaustive, applicable sous Linux)
• Sanoid / Syncoid — GitHub officiel