Sauvegardes ZFS immuables : readonly et politiques de snapshots qui tiennent la route

Ce que « immuable » signifie dans l’univers ZFS (et ce que ça ne signifie pas)

Dans le marketing des sauvegardes, « immuable » signifie souvent « on a coché un drapeau et ça rassure ». En production, immuable désigne quelque chose de plus restreint et testable : les données qui vous importent ne peuvent pas être modifiées ou supprimées pendant une fenêtre de rétention définie, même si un attaquant ou un opérateur obtient le niveau d’accès habituel.

Avec ZFS, vous n’avez pas un interrupteur magique d’immuabilité. Vous avez des couches :

• Les snapshots vous donnent une cohérence point-in-time et un versioning peu coûteux.
• Les datasets en readonly réduisent les écritures accidentelles et empêchent toute une catégorie de « oups ».
• Les holds et la délégation des permissions peuvent empêcher la suppression de snapshots par des opérateurs standards.
• Les topologies de réplication peuvent rendre le serveur de sauvegarde plus « simple » (bon point) et réduire le rayon d’effet d’un incident.
• Les contrôles hors ligne ou de suppression différée (souvent hors ZFS) sont ce qui fait pleurer les ransomwares.

Voilà ce que l’immuabilité ZFS n’est pas :

• Ce n’est pas une protection contre root sur l’hôte de sauvegarde. Si un attaquant contrôle root et possède les clés, il peut détruire votre pool. Votre travail est de rendre cela plus difficile, plus rare et détectable.
• Ce n’est pas un substitut aux copies hors site. Le feu et les inondations se moquent des snapshots.
• Ce n’est pas garanti par « readonly=on » seul. Vous pouvez toujours détruire des snapshots et datasets à moins d’avoir conçu le système pour l’empêcher.

L’objectif opérationnel est ennuyeux : assurez-vous de pouvoir toujours restaurer une copie récente et propre dans votre fenêtre RPO, et prouvez-le régulièrement.
« Ennuyeux » est un compliment en ingénierie des sauvegardes.

Faits et contexte historique qui façonnent des designs de sauvegarde réalistes

• ZFS est né chez Sun pour tuer la séparation “volume manager + système de fichiers”. C’est pourquoi les snapshots et le checksum sont natifs, pas greffés.
• Copy-on-write est l’astuce qui rend tout possible. Les snapshots ZFS sont économiques car les blocs sont partagés jusqu’à modification.
• ZFS sommeille et contrôle les checksums des données et des métadonnées de bout en bout. Cela a rendu la « corruption silencieuse » un problème solvable, pas une légende urbaine.
• Les snapshots ne sont pas des sauvegardes—pris isolément. Ils sont stockés sur le même pool. Perte de pool = perte des snapshots. Cette distinction est ignorée depuis la naissance des snapshots.
• Les premiers adopteurs ont appris que « scrub » est un planning, pas une émotion. Les scrubs réguliers trouvent les secteurs défaillants tant que vous avez encore de la redondance.
• Le send/receive incrémental est devenu le cheval de trait du DR basé sur ZFS. C’est essentiellement un journal des blocs modifiés entre snapshots.
• Les conventions de nommage des snapshots sont devenues une industrie à part. Parce qu’en situation de panique, vous choisirez le mauvais snapshot si le nommage n’est pas évident.
• Les « sauvegardes immuables » sont devenues populaires après la montée des ransomwares. Les attaquants ont appris à supprimer d’abord les sauvegardes, puis à chiffrer. Les défenseurs ont appris à rendre la suppression plus difficile.

Une idée paraphrasée à garder au mur : idée paraphrasée « L’espoir n’est pas une stratégie », attribuée à James Cameron, souvent répétée en opérations parce que c’est douloureusement vrai.

Un modèle pratique : source modifiable, destination quasi-append-only

L’architecture la plus simple et fiable est asymétrique :

1. Source (production) : datasets modifiables, snapshots fréquents, émetteur de réplication.
2. Cible de sauvegarde (vault) : reçoit les snapshots, les garde en readonly, les retient et minimise qui peut les supprimer.
3. Optionnel — second cible (hors site) : reçoit depuis le vault ou directement depuis la source, selon les frontières de confiance.

L’idée n’est pas de rendre la source immuable. La source héberge les applications. Elle change constamment. Votre travail est de rendre la destination difficile à manipuler tout en gardant la restauration pratique. Si restaurer est difficile, les gens ne testeront pas. Si personne ne teste, vous jouez à la catastrophe simulée.

Modèle de menace, franchement

