Aller au contenu
Tendances

Épisode 14 / 14La protection des données40 min

Créer et restaurer des snapshots

La machine à remonter le temps de ZFS : planifier les snapshots, récupérer un fichier supprimé, revenir en arrière après une mise à jour ratée — et savoir exactement ce qu’ils ne protègent pas.

Dans cet épisode

  • Créer un snapshot et comprendre pourquoi il ne coûte presque rien
  • Automatiser les snapshots avec une durée de conservation adaptée
  • Récupérer un fichier, et restaurer un dataset entier sans mauvaise surprise

Un fichier supprimé par erreur, une mise à jour qui casse une application, un rançongiciel qui chiffre le partage réseau : les snapshots sont la réponse de ZFS à tout ça. Instantanés, automatiques, et presque gratuits en place.

Les notions

TermeCe que c’est
SnapshotL’état figé d’un dataset à un instant. En lecture seule, créé en une fraction de seconde.
Tâche planifiéeLa création automatique de snapshots, avec une durée de conservation.
CloneUn nouveau dataset créé à partir d’un snapshot, pour y fouiller sans rien écraser.
RollbackLe retour d’un dataset entier à l’état d’un snapshot. Efface tout ce qui a suivi.
RéplicationL’envoi des snapshots vers un autre pool ou un autre NAS.

Étape 1 : un premier snapshot à la main

Dans Datasets, sélectionnez par exemple tank/apps/jellyfin et créez un snapshot, avec un nom explicite comme avant-mise-a-jour. Il apparaît instantanément. Prenez ce réflexe avant chaque mise à jour importante.

Étape 2 : automatiser

Dans Data Protection › Periodic Snapshot Tasks, ajoutez une tâche par dataset ou groupe de datasets (cochez Recursive pour inclure les sous-datasets). Un point de départ raisonnable :

FréquenceConservationPour quoi
Toutes les heures1 jourCe qui bouge vite : documents, Nextcloud, Vaultwarden
Tous les jours1 moisLes applications, les photos
Toutes les semaines3 moisCe qui bouge peu : films, archives

Étape 3 : récupérer un fichier supprimé

Le moment où l’on bénit les snapshots. Trois méthodes, de la plus simple à la plus complète :

  1. Sous Windows, les versions précédentes : clic droit sur le dossier dans le partage réseau, Propriétés › Versions précédentes. Si l’option est active sur le partage SMB, chaque snapshot y apparaît comme une version : ouvrez-la et récupérez le fichier.
  2. Un clone : dans la liste des snapshots, clonez celui de la bonne date vers un nouveau dataset, copiez-y le fichier perdu, puis supprimez le clone.
  3. Le dossier caché : chaque dataset contient un dossier .zfs/snapshot qui donne accès aux snapshots en lecture seule, selon la configuration du dataset.

Faites l’essai maintenant, avec un fichier de test supprimé exprès. Le jour où vous en aurez besoin, vous saurez faire.

Étape 4 : le rollback, avec précaution

Le rollback remet tout le dataset à l’état d’un snapshot : c’est la solution après une mise à jour ratée ou une base de données corrompue.

lundi mardi mercredi jeudi aujourd’hui Rollback vers mardi Effacé : tout ce qui a suivi mardi, snapshots de mercredi et jeudi compris
Revenir à mardi, c’est renoncer à tout ce qui a suivi. Pour un seul fichier, préférez les versions précédentes ou un clone.

Ce que les snapshots ne font pas

Les snapshots vivent dans le même pool que les données. Contre la suppression d’un fichier, une mise à jour ratée ou un rançongiciel sur un PC de la maison — qui ne peut pas toucher aux snapshots —, ils sont redoutables. Contre la perte du NAS entier, ils ne peuvent rien.

D’où la règle 3-2-1 : trois copies de vos données, sur deux supports différents, dont une hors de chez vous. TrueNAS propose tout ce qu’il faut :

  • Replication Tasks pour envoyer les snapshots vers un second NAS, chez un proche par exemple ;
  • Cloud Sync Tasks pour synchroniser un dataset vers un stockage en ligne.

Votre NAS est prêt

Si vous avez suivi les quatorze épisodes, votre NAS range ses données dans des datasets clairs, les partage avec des comptes limités, fait tourner vos services, et sait revenir en arrière. Il ne reste qu’une chose à faire régulièrement : tester une restauration. Une sauvegarde qu’on n’a jamais restaurée n’est qu’une promesse.

Testez-vous

3 questions pour vérifier que l’essentiel est acquis. Rien n’est noté ni enregistré.

  1. Pourquoi un snapshot ne prend-il presque pas de place au départ ?

  2. Que fait un rollback vers le snapshot de mardi ?

  3. Contre quoi les snapshots ne protègent-ils pas ?

Vérifier que tout fonctionne

Cochez au fur et à mesure : quand tout est coché, vous pouvez passer à la suite.

Problèmes courants

Les snapshots prennent beaucoup de place

Un snapshot conserve les blocs modifiés ou supprimés depuis sa création. Un dataset qui change beaucoup, comme les téléchargements, fait grossir ses snapshots. Réduisez leur durée de conservation, ou excluez ce dataset des snapshots fréquents.

Une tâche planifiée est en échec

Ouvrez la tâche pour lire l’erreur. Les causes habituelles : un dataset renommé ou supprimé, ou un pool en mauvaise santé. Vérifiez l’état du pool dans Storage.

Peut-on prendre un snapshot pendant qu’une application tourne ?

Oui. Pour une base de données en pleine écriture, le snapshot peut saisir un état intermédiaire ; dans la plupart des cas, l’application s’en remet au redémarrage. Pour une restauration critique, arrêtez l’application quelques secondes avant un snapshot manuel.

Votre progression reste sur cet appareil, rien n’est envoyé.