【技術】Commvaultでの苦戦

f:id:infra_kiku23:20190613212818j:plain

こんばんは。

キクです。

※諸事情により本記事はデータ移行したものです

今日は、最近触っているCommvaultについて書いてみようと思います。

触り始めの認識なので、これから知識を深めていく形になります。

(書き味的には備忘録になるだろうか)

ここ数日、Commvaultというバックアップ関連の技術の練習をしています。

そもそもバックアップに関する知識がないので、Commvault以前に分からないことも多く苦戦していますが｢作る｣｢消す｣の作業を繰り返していく中で少しずつ動きがわかったりもするので楽しめてもいます。

苦戦したところは「バックアップジョブ」に関連する「シーケンス番号」という概念。

バックアップ取得の際に「フルバックアップ」「増分バックアップ」など種類を選びながら取っていくことになるかと思います。

そこで絡んでくるのがシーケンス番号で、例えば「フル→増分→増分」と行った感じでバックアップを取得していくと「シーケンス１→シーケンス２→シーケンス３」といった感じにそれぞれが連続した関係性を持つことになります。

途中のシーケンス番号のバックアップジョブが消えた場合、以降のバックアップジョブは存在価値がなくなるといってもいいような立ち位置になってしまうのだと思いました。

つまり、シーケンス番号が繋がっている部分までをリストアできるといってもいいと思います。

これに気づいて少し腑に落ちたといった感じです。

そもそもなぜこの疑問を持ったのか。

それは、ライブラリ自身のデータがダメになった時、そのデータをどこかに複製していたのであればリストアをすると思います。

その時、ライブラリにあったデータは少し古くなる可能性があります。

しかし、それに連動して古くなった際に消えたそれ以降のデータを取得する際に実行されたバックアップジョブはCommvault上に残っているのです。

これが厄介でした。

データはないけど、バックアップジョブは存在するという状態。

それではライブラリをリストアした後に実行したバックアップジョブのシーケンス番号はどうなるのか？

連番になります。

しかし、途中のシーケンス番号はバックアップファイルの存在しないバックアップジョブが潜んでいることは上記の通り。

新しいバックアップジョブからリストアしようとすると、中身のないシーケンス番号の所で失敗してリストアはできませんでした。

じゃあ新しいバックアップジョブを実施する前に中身のないバックアップジョブを削除したら良いのではないだろうか？

そうすれば削除した分のシーケンス番号の所に、新しいバックアップジョブのシーケンス番号が入るのではないだろうか？

そう考えた私は１度やってみました。

結果としてはうまく行きませんでした。

「増分バックアップ」としてバックアップジョブを実行したはずなのに「フルバックアップ」が実行されたのです。

自分なりに解釈した結果、どこであろうがシーケンス番号が抜けた時点でそのシーケンスの繋がりは崩れるのだと考えました。

例

フル→増分１→増分２→増分３

：増分２を削除した場合、増分１まではリストアできるがそれ以降はできない

：増分３を削除した場合、増分２まではリストアできる

　また、新しくバックアップジョブを実施したら新しいフルができる

「フル→増分１→増分２」「フル」

以上から、シーケンス番号の繋がりは思ったより固いのだなと思った次第です。

それでは。

Kiku Blog