• Suppression accidentelle : un administrateur détruit des snapshots ou datasets, ou un job de nettoyage part en vrille.
• Ransomware avec crédentiels : l’attaquant obtient des clés SSH, des jetons API ou un admin de domaine et cible l’infrastructure de sauvegarde.
• Hôte de sauvegarde compromis : l’attaquant obtient root sur le vault et tente de détruire la rétention.
• Corruption : RAM défectueuse, disques en fin de vie, HBA instables ou firmware défaillant — ZFS peut détecter, mais seulement si vous scrubbez et surveillez.

Vos défenses doivent correspondre à la menace. Readonly protège contre les écritures accidentelles. Les holds et la délégation protègent contre la suppression par des utilisateurs « normaux ». Pour « root sur le vault », vous avez besoin de séparation (domaine d’authentification différent, MFA, clés limitées), de surveillance et idéalement d’une copie hors ligne/hors site.

Datasets readonly vs snapshots : la différence qui compte à 2 h du matin

Dataset readonly signifie que vous ne pouvez pas modifier les fichiers dans la vue live de ce dataset (mountpoint). C’est une garde-fou.
C’est excellent pour les cibles de sauvegarde : vous recevez des snapshots répliqués puis maintenez le dataset en readonly pour éviter qu’un opérateur « modifie vite fait un config » dans la copie de sauvegarde.

Les snapshots sont des vues immuables du dataset à un instant donné. Mais « immuable » ici signifie que les blocs ne changeront pas ; cela ne signifie pas qu’un utilisateur privilégié ne peut pas détruire l’objet snapshot.
La suppression est le véritable ennemi dans les scénarios de ransomware.

Ce que readonly vous protège

• Modifications aléatoires du dataset de sauvegarde par des humains curieux.
• Services mal configurés qui écrivent accidentellement dans le mountpoint de sauvegarde.
• Certaines classes de malwares qui chiffrent simplement les systèmes de fichiers montés en écriture.

Ce que readonly ne protège pas

• zfs destroy sur des snapshots/datasets par quelqu’un disposant des privilèges ZFS.
• Destruction du pool (zpool destroy), retrait d’un device, ou sabotage de l’importabilité.
• Flux de réplication qui écrasent vos attentes (par ex., des receives forcés qui effectuent un rollback).

Si vous ne retenez qu’une chose : readonly protège des écritures ; les holds/délégation protègent des suppressions.

Blague n°1 : Readonly, c’est comme mettre vos restes dans le frigo du bureau avec votre nom dessus. Ça aide, mais ça n’arrête pas quelqu’un de déterminé et affamé.

Politique de snapshots qui ne pourrit pas : nommage, cadence, rétention

Les politiques de snapshots pourrissent quand elles sont trop astucieuses. Évitez l’astuce. La politique doit être :
prévisible, consultable et facile à raisonner lors d’une restauration.

Convention de nommage : choisissez-en une et ne déviez jamais

Utilisez un préfixe qui encode « géré par politique » et un timestamp qui trie lexicographiquement. Exemple :
auto-YYYYMMDD-HHMM pour les snapshots fréquents, et daily-YYYYMMDD pour les paliers de rétention plus longs.

Vous pouvez conserver plusieurs paliers sur le même dataset tant que votre outil de rétention les comprend. Si vous le faites manuellement, faites simple :
horaire pendant 48 heures, quotidien pendant 30 jours, hebdo pendant 12 semaines, mensuel pendant 12 mois. Ajustez selon RPO/RTO et la réalité de capacité.

Cadence : adaptez-vous aux rythmes métiers, pas à vos préférences

• Bases de données : les snapshots fréquents comptent, mais la cohérence compte plus. Coordonnez avec l’arrêt des applications ou utilisez des réplicas.
• Répertoires personnels : l’horaire (horaire) est souvent suffisant. Les gens suppriment des fichiers pendant la journée ; vous voulez des retours faciles.
• Images de VM : snapshot juste avant les fenêtres de changement et avant les patchs. Et suffisamment fréquemment pour couvrir « oups on a mis à jour la mauvaise chose ».

Rétention : ce que vous gardez est ce que vous pouvez restaurer

La rétention est un exercice de budget stockage avec conséquences. Votre politique de rétention doit rentrer dans le pool avec de la marge, sinon elle se suicidera :
les snapshots rempliront le pool, les performances chuteront, les allocations échoueront et quelqu’un supprimera « temporairement » des snapshots pour récupérer de l’espace.
« Temporairement » est comment les politiques de sauvegarde meurent.

Ne confondez pas nombre de snapshots et sécurité

Dix mille snapshots ne valent pas mieux que cinquante si vous ne les répliquez pas, ne les vérifiez pas et ne les protégez pas contre la suppression.
Un grand nombre de snapshots peut aussi ralentir des opérations comme la liste des snapshots et certaines tâches admin. ZFS gère bien beaucoup de snapshots, mais vos humains et vos outils peuvent ne pas le faire.

