Priorisation des tâches

[Nico052020]

Bonjour à tous,

Je me pose une question concernant les différentes tâches de maintenance ou de surveillance programmée.
Si je prends mon cas :
1x SSD sur lequel est installé l'OS
4x HDD qui constituent un raidz2

J'ai configuré les tâches suivantes :

Tests SMART
1x Test court effectué sur tous les disques (SSD + HDD) programmé chaque dimanche à minuit
1x Test long effectué sur ada0 (SSD) programmé le 1er de chaque mois à minuit
1x Test long effectué sur ada1 (HDD) programmé le 7 de chaque mois à 01h00
1x Test long effectué sur ada2 (HDD) programmé le 14 de chaque mois à 01h00
1x Test long effectué sur ada3 (HDD) programmé le 21 de chaque mois à 01h00
1x Test long effectué sur ada4 (HDD) programmé le 28 de chaque mois à 01h00

Instantanés
1x instantané effectué sur le volume de données (4x HDD) programmé tous les 1er du mois à 00h00 (durée de rétention 3 mois)
1x instantané effectué sur le volume de données (4x HDD) programmé tous les dimanches à 00h00 (durée de rétention 4 semaines)
1x instantané effectué sur le volume de données (4x HDD) programmé tous les jours à 00h00 (durée de rétention 2 semaines)

SCRUB
Scrub effectué sur le volume de donnée (4x HDD) programmé tous les 28 jours à 01h00

A cela s'ajoute un scrub effectué sur le "boot-pool" donc sur ada0 (SSD) que je n'ai pas programmé et qui n'apparait pas dans le Web GUI.
Je pense qu'il s'agit d'un scrub effectué automatiquement par le système. Je ne connais pas encore la fréquence, je m'en suis aperçu récemment quand j'ai mis en place les alertes courriels (j'ai reçu le courriel qui indiqué le début du scrub ce samedi 18 mars à 3h45).


Plusieurs questions :

1] Comment le système gère-t-il le fait qu'il puisse y avoir des tâches qui se chevauchent ?
Les tâches sont elles-effectuée l'une après l'autre? en même temps? Celle qui n'a pas pu être effectuée à son heure est "annulée" ?

2] Que pensez-vous de l’agrégation de des différents tests (smart) / services de maintenance, de sauvegarde,...
Je l'a trouve un peu bancale. J'ai du mal à savoir à configurer quelque chose qui tienne la route.
J'ai priorisé le fait que les tâches soient effectuées en pleine nuit, mais du coup, elles sont toutes effectuées en pleine nuit.

3] Que pensez-vous de la configuration des différents tests/ services eux-même
Pensez-vous que la fréquence des tests smart soient suffisant/trop/insuffisant
Pensez-vous que la fréquence des sauvegardes soient suffisant/trop/insuffisant (à savoir que je fais une sauvegarde sur des disques externe, tous les 1.5 mois en moyenne).
...

Cordialement

 

[Pitfrr]

Bonjour,


1] Alors ça je ne sais pas exactement comment le système gère cela...
Mais ce que je peux ajouter ici c'est que par exemple les tests SMART peuvent s'effectuer en opération normale. Théoriquement on pourrait même exécuter les tests de chaque disque en parallèle... En pratique cela aura une influence sur la disponibilité (enfin le temps de réaction) des disques et, si on accède aux disques en même temps, cela rallongera la durée du test.

2] Qu'appelles-tu service de sauvegarde car je n'en vois pas... Si tu fais référence aux snapshots, alors ce ne sont pas des sauvegardes pour moi...
(ok, ok, on peut s'accorder sur "une forme de sauvegarde", mon objectif n'est pas de commencer un long débat sur le sujet mais savoir de quoi tu parles exactement.)
Je décalerai le premier test long (du SSD) qui peut entrer en collision avec le short au même moment.
Je décalerai le scrub au 29 (pour éviter la collision avec le test long de ada4, même si ça ne devrait pas être trop gênant).
Pour les snapshots, ça me semble bien aussi, tu verras surtout à l'usage.
Pour ma part, j'ai différencié les snapshots selon les datasets que j'ai. Sur les datasets où les changements sont plus fréquents, j'ai une fréquence de snapshots plus importante (et inversement pour les autres).
Le scrub du volume de démarrage est configuré automatiquement et.... je viens de me rendre compte qu'en regardant vite fait, je trouve pas où c'est configuré tiens! :-O Mais bon, ça se fait automatiquement donc pas trop de soucis à se faire surtout si tu as fait une sauvegarde de ta config.

