Linuxとテープは完璧な組み合わせであるかのように思えます。
ツールは柔軟です。自動化も可能です。望む通りのスクリプトを作成し、データの分割方法を決め、すべてを検証し、好みの方法でカタログを管理し、重視するのであれば高価なソフトウェアへの支払いを回避できます。適切な運用者にとって、その自由は魅惑的です。
また、多くのテープワークフローが脆弱になる原因でもあります。
スクリプト可能であることと、運用上の明快さは同義ではない
これが罠です。
カスタム構築されたLinuxテープワークフローは、ターミナル上では優雅に見えても、いざリストアの日には悲惨な結果を招くことがあります。tarジョブ、mtコマンド、LTFSマウント、独自マニフェスト、生成インデックス、バーコード対応表、チェックサムファイル、ステージング処理。個々の要素は完全に理にかなっていても、システム全体としては組み立てた本人にしか理解できないものになってしまうのです。
Linuxベースのテープツールを巡る最近の議論は、常にこの葛藤に立ち戻っていました。人々がスクリプト可能で透明性の高いワークフローを求めるのには正当な理由がありました。プロプライエタリなバックアップソフトウェア群や不可視のカタログ形式に縛られたくなかったのです。彼らが望んだのは、自ら検証し制御できるプロセスでした。
その直感は健全です。しかしそれが健全であり続けるのは、時間が経過した後でもワークフローが明快な状態を保っている場合に限られます。
テープはドキュメント作成のあらゆる弱点を浮き彫りにする
なぜなら、テープは通常、毎日張り詰めた緊張感の中で使用されるものではないからです。
ジョブが実行されます。メディアが交換されます。数週間が過ぎ、数か月が過ぎます。そしてある日、重要なデータを復元する必要が生じたとき、文書化されていないすべての前提が突然脅威となります。どのアーカイブセットがどのテープシーケンスに属していたか？どのバージョンのスクリプトで書き込まれたか？圧縮は有効だったか？マニフェストはどこにあるか？どのマシンに復元手順が記録されているか？そもそも復元の必要性を生じさせた障害を乗り越えてカタログは無事か？
シェルスクリプトがどれほど巧妙に見えたとしても、これらの問いに明確に答えられないスクリプトワークフローは、まだ成熟しているとは言えません。
優れたLinuxテープワークフローは退屈なほど明確である
それこそが追求すべき基準です。
彼らは一貫してマニフェストを生成します。何がどこに送られたかを記録します。書き込みを検証します。バックアップを実行しているマシンとは別の場所にリストア手順を文書化します。メディアにまたがる分割を予測可能なものにします。ラベリングルールを定義します。運用者のその場限りの職人芸を排除します。要するに、生存性の向上のために少しのスマートさを犠牲にするのです。
一部のチームが最終的に「賢いスクリプトの集まり」から本格的なバックアップソフトウェアへと移行するのはこのためです。Linuxに失望したからではなく、手作業で制御する楽しさよりも運用の確実性が重要になったからです。
そしてときにはその逆も起こります。丹念に構築されたLinuxワークフローが、運用担当者が堅牢性を維持できる十分な規律を持っているために、適切な答えであり続ける場合です。
どちらの結果でも構いません。危険なのは、スクリプトが存在することをもってバックアップシステムが存在すると誤認することです。
そうではありません。
テープはもとより厳密さを要求します。Linuxはその厳密さに見事に応える自由も、巧みに回避する自由も与えてくれます。違いを生むのはプラットフォームではありません。スクリプトを書いた本人が疲れているとき、不在のとき、あるいは実際のインシデントに対応しているときでも、プロセスが理解可能な状態を保てているかどうかです。
それこそが基準です。スクリプト化できることは機能の一つに過ぎません。復旧できることこそが本質なのです。