Prévenir la suppression : holds, délégation et rayon d’effet admin

Si votre menace inclut le ransomware, vous devez supposer que l’attaquant tentera de supprimer des snapshots. Vous avez besoin d’au moins une des options suivantes :
holds, délégation de permissions qui empêche la destruction de snapshots, ou un système séparé qui applique la rétention hors bande.
Idéalement : toutes ces couches.

Les holds ZFS : la ceinture de sécurité sous-estimée

Un hold empêche la destruction d’un snapshot tant que le hold n’est pas relâché. Ce n’est pas une « immuabilité absolue », mais c’est une défense robuste contre
la suppression accidentelle et contre les attaquants qui n’ont pas l’ensemble précis de privilèges (ou qui ne remarquent pas les holds).

Les holds sont agréables opérationnellement car ils sont explicites et inspectables. Vous pouvez taguer les holds avec des noms comme policy ou vault.
Utilisez-les côté vault pour appliquer les fenêtres de rétention.

Délégation : moins de personnes doivent pouvoir détruire les sauvegardes

Trop d’organisations exécutent la cible de sauvegarde avec le même groupe d’admin que la production. C’est pratique. C’est aussi la manière dont les attaquants obtiennent un double effet.
Séparez les rôles :

• L’utilisateur de réplication peut receive des snapshots mais ne peut pas détruire les anciens.
• Les opérateurs de sauvegarde peuvent lister et restaurer, mais la suppression des snapshots est protégée.
• Un rôle « break-glass » peut retirer des holds, avec MFA et journalisation d’audit.

Readonly sur le vault reste utile

Même avec des holds, définissez le dataset reçu en readonly. La plupart des ransomwares et la plupart des accidents sont ennuyeux : ils chiffrent les fichiers qu’ils peuvent écrire.
Rendre l’écriture difficile réduit la liste des victimes.

Réplication bien faite : schémas send/receive et modes de défaillance

La réplication ZFS est puissante car elle copie les snapshots à l’identique, propriétés incluses (si vous le souhaitez), et peut être incrémentale.
Elle est aussi assez tranchante pour vous blesser.

Schéma A : la source snapshote, le vault reçoit (par défaut recommandé)

La source prend des snapshots selon un planning. Le vault les pull ou la source les pousse. Le vault conserve des snapshots plus longtemps que la source.
Le dataset du vault est readonly et protégé contre la suppression. C’est la configuration standard qui fonctionne.

Schéma B : le vault snapshote le dataset reçu (utile pour l’historique côté vault)

Parfois vous voulez des snapshots côté vault (par ex. des copies « daily-cold ») indépendamment de ce que fait la source.
C’est acceptable, mais ça complique les restaurations : vous avez maintenant deux namespaces de snapshots, et vous devez être précis sur ce que vous envoyez et ce que vous retenez.

Mode de défaillance : receives forcés et rollbacks inattendus

Les outils de réplication utilisent parfois des flags qui peuvent rollback la cible pour coller au flux source. Cela peut supprimer des snapshots plus récents côté cible
ou détruire l’historique local du vault si vous êtes négligent. Votre vault devrait être ennuyeux : principalement recevoir, retenir et servir des restaurations.
Évitez les astuces bidirectionnelles « intelligentes » sauf si vous en avez vraiment besoin.

Mode de défaillance : chaîne incrémentale rompue

Le send incrémental requiert que le snapshot de base existe des deux côtés. Si quelqu’un supprime un snapshot nécessaire sur le vault, la réplication suivante échoue,
et la « correction » devient un renvoi complet. Les renvois complets sont coûteux, lents et surviennent souvent au pire moment.

Blague n°2 : La réplication incrémentale, c’est comme les commérages de bureau — supprimez un détail clé et soudain tout le monde doit repartir du début.

Tâches pratiques avec commandes : quoi exécuter, ce que ça signifie, ce que vous décidez

Ce sont des tâches opérationnelles réelles. Exécutez-les sur le bon hôte (source ou vault), et considérez la sortie comme un point de décision.
Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie, et ce que vous faites ensuite.

Task 1: Confirm dataset readonly on the vault

cr0x@server:~$ zfs get -H -o property,value readonly vault/backups/prod
readonly	on

Signification : Le mount du dataset n’est pas modifiable.
Décision : S’il est off, activez-le maintenant sur le dataset du vault (pas sur les datasets de production que les applications doivent écrire).

Task 2: Enforce readonly (vault side)

cr0x@server:~$ sudo zfs set readonly=on vault/backups/prod
cr0x@server:~$ zfs get -H readonly vault/backups/prod
readonly	on

Signification : Les nouvelles écritures via le mountpoint sont bloquées.
Décision : Si un processus a besoin d’écrire, il ne devrait pas utiliser le dataset du vault. Corrigez le flux de travail, pas le drapeau.