3] La fréquence des tests me semble bonne: une semaines pour les courts, un mois pour les longs et un mois pour le scrub.
Après c'est une question de sensibilité de chacun et pragmatisme (selon la taille des disques, ces tests peuvent prendre du temps!).
Quant aux sauvegardes... Comme je le disais plus haut, pour moi les snapshots ne sont pas des sauvegardes. Car si quelque chose arrive à ton volume, ben tu perds les données et les "sauvegardes". Je vois les snapshots comme un outil dans la stratégie de sauvegarde. Et ça prend du sens lorsque tu ajoutes que tu fais des sauvegardes externes tous les 1,5 mois en moyenne.
Pour les sauvegarde, cela va dépendre de la criticité de tes données et de ta sensibilité encore une fois. Car dans le pire des cas, tu peux perdre 1,5 mois (en moyenne) de données. A toi de juger si cela est acceptable ou pas (cela dépend des données que tu manipules et de la fréquence des changements).


Globalement, tu as réfléchi à ta stratégie de maintenance et de sauvegarde et c'est une bonne chose.
Dans ce que tu décris, je n'ai rien qui me saute aux yeux donc maintenant, tu verras aussi à l'utilisation ce que ça donne.

 

[Nico052020]

Bonjour Pitfrr,
Toujours au rdv. :)

2] Qu'appelles-tu service de sauvegarde car je n'en vois pas... Si tu fais référence aux snapshots, alors ce ne sont pas des sauvegardes pour moi...

Oui, il s'agit bien des snapshots dont je parle. Comme tu l'as dit plus bas dans ton message, ça fait parti de ma stratégie de sauvegarde.
Effectivement ça n'est pas à proprement parlé d'une sauvegarde, mais on peut la considérer comme telle s'il devait y avoir un rançongiciel par exemple.
De même, on peut la considérer comme tel si on doit récupérer des fichiers supprimés par inadvertance. D'ailleurs, je m'aperçois en écrivant ces lignes que je n'ai aucune idée de comment récupérer un fichier supprimé à partir d'un snapshot.
Je sais récupérer un fichier modifié : dans windows, on clique droit sur le fichier en question > Propriété > onglet "version précédente" > sélectionner le fichier à récupérer en fonction de la date et du nombre de version

==> si tu sais comment faire pour un fichier supprimé, je suis preneur.

Je décalerai le premier test long (du SSD) qui peut entrer en collision avec le short au même moment.

Tu crois ? ça prends deux minutes un test court. (le ssd fait 128Go en plus)
Suis-je passé à côté de quelque chose pour que tu me proposes ce décalage ?

Je décalerai le scrub au 29 (pour éviter la collision avec le test long de ada4, même si ça ne devrait pas être trop gênant).

Excuse-moi, petite coquille. Le scrub est effectué le 2 de chaque mois, avec un intervalle minimum de 28 jours.
En gros une fois par mois. (j'avais mis le paramètre "jour seuil" à 28 pour prendre en compte la particularité du mois de février).

En fait là où j'ai peur qu'il y ait des chevauchement ce sont surtout les snapshots qui sont paramétrés pour s'effectuer aux mêmes jours et surtout aux mêmes horaires que les tests smart et le scrub.
Je me demande si je les décalerai pas. Mais ou? Le problème c'est que les tests smart peuvent prendre plusieurs heures (en tests longs) sur des 3To.
Finalement d'où ma question initiale sur comment le système gère ces chevauchements. ;)

Cordialement

 

[Pitfrr]

==> si tu sais comment faire pour un fichier supprimé, je suis preneur.

Pour récupérer un fichier supprimé, il faut monter le snapshot. Ca se fait dans l'interface de TrueNAS, il va te créer un dataset (en lecture seule) du nom du snapshot et tu pourras y accéder ensuite à ta convenance (directement depuis un terminal SSH ou en y configurant un partage SMB par exemple).
Généralement, lorsque ça m'arrive (et si c'est que pour un fichier), je fais le tout depuis un terminal en SSH et je copie le fichier dans le bon dataset avant de supprimer ensuite le dataset du snapshot (bon là faut faire gaffe de pas supprimer le dataset actuel... Une erreur est si vite arrivée!).
Sinon, comme tu le dis, pour ouvrir une version précédente, sous windows, click droit sur le fichier et "Versions précédentes". Mais ça, ça marche que pour les fichiers existants... (et si c'est configuré)

Tu crois ? ça prends deux minutes un test court. (le ssd fait 128Go en plus)
Suis-je passé à côté de quelque chose pour que tu me proposes ce décalage ?

Oui tu as raison, je pense pas que ça pose problème si les deux arrivent en même temps... mais pour le principe.
Et comme tu le mentionnais dans ton premier post, je ne sais pas exactement ce qui se passe en cas de deux tests concurrents: sont-ils exécutés l'un après l'autre ou en même temps... Bah il se débrouille. :-D

les snapshots qui sont paramétrés pour s'effectuer aux mêmes jours et surtout aux mêmes horaires que les tests smart et le scrub

Là ce n'est pas un problème car les snapshots sont instantanés (comme le nom l'indique mais dire "les instantanés sont instantanés" aurait pu prêter à la confusion) donc ils ne vont pas interférer avec un scrub ou un test SMART.
Là je pense que c'est exécuté en parallèle et ça ne pose pas de problème.
Pour info: les tests SMART sont gérés par le disque lui même (c'est l'hôte qui envoie la commande et ensuite c'est le disque qui se débrouille mais qui répond aussi aux autres demandes de données de l'hôte). Les scrub sont gérés par TrueNAS et les snapshots aussi.

 

