Comment configurer des jeux de données ZFS distincts pour les données des applications, les sauvegardes et les téléchargements

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Configurez des jeux de données ZFS distincts pour les données des applications, les sauvegardes et les téléchargements en attribuant à chaque charge de travail son propre point de montage, ses propriétés, sa politique d’instantanés et sa limite de nettoyage.

Sur un serveur domestique, ces dossiers commencent souvent dans un seul grand partage, simplement parce que c’est pratique. Ils finissent ensuite par nécessiter des politiques différentes en matière de conservation, d’autorisations, de compression, de taille d’enregistrement, de quotas et de restauration. La configuration la plus sûre consiste donc à les séparer avant qu’une charge de travail très active n’impose sa politique à toutes les autres.

Déterminez ce que chaque jeu de données doit protéger

Commencez par définir le rôle de chaque charge de travail. Les données des applications nécessitent généralement des instantanés cohérents et des restaurations soigneusement contrôlées, les sauvegardes exigent une maîtrise de la capacité et de la conservation, tandis que les téléchargements doivent pouvoir être nettoyés facilement sans entrer dans une protection à long terme.

Les jeux de données ZFS constituent autant des limites administratives que des dossiers. Des propriétés telles que la compression, les quotas et les réservations, les points de montage et les instantanés peuvent être gérés par jeu de données. C’est pourquoi il est utile de séparer les charges de travail, même lorsqu’elles résident dans le même pool.

Avant toute création, notez les trois rôles prévus : l’état des applications à restaurer, les données de sauvegarde à conserver et les données temporaires ou retéléchargeables à supprimer. Si deux dossiers nécessitent la même politique de restauration et de nettoyage, ils n’ont peut-être pas encore besoin de jeux de données distincts.

Créez des points de montage clairs avant de déplacer les données

Choisissez des points de montage qui rendent la séparation évidente pour les applications comme pour les utilisateurs. Une structure simple peut utiliser un dossier parent tel que /srv/storage, puis des points de montage enfants pour appdata, backups et downloads.

La documentation OpenZFS zfs-set décrit la définition des propriétés des jeux de données avec zfs set, tandis que la documentation générale des propriétés couvre le comportement des points de montage et l’héritage des propriétés. Vous pouvez ainsi créer un parent avec des valeurs par défaut communes et ne modifier que les enfants qui nécessitent un comportement différent.

Créez d’abord des jeux de données vides, vérifiez qu’ils sont montés aux emplacements prévus, puis déplacez les données. Si une application écrit encore dans l’ancien chemin, arrêtez-vous et migrez-la pendant une fenêtre de maintenance afin de pouvoir revenir proprement en arrière.

Appliquez à l’ensemble de données des applications la politique d’instantanés la plus rigoureuse

Les données des applications évoluent généralement par petites modifications importantes : bases de données, fichiers de configuration, contenus envoyés par les utilisateurs, volumes de conteneurs et état des applications. La perte d’un seul fichier peut être moins visible que la perte d’un dossier de sauvegarde entier, mais restaurer le mauvais instant peut rendre une application inutilisable.

La documentation des propriétés OpenZFS montre que les propriétés au niveau des jeux de données peuvent être héritées ou remplacées. Les données des applications peuvent ainsi bénéficier d’instantanés plus fréquents ou d’une compression différente, sans imposer ces choix aux téléchargements.

Pour les données des applications, privilégiez des instantanés fréquents, une suppression prudente et un test de restauration sur une application représentative. Si une application utilise une base de données active, coordonnez les instantanés avec sa propre méthode de sauvegarde ou de mise en veille, plutôt que de supposer que l’instantané du système de fichiers est cohérent avec l’application.

-15% OFF

Fixez des limites de capacité et de conservation aux sauvegardes

Les sauvegardes méritent leur propre jeu de données, car elles peuvent augmenter discrètement à cause de la conservation, des métadonnées de déduplication, des sauvegardes complètes synthétiques, de la réplication ou d’anciennes tâches clientes. Un jeu de données de sauvegarde sans limite peut consommer l’espace nécessaire aux applications ou aux partages actifs.

Le guide Oracle sur les propriétés ZFS présente les quotas et les réservations comme des contrôles au niveau des jeux de données. Ils sont donc utiles pour empêcher la croissance des sauvegardes d’empiéter sur les charges de travail sans rapport.

Définissez un quota ou, au minimum, un seuil d’alerte pour le jeu de données de sauvegarde, puis faites correspondre la conservation des instantanés à celle de l’outil de sauvegarde. Ne conservez pas indéfiniment des instantanés du système de fichiers autour de fichiers de sauvegarde que l’application de sauvegarde considère déjà comme supprimés.

Gardez les téléchargements faciles à reconstruire et à supprimer

Les téléchargements constituent généralement le jeu de données le moins important, car la plupart des fichiers sont temporaires, retéléchargeables ou placés en attente avant leur classement. Ils méritent néanmoins leur propre limite, car ils peuvent remplir rapidement un pool et hériter d’instantanés dont ils n’ont pas besoin.

Un jeu de données distinct pour les téléchargements permet de réduire ou de désactiver la conservation à long terme, d’adapter la compression au type de fichiers et de nettoyer le dossier sans toucher à l’état des applications ni aux sauvegardes.

Utilisez un quota réduit ou un nettoyage planifié si les téléchargements remplissent régulièrement l’espace disponible. Si un fichier devient important, déplacez-le vers le jeu de données dont la politique correspond à son nouveau rôle, au lieu de conserver des données à long terme dans la zone temporaire.

Vérifiez les autorisations, les instantanés et les restaurations après la séparation

La configuration n’est pas terminée lorsque les jeux de données existent. Elle l’est lorsque les applications démarrent correctement, que les sauvegardes sont enregistrées dans le bon jeu de données, que les téléchargements peuvent être nettoyés sans risque et que les instantanés présentent les limites attendues.

Effectuez un contrôle de restauration pour chaque catégorie : restaurez une petite configuration d’application, affichez un point de récupération de sauvegarde et supprimez ou nettoyez un fichier de téléchargement de test. Vous vérifierez ainsi que la limite du jeu de données correspond bien à la limite opérationnelle.

Si un instantané inclut de manière inattendue des téléchargements ou exclut des données d’application, arrêtez-vous et corrigez le point de montage ou l’affectation du jeu de données avant d’ajouter d’autres automatisations. Le résultat final idéal est simple : chaque charge de travail possède une politique que vous pouvez expliquer en une phrase.

FAQ

Les données des applications et les sauvegardes peuvent-elles parfois partager un même jeu de données ?

Oui, uniquement si elles partagent réellement les mêmes exigences en matière de conservation, de quota, d’instantanés et de restauration. Sur la plupart des serveurs domestiques, les données des applications et les sauvegardes nécessitent des politiques différentes.

Puis-je séparer les jeux de données une fois que les données existent déjà ?

Oui, mais considérez cette opération comme une migration. Créez les nouveaux jeux de données, arrêtez les applications ou tâches qui écrivent des données, déplacez les données, mettez à jour les chemins, effectuez des tests et conservez l’ancienne copie jusqu’à ce que les nouveaux points de montage soient vérifiés.

Pour une étape de planification connexe, examinez l’interaction entre les limites des jeux de données et la capacité de réplication. Le guide de ZimaSpace sur le remplissage d’un pool de destination par la réplication des instantanés montre pourquoi la conservation et la portée des jeux de données doivent être conçues ensemble.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.