Task 3: List snapshots with creation time to verify cadence

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation -r tank/prod | tail -5
tank/prod@auto-20251226-0100  Fri Dec 26 01:00 2025
tank/prod@auto-20251226-0200  Fri Dec 26 02:00 2025
tank/prod@auto-20251226-0300  Fri Dec 26 03:00 2025
tank/prod@auto-20251226-0400  Fri Dec 26 04:00 2025
tank/prod@auto-20251226-0500  Fri Dec 26 05:00 2025

Signification : La cadence des snapshots est cohérente ; les noms se trient par temps.
Décision : En cas de trous, vérifiez cron/systemd timers, les journaux de l’outil de snapshots et la santé du pool (les snapshots échoués peuvent être un symptôme).

Task 4: Check retention pressure via snapshot space usage

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used -r tank/prod | head -5
NAME                         USED  REFER
tank/prod@auto-20251220-0100  48G   1.2T
tank/prod@auto-20251218-0300  41G   1.2T
tank/prod@auto-20251222-0900  39G   1.2T
tank/prod@auto-20251224-1800  35G   1.2T

Signification : Certains snapshots retiennent de grandes quantités de blocs anciens (HIGH USED).
Décision : Les gros snapshots USED sont souvent « avant une réécriture massive ». Gardez-les s’ils sont dans la politique ; sinon, taillez par palier, pas au feeling.

Task 5: Verify holds on vault snapshots

cr0x@server:~$ zfs holds vault/backups/prod@daily-20251201
NAME                               TAG     TIMESTAMP
vault/backups/prod@daily-20251201   policy  Fri Dec  1 00:05 2025

Signification : Un hold nommé policy empêche la suppression.
Décision : S’il n’y a pas de holds et que vous comptez sur eux pour l’immuabilité, ajoutez-les systématiquement (idéalement via automatisation).

Task 6: Apply a hold to a snapshot you must not lose

cr0x@server:~$ sudo zfs hold policy vault/backups/prod@daily-20251201
cr0x@server:~$ zfs holds vault/backups/prod@daily-20251201
NAME                               TAG     TIMESTAMP
vault/backups/prod@daily-20251201   policy  Fri Dec 26 05:40 2025

Signification : Le snapshot est maintenant protégé contre zfs destroy tant que le hold n’est pas relâché.
Décision : Utilisez des holds pour les paliers de rétention, les retenues légales ou les gels d’incident. Documentez qui peut les relâcher.

Task 7: Prove a snapshot cannot be destroyed due to holds

cr0x@server:~$ sudo zfs destroy vault/backups/prod@daily-20251201
cannot destroy snapshot vault/backups/prod@daily-20251201: snapshot has holds

Signification : La protection fonctionne.
Décision : Si cela ne bloque pas comme prévu, votre « immuabilité » est surtout une impression. Corrigez avant le prochain incident.

Task 8: Check who can destroy snapshots (delegation)

cr0x@server:~$ sudo zfs allow vault/backups/prod
---- Permissions on vault/backups/prod --------------------------------
Local+Descendent permissions:
user repl-user create,mount,receive
user backup-ops mount,snapshot,send
user breakglass destroy,hold,release

Signification : La délégation de permissions restreint les actions destructrices à des comptes spécifiques.
Décision : Si votre utilisateur de réplication a destroy, vous êtes à une clé compromise de regrettables conséquences. Retirez-le.

Task 9: Verify pool health (because replication won’t fix bad disks)

cr0x@server:~$ zpool status -x
all pools are healthy

Signification : Pas de défauts connus pour l’instant.
Décision : Si vous voyez des devices degraded/faulted, réparez le matériel d’abord. Des sauvegardes sur un pool malade ne sont que de la livraison plus lente de la corruption.

Task 10: Check recent scrub results

cr0x@server:~$ zpool status vault
  pool: vault
 state: ONLINE
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Dec 22 03:30:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        vault       ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Signification : Un scrub a été exécuté, rien n’a été réparé, pas d’erreurs de checksum trouvées.
Décision : Si les scrubs ne sont pas planifiés, planifiez-les. Si le scrub trouve des erreurs de façon répétée, investiguez les disques, câblage et la RAM.

Task 11: Confirm replication snapshots exist on both sides

cr0x@server:~$ zfs list -t snapshot -o name -r tank/prod | grep auto-20251226-0500
tank/prod@auto-20251226-0500
cr0x@server:~$ zfs list -t snapshot -o name -r vault/backups/prod | grep auto-20251226-0500
vault/backups/prod@auto-20251226-0500

Signification : Le point dans le temps existe aux deux extrémités, donc les incrémentaux peuvent continuer.
Décision : S’il manque sur le vault, la réplication est en retard ou échoue. S’il manque sur la source, votre job de snapshot échoue.