[Nico052020]

==> si tu sais comment faire pour un fichier supprimé, je suis preneur.

Pour récupérer un fichier supprimé, il faut monter le snapshot. Ca se fait dans l'interface de TrueNAS, il va te créer un dataset (en lecture seule) du nom du snapshot et tu pourras y accéder ensuite à ta convenance (directement depuis un terminal SSH ou en y configurant un partage SMB par exemple).
Généralement, lorsque ça m'arrive (et si c'est que pour un fichier), je fais le tout depuis un terminal en SSH et je copie le fichier dans le bon dataset avant de supprimer ensuite le dataset du snapshot (bon là faut faire gaffe de pas supprimer le dataset actuel... Une erreur est si vite arrivée!).
Sinon, comme tu le dis, pour ouvrir une version précédente, sous windows, click droit sur le fichier et "Versions précédentes". Mais ça, ça marche que pour les fichiers existants... (et si c'est configuré)

Super merci. Je n'avais pas remarqué que les instantanés sont enregistrés dans Stockage > Instantanés (Truenas 13).
Cela m'amène à une réflexion. J'ai configuré mes instantanés sur le pool racine.
Si jamais je devais aller récupérer un fichier. Tel que je le comprends, il faudrait sélectionner l'instantané souhaité et cliquer sur "cloner vers un nouveau dataset". Du coup, cela va me créer une copie de plusieurs centaines de gigaoctets, en gros de l'ensemble de mes données.
Si je vais à l'extrême, il pourrait ne pas y avoir assez de place disponible sur le volume pour monter l'instantané sur un nouveau dataset.
Ne faudrait-il pas mieux configurer des instantanés par dataset enfant ?
Qu'en penses-tu ?

Tu crois ? ça prends deux minutes un test court. (le ssd fait 128Go en plus)
Suis-je passé à côté de quelque chose pour que tu me proposes ce décalage ?

Oui tu as raison, je pense pas que ça pose problème si les deux arrivent en même temps... mais pour le principe.
Et comme tu le mentionnais dans ton premier post, je ne sais pas exactement ce qui se passe en cas de deux tests concurrents: sont-ils exécutés l'un après l'autre ou en même temps... Bah il se débrouille. :-D

Bon, je ne sais plus pourquoi j'avais décidé de faire comme cela. Peut-être une erreur de configuration. J'ai décalé le test long à 01h00, comme les autres.

les snapshots qui sont paramétrés pour s'effectuer aux mêmes jours et surtout aux mêmes horaires que les tests smart et le scrub

Là ce n'est pas un problème car les snapshots sont instantanés (comme le nom l'indique mais dire "les instantanés sont instantanés" aurait pu prêter à la confusion) donc ils ne vont pas interférer avec un scrub ou un test SMART.
Là je pense que c'est exécuté en parallèle et ça ne pose pas de problème.
Pour info: les tests SMART sont gérés par le disque lui même (c'est l'hôte qui envoie la commande et ensuite c'est le disque qui se débrouille mais qui répond aussi aux autres demandes de données de l'hôte). Les scrub sont gérés par TrueNAS et les snapshots aussi.

