Linux et la bande semblent former un duo évident.
L'outillage est souple. L'automatisation est possible. Vous pouvez scripter selon vos besoins, segmenter vos données, tout vérifier, gérer vos catalogues à votre façon et éviter des logiciels lourds et coûteux. Pour l'exploitant averti, cette liberté est grisante.
C'est aussi là que de nombreux flux sur bande deviennent fragiles.
La flexibilité d'un script ne garantit pas la clarté opérationnelle
Voici le piège.
Un flux Linux personnalisé peut être élégant dans le terminal et désastreux le jour de la restauration : commandes tar, mt, montages LTFS, manifestes sur mesure, index générés, tables de codes-barres, sommes de contrôle, logique de transit... chaque élément peut être logique individuellement alors que l'ensemble n'est compréhensible que par son auteur.
Les discussions récentes autour des outils de bande sous Linux revenaient sans cesse sur cette tension : on recherchait des flux scriptables et lisibles pour d'excellentes raisons, sans vouloir s'enfermer dans des suites fermées ou des catalogues opaques.
Ce réflexe est sain, à condition que le flux reste parfaitement compréhensible au fil des années.
La bande met à nu chaque faiblesse documentaire
Car la bande ne s'utilise pas chaque jour avec une intensité émotionnelle maximale.
Les tâches s'exécutent. Les supports tournent. Les semaines et les mois passent. Puis un jour, il faut récupérer un élément crucial, et soudain chaque hypothèse non documentée devient une menace. Quel jeu d'archives appartenait à quelle séquence de bandes ? Quelle version du script a écrit ce lot ? La compression était-elle active ? Où se trouve le manifeste ? Quelle machine conservait les notes de restauration ? Le catalogue est-il assez isolé pour survivre à la panne qui a déclenché le besoin de restauration ?
Un flux de travail scriptable incapable de répondre clairement à ces questions manque encore de maturité, quelle que soit l'élégance du script.
Les bons flux de travail sur bande sous Linux sont d'une rigueur limpide
Voilà l'exigence qu'il convient de viser.
Ils génèrent des manifestes de manière rigoureuse, tracent chaque emplacement, vérifient les écritures, archivent les instructions de restauration ailleurs que sur le serveur actif, anticipent les coupures de bande, fixent des conventions d'étiquetage et bannissent les bricolages d'urgence. En somme, ils sacrifient un peu d'élégance pour beaucoup de pérennité.
Voilà pourquoi certaines équipes finissent par migrer d'une collection de scripts vers une vraie suite logicielle : non parce que Linux a failli, mais parce que la rigueur des procédures a pris le pas sur le plaisir du sur-mesure artisanal.
Et parfois, l'inverse se produit : un flux Linux soigneusement bâti demeure la meilleure réponse parce que ses exploitants font preuve de la discipline requise pour le pérenniser.
L'une ou l'autre issue convient. Le vrai danger réside dans l'illusion que l'existence de scripts garantit l'existence d'un système de sauvegarde.
Il n'en est rien.
La bande exige déjà de la méthode : Linux vous donne la liberté de l'appliquer brillamment ou de l'esquiver avec art. La différence ne vient pas du système, mais de la clarté du processus lorsque son créateur est fatigué, absent ou face à une vraie crise.
Telle est la norme : la scriptabilité est un atout, la capacité de restauration est le but.