Task 12: Run an incremental send/receive (manual, explicit)

cr0x@server:~$ sudo zfs send -I tank/prod@auto-20251226-0400 tank/prod@auto-20251226-0500 | ssh backup-vault sudo zfs receive -u -F vault/backups/prod
cr0x@server:~$ ssh backup-vault zfs list -t snapshot -o name -r vault/backups/prod | tail -2
vault/backups/prod@auto-20251226-0400
vault/backups/prod@auto-20251226-0500

Signification : La réplication incrémentale a réussi ; le vault possède le nouveau snapshot. Les flags comptent :
-u reçoit sans monter ; -F peut faire un rollback — n’utilisez que si vous comprenez pleinement les conséquences côté cible.
Décision : Si vous avez besoin de -F régulièrement, vous avez probablement un problème d’hygiène des chaînes de snapshots. Corrigez la suppression et le nommage des snapshots.

Task 13: Measure replication throughput and spot compression wins

cr0x@server:~$ sudo zfs send -nvP tank/prod@auto-20251226-0500 2>&1 | tail -3
send from @auto-20251226-0400 to tank/prod@auto-20251226-0500 estimated size is 17.2G
total estimated size is 17.2G
time        sent   snapshot

Signification : L’estimation en dry-run montre la taille de l’incrémental.
Décision : Si les estimations sont constamment énormes, votre charge réécrit beaucoup. Aucune astuce ne transformera « 17G par heure » en « 200M par heure ». Ajustez la fréquence, excluez les datasets à forte activité ou acceptez la réalité réseau/capacité.

Task 14: Detect “snapshots pinning space” causing low free space

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint vault/backups/prod
NAME               USED  AVAIL  REFER  MOUNTPOINT
vault/backups/prod  38T   1.2T  1.4T   /vault/backups/prod

Signification : Le dataset approche la capacité (AVAIL petit). Les performances et allocations peuvent souffrir.
Décision : Ne « résolvez » pas cela en supprimant des snapshots au hasard. Appliquez la politique de rétention, ajoutez de la capacité ou déplacez des paliers hors du pool.

Task 15: Check reservation and refreservation surprises

cr0x@server:~$ zfs get -H -o property,value reservation,refreservation vault/backups/prod
reservation	none
refreservation	none

Signification : Aucune espace n’est réservé artificiellement.
Décision : Si vous trouvez de grandes réservations sur une cible de sauvegarde, confirmez qu’elles sont intentionnelles. Les reservations peuvent étouffer d’autres datasets et déclencher des suppressions paniques.

Task 16: Verify you can actually restore (clone a snapshot)

cr0x@server:~$ sudo zfs clone vault/backups/prod@auto-20251226-0500 vault/restore/prod-test
cr0x@server:~$ zfs list -o name,mountpoint,readonly vault/restore/prod-test
NAME                    MOUNTPOINT              READONLY
vault/restore/prod-test  /vault/restore/prod-test  off

Signification : Vous pouvez matérialiser une vue point-in-time pour tester la restauration. Les clones sont modifiables par défaut.
Décision : Les workflows de restauration doivent opérer sur des clones, pas sur le dataset immuable. Gardez le dataset du vault readonly ; faites les restaurations séparément.

Guide de diagnostic rapide : trouvez le goulot en premier, pas en dernier

Quand les sauvegardes prennent du retard, les équipes aiment argumenter « réseau » vs « stockage » vs « ZFS lent ». N’argumentez pas. Mesurez dans l’ordre.

Premièrement : le pool est-il sain et pas en train de mourir ?

• Exécutez zpool status. Si vous avez des erreurs READ/WRITE/CKSUM, vous avez un incident de fiabilité, pas un problème de tuning.
• Vérifiez si un scrub est en cours. Scrub + réplication peuvent écraser l’I/O sur des petits pools.

Deuxièmement : la capacité est-elle la contrainte cachée ?

• Vérifiez zfs list et l’espace libre du pool. Les pools très pleins fragmentent et ralentissent ; la suppression de snapshots peut devenir « la seule solution » à laquelle on pense.
• Inspectez quels snapshots retiennent de l’espace (zfs list -t snapshot -o used).

Troisièmement : la réplication est-elle bloquée par l’état de la chaîne de snapshots ?

• Confirmez que les snapshots de base existent des deux côtés.
• Cherchez des erreurs « cannot receive incremental stream » dans les logs ; cela signifie généralement des snapshots manquants ou une histoire divergente.

Quatrièmement : est-ce I/O, CPU ou réseau ?