Heu, là j'ai un peu de mal à te suivre. S'il y a plusieurs dizaines de giga à copier, cela va forcément impacter un test smart long ou un scrub en court (même si celui-ci est géré par le disque et non par le système).

 

[Etorix]

Si jamais je devais aller récupérer un fichier. Tel que je le comprends, il faudrait sélectionner l'instantané souhaité et cliquer sur "cloner vers un nouveau dataset". Du coup, cela va me créer une copie de plusieurs centaines de gigaoctets, en gros de l'ensemble de mes données.

Un clone ne copie rien du tout. Seules les modifications effectuées sur le clone occuperont de l'espace.
Incidemment, pour récupérer un fichier il suffit de monter l'instantané (lecture seule) et de copier le fichier vers une nouvelle destination.

Heu, là j'ai un peu de mal à te suivre. S'il y a plusieurs dizaines de giga à copier, cela va forcément impacter un test smart long ou un scrub en court (même si celui-ci est géré par le disque et non par le système).

Pourquoi y aurait-il "des dizaines de giga à copier" ? Un instantané est… instantané parce que c'est juste une opération sur les métadonnées.

 

[Pitfrr]

En complément de la réponse de @Etorix, je vais essayer d'illustrer le principe des snapshots.

Si tu prends l'image ci-dessus en partant d'un dataset vide.

• 3 fichiers sont créés de 100Mo chacun puis on fait un snapshot (snapshot 1)
  • Ce snapshot 1 fige ces 3 fichiers et occupe une place de 300Mo
  • Espace disque utilisé: 300Mo
• 2 fichiers supplémentaires sont créés de 100Mo chacun puis un fait un snapshot (snapshot 2)
  • Ce snapshot 2 fige ces 2 nouveaux fichiers et prend une place de 200Mo
  • Espace disque utilisé 500Mo
• 2 fichiers sont supprimés (fichiers 2 et 5) et un nouveau fichier est créé puis un snapshot est fait (snapshot 3)
  • Ce snapshot 3 fige un nouveau fichier (et 2 suppressions) et prend une place de 100Mo
  • Espace disque utilisé 600Mo

D'un point de vu utilisateur, on peut restaurer n'importe quel snapshot (de 1 à 3), il va cloner le snapshot dans un dataset dédié mais ne va pas copier quoi que ce soit, il va juste donner accès en lecture seule à l'endroit ou "pointe" le snapshot.
Un snapshot prend une "photo" du système de fichier à l'instant donnée par rapport au dernier snapshot (donc que les différences sont enregistrées). C'est pour ça que le snapshot 3 ne pend que 100Mo.
Par contre, lorsque l'on supprime un fichier et qu'un snapshot existe, ce fichier ne sera alors pas supprimé. Il faut donc faire attention que les snapshots peuvent prendre beaucoup de place si on a beaucoup de modification.
C'est un donc un bon système de "protection" (contre la suppression par accident ou autre) mais à un prix (en stockage).

De plus TrueNAS est fait de tel sorte que le système de fichier gère nativement les snapshots, donc c'est une opération simple, rapide (instantanée) qui s'effectue sur les métadonnées.

 

[Pitfrr]

Et à propos des snapshot, un post de @Paul042020 à ce sujet...

 

[Nico052020]

Je comprends mieux. Merci.

Typiquement , quand on dit que s'il y a un rançongiciel, les snapshot sont une sécurité dans la mesure où ils sont en lecture seule. Moi je comprenais, qu'il y avait une espèce de sauvegarde incrémentale en parallèle. Et que du coup, cette "sauvegarde" ne pouvait pas être atteint par un rançongiciel car justement elle était en lecture seule.
Mais en fait c'est l'inverse, si un tel cas venait à se produire, les données sont effectivement "chiffrées" par un logiciel, mais étant donné que le système a enregistré dans les métadonnées toutes les opérations effectuées sur les fichiers (suppressions, ajouts, modifications,...) entre deux snapshots, on peut revenir en arrière.
Du coup, on ne fait que "remonter le temps" avec une perte potentielle de données qui dépend de la fréquence des snapshots et du moment où on s'en rend compte.

Si j'ai bien compris, pas besoin d'affiner les snapshots aux datasets enfants.