• Si les sends sont estimés énormes, la charge est très volatile. Aucun réglage ne transforme cela miraculeusement.
• Si vous utilisez chiffrement ou compression sur le flux, le CPU peut être un facteur réel. Profilez avant de changer les réglages.
• Si le vault est sur des disques plus lents que la production (commun), les receives prendront du retard. Ce n’est pas un bug ; c’est votre architecture qui demande de la patience.

Cinquièmement : vous tirez-vous une balle dans le pied avec des propriétés ?

• Vérifiez sync, recordsize et compression sur les datasets du vault. Ne refaites pas bêtement les réglages de production sur les sauvegardes.
• Méfiez-vous de atime sur les datasets de sauvegarde ; il peut générer des écritures métadonnées inutiles si quelque chose parcourt l’arborescence.

Erreurs courantes : symptômes → cause racine → correction

Mistake 1: “Readonly means immutable”

Sx: Les snapshots disparaissent lors d’un incident ; le dataset est toujours en readonly.

Cause racine : Quelqu’un avec des privilèges ZFS a détruit des snapshots/datasets ; readonly n’arrête pas cela.

Correction : Utilisez des holds pour les paliers de rétention, retirez destroy des rôles replication/operator, et isolez la frontière admin du vault.

Mistake 2: Replication “succeeds” but restores are missing data

Sx: La cible a des snapshots, mais les données applicatives sont incohérentes ou manquent des fichiers récents attendus.

Cause racine : Le timing des snapshots n’est pas aligné avec la cohérence applicative, ou vous avez répliqué le mauvais sous-arbre de datasets.

Correction : Snapshottez les bons datasets, coordonnez avec l’arrêt applicatif si nécessaire, validez les restaurations avec des vérifications automatisées et conservez un dataset de test de restauration.

Mistake 3: Full resends every week

Sx: Les receives incrémentaux échouent ; les jobs reviennent aux envois complets ; le réseau est saturé.

Cause racine : Le snapshot de base est supprimé d’un côté, ou la cible a divergé à cause de snapshots locaux/changements et de rollbacks forcés.

Correction : Protégez les snapshots de base via des holds, standardisez le nommage, évitez les écritures locales sur les datasets reçus, et arrêtez d’utiliser -F comme mode de vie.

Mistake 4: Pool hits 95% and everything becomes “slow ZFS”

Sx: Retard de réplication, latence élevée, ENOSPC occasionnel, suppressions de snapshots très longues.

Cause racine : Planification de capacité ignorée pour la croissance des snapshots ; rétention trop agressive pour le pool.

Correction : Réduisez la rétention par palier, excluez les datasets à fort churn, ajoutez de la capacité ou déplacez la rétention long terme vers un autre pool.

Mistake 5: Backup dataset mounted and scanned by antivirus/indexers

Sx: I/O métadonnées inattendue, ralentissement des receives, pics de charge sur l’hôte de sauvegarde.

Cause racine : Les datasets du vault sont montés et traités comme des systèmes de fichiers vivants ; les scanners touchent tout.

Correction : Recevez avec -u, gardez les datasets du vault démontés par défaut, montez uniquement pour les restaurations et isolez les clones de restauration.

Mistake 6: Holds exist but retention doesn’t work

Sx: Les snapshots s’accumulent indéfiniment ; le pool se remplit ; personne ne peut supprimer rien.

Cause racine : Holds appliqués sans cycle de vie ; pas de suppression automatique après la fenêtre de rétention.

Correction : Implémentez des tags de hold par palier (ex. policy), et bâtissez un processus contrôlé pour relâcher les holds quand les snapshots dépassent l’âge autorisé.

Mistake 7: “We replicated, so we’re safe”

Sx: Source et vault contiennent des données chiffrées/corrompues après compromission.

Cause racine : La réplication a fidèlement copié des changements mauvais rapidement ; pas de délai, pas de détection, pas de palier hors ligne.

Correction : Ajoutez de la réplication différée, des paliers de rétention plus longs, une détection d’anomalies (churn inattendu) et une seconde copie dans un domaine de confiance séparé.

Trois mini-récits d’entreprise issus du front des sauvegardes

1) Incident causé par une mauvaise hypothèse : « Readonly = immuable »

Une entreprise SaaS de taille moyenne utilisait ZFS en production et sur un serveur de sauvegarde. Les datasets de sauvegarde étaient réglés readonly=on, et tout le monde se sentait rassuré.
Ils avaient même une diapositive dans la revue trimestrielle des risques : « sauvegardes immuables activées ».

Puis un compte privilégié a été compromis. L’attaquant ne s’est pas embarrassé à chiffrer le dataset du vault. Il a simplement supprimé les snapshots, parce que supprimer va plus vite que chiffrer.
La production a été touchée ensuite, et l’équipe a découvert que leur fenêtre de rétention était désormais « depuis l’arrivée de l’attaquant ».

Le postmortem fut inconfortable mais utile : personne n’a menti, mais plusieurs ont admis avoir supposé que readonly impliquait non supprimable.
Ce n’est pas le cas. ZFS est précis ; les humains ne le sont pas.

La remédiation fut tout aussi précise : holds sur les snapshots du vault pour les paliers de rétention, permissions déléguées pour empêcher les comptes de réplication de détruire quoi que ce soit,
un compte break-glass séparé avec journalisation d’audit et MFA. Ils décidèrent aussi que les hôtes de sauvegarde ne rejoindraient pas le même domaine d’identité que la production.

2) Optimisation qui se retourne contre soi : « On économise de l’espace en taillant agressivement »

Une grande équipe d’entreprise subissait des pressions pour réduire les coûts de stockage. Ils ont réduit la rétention des snapshots sur le vault drastiquement et activé un script de nettoyage
qui supprimait les snapshots au-delà d’un certain nombre, pas selon l’âge. Le script était rapide et les graphiques étaient beaux. Pendant un temps.

Puis un problème de corruption lente est apparu dans une application. Ce n’était pas évident : quelques enregistrements erronés, puis d’autres, puis l’application a commencé à « corriger » de façon qui empirait les données.
Au moment où quelqu’un a remarqué, le seul point de restauration propre était plus ancien que la fenêtre de rétention.

Le point intéressant : ZFS n’était pas en faute. Leur optimisation avait supprimé la seule chose capable de vous sauver des pannes lentes — le facteur temps.
Le ransomware est bruyant. La corruption et la logique défaillante sont silencieuses.

Ils ont annulé le changement de rétention, mais pas pour revenir aux anciens chiffres. Ils ont fait quelque chose de plus mature : rétention tierée avec un petit ensemble de snapshots « gold » plus durables et tenus par des holds, plus un test de restauration périodique. Les coûts de stockage ont augmenté modestement. La confiance en restauration a énormément monté.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : exercices de restauration routiniers

Une équipe de services financiers exécutait des exercices de restauration hebdomadaires. Chaque vendredi, quelqu’un cloneait un snapshot du vault vers un bac à sable de restauration et exécutait une petite batterie de vérifications :
comptage de fichiers, contrôles de cohérence applicative et une lecture d’intégrité rapide sur quelques fichiers représentatifs.

Ce n’était pas glamour. Les gens se plaignaient que ça prenait du temps. La direction continuait de financer parce que cela produisait un artefact simple : un ticket indiquant « restauration testée depuis le snapshot X ».
Ce ticket était une preuve répétable et ennuyeuse.

Quand ils ont subi un incident de vol de crédentiels, l’attaquant a tenté de supprimer des snapshots et a buté sur les holds. Il a ensuite tenté de manipuler le dataset monté et a buté sur readonly.
Entre-temps, l’équipe savait déjà quel snapshot restaurer parce qu’ils l’avaient testé récemment. Ils ont restauré proprement et sont passés à autre chose.

La leçon n’était pas « nous avions une meilleure techno ». C’était « nous avons fait le travail monotone ». En opérations, le travail monotone est ce qui vous achète du sommeil.

Listes de contrôle / plan étape par étape

Étape par étape : construire un vault ZFS “presque immuable” avec des paramètres raisonnables

1. Définissez datasets et frontières.
   Les datasets de production sont modifiables ; les datasets du vault sont en receive-only et readonly.
2. Mettez en place la cadence de snapshots sur la source.
   Gardez des noms cohérents. Assurez-vous que les snapshots couvrent votre RPO.
3. Répiquez vers le vault.
   Préférez une réplication explicite basée sur des snapshots. Évitez les workflows qui nécessitent fréquemment -F.
4. Définissez les datasets du vault en readonly et idéalement démontés par défaut.
   Montez les clones de restauration lorsque nécessaire.
5. Appliquez des holds sur les snapshots du vault selon les paliers de rétention.
   Utilisez un tag comme policy pour que ce soit consultable et cohérent.
6. Déléguez les permissions ZFS.
   Compte de réplication : receive, pas destroy. Opérateurs : actions de restauration, pas de contournement de rétention.
7. Planifiez des scrubs et surveillez les erreurs.
   Les scrubs servent à détecter les erreurs latentes avant qu’elles ne deviennent des blocs manquants lors d’une restauration.
8. Planifiez la capacité avec marge.
   Ne faites pas tourner le pool du vault presque plein. La rétention des snapshots a besoin de souffle.
9. Testez des restaurations régulièrement.
   Clonez un snapshot, montez-le, validez et enregistrez le résultat.
10. Pratiquez le break-glass.
    Définissez qui peut relâcher des holds, comment c’est audité et comment éviter la culture « tout le monde est root » sur le vault.

Checklist opérationnelle : avant de prétendre avoir des « sauvegardes immuables »

• Un compte non-breakglass peut-il détruire des snapshots du vault ? Si oui, vous n’êtes pas immuable.
• Des holds sont-ils appliqués et visibles ? Si non, vous faites confiance à des humains sous stress.
• Le vault est-il monté et modifiable quelque part ? Si oui, attendez-vous à ce que des tentatives de chiffrement réussissent.
• Avez-vous au moins une copie hors du domaine de confiance principal ? Si non, un admin de domaine compromis vous coûtera cher.
• Avez-vous restauré depuis le vault ces 30 derniers jours ? Si non, vous avez des croyances, pas des sauvegardes.

FAQ

Un snapshot ZFS est-il vraiment immuable ?

Son contenu est immuable (copy-on-write), mais l’objet snapshot peut être détruit par quelqu’un disposant des bons privilèges.
Si vous avez besoin de « ne peut pas être supprimé », utilisez des holds et restreignez destroy.

readonly=on arrête-t-il les ransomwares ?

Il bloque le chiffrement direct des systèmes de fichiers montés. Il n’empêche pas la suppression de snapshots, la destruction du pool, ou un attaquant privilégié.
Utilisez readonly comme une couche, pas comme une ligne d’arrivée.

Dois-je prendre des snapshots sur le vault ou sur la source ?

Par défaut, faites-les sur la source et gérez la rétention sur le vault. Les snapshots côté vault peuvent être utiles pour des paliers supplémentaires, mais ils ajoutent de la complexité et peuvent embrouiller les restaurations.

Quelle est la façon la plus sûre de restaurer sans affaiblir l’immuabilité ?

Clonez le snapshot dans un dataset de restauration séparé puis montez-le. Gardez le dataset reçu du vault readonly et idéalement démonté.

Comment les holds interagissent-ils avec les politiques de rétention ?

Les holds bloquent la suppression tant qu’ils ne sont pas relâchés. Un système de rétention doit appliquer des holds pour les snapshots dans la fenêtre de rétention et les relâcher quand ils expirent, puis supprimer proprement les snapshots.

Les utilisateurs de réplication peuvent-ils être limités à recevoir seulement ?

Oui. Utilisez zfs allow pour déléguer uniquement ce qui est nécessaire (typiquement receive, peut-être create), et évitez d’accorder destroy.
Vérifiez ensuite avec la sortie de zfs allow.

Pourquoi la réplication demande-t-elle parfois un renvoi complet ?

Les streams incrémentaux requièrent un snapshot de base commun. Si le snapshot de base manque d’un côté — ou si l’historique de la cible a divergé — la réception incrémentale échoue et un send complet est nécessaire.
Protégez les snapshots de base, et arrêtez de supprimer des snapshots ad hoc.

Combien de snapshots est « trop » ?

Cela dépend de la charge et des outils. ZFS peut gérer beaucoup de snapshots, mais les outils d’administration, les jobs de réplication et les humains peuvent peiner.
Gardez des paliers raisonnables et taillez selon la politique, pas la panique.

Quel est le meilleur indicateur que mon vault de sauvegarde est en mauvaise santé ?

Des erreurs de checksum persistantes ou des scrubs qui réparent à répétition. ZFS vous dit que l’intégrité des données est compromise.
Traitez cela en urgence : investiguez le matériel, firmware, câblage et la mémoire.

Une copie hors site est-elle toujours nécessaire si mon vault est « immuable » ?

Oui. L’immuabilité concerne la manipulation et la suppression, pas la perte de site, le vol ou les catastrophes.
Vous voulez au moins une copie dans un autre domaine de défaillance.

Conclusion : prochaines étapes réalisables cette semaine

Si vous voulez des sauvegardes ZFS immuables qui tiennent sous pression, arrêtez de chercher un unique bouton et commencez à empiler des contrôles :
readonly pour les écritures, holds pour résister aux suppressions, délégation pour réduire le rayon d’effet, et réplication qui n’exige pas des interventions héroïques.

1. Sur le vault, réglez les datasets reçus readonly=on et recevez avec -u pour qu’ils ne soient pas montés occasionnellement.
2. Mettez en place des holds pour les snapshots de votre fenêtre de rétention et prouvez que vous ne pouvez pas détruire des snapshots tenus.
3. Retirez destroy des comptes de réplication et des opérateurs ; réservez-le pour un rôle break-glass avec audit.
4. Exécutez un exercice de restauration : clonez un snapshot, montez-le et validez quelque chose de significatif (pas juste « ça s’est monté »).
5. Vérifiez la santé du pool et la planification des scrubs sur la source et le vault. Si l’intégrité est fragile, l’immuabilité est de la théorie.

Faites ces cinq choses et votre posture de sauvegarde passera de « espoirs et captures d’écran » à « mesurée et survivable ». Voilà le but.