IBM Spectrum Protect(ISP)の保管ポリシー設定について、時々見かける誤解について注意喚起したいと思います。
ISPのバックアップの保管ポリシーの設定値には、バックアップデータを世代で管理するための verexist と verdeleted、日数で管理するための retextra と retonly があります。
世代管理の設定値は分かりやすいので、間違えることはほとんどありません。
verexist はサーバー上に存在するファイルの保管世代数で、verdeleted はサーバー上から削除されたファイルの保管世代数です。
世代数について間違えることはあまりありませんが、世代管理の仕組みについては注意が必要です。
パスとファイル名を元に世代管理するので、例えば、ファイル名に日付が付けられて毎回ユニークな名前になってしまうファイルについては世代管理になりません。
同様に、同じ名前のファイルでも日付が付いたフォルダに保管される場合などはパスが変わることになりますので、世代管理になりません。
また、verdeleted はISPサーバーがファイルが削除されたことを検知してから適用されるため、削除されたことを検知出来ないようなバックアップを行うと適用されない場合があります。
例えば、2019年は"/2019"ディレクトリーを指定してバックアップ、2020年は"/2020"ディレクトリーを指定してバックアップ、という運用をすると、2020年に"/2019"ディレクトリーの中のファイルに変更があっても検知することが出来ません。
ISPサーバーは"/2019"ディレクトリーにファイルが存在すると認識したままなので、"/2019"ディレクトリーのバックアップを保持し続けることになります。
主に問題となるのは、日数管理の設定値である retextra と retonly です。
今回は retextra に関する誤解例について紹介します。
retextra はマニュアル上で、「バージョンが非活動状態になった後に、バックアップ・バージョン を保存する日数を指定します。」と説明されています。
バージョンが非活動状態(INACTIVE)というのは、サーバー上に存在するファイルの最新のバックアップ(ACTIVE)ではないことを指します。
そのため、マニュアルにも記載はされていますが、verexist や verdeleted で指定している保管世代数の範囲内のバックアップバージョンであっても、retextra で指定した日数が経過すると削除されてしまいます。
世代管理を保持した上で日数管理しているという誤解が生じる可能性がありますので、注意が必要となります。
例えば、バックアップは日次で増分バックアップ、保管期間は365日で、念のため3世代分のバックアップを保管するといった要件があった時に、verexist=3 retextra=365 と設定すると何が起きるでしょうか。
2019/1/1
Aという名前のファイルが作成されて、バックアップされる
2019/1/2
Aが更新されて、バックアップされる
※便宜的にA'と表現する
2019/1/3
Aが更新されて、バックアップされる
※便宜的にA''と表現する
2019/1/4以降は更新されなかった。
上記の状態では、A''が最新のACTIVEなバージョン、A'とAがINACTIVEなバージョンになります。
この状態で、2020/1/1になると、AがINACTIVEの状態でバックアップから365日経過したことによって、retextra の削除対象となります。
2020/1/2になると、A'がINACTIVEの状態で365日経過したことによって、削除対象となります。
2020/1/3になると、A''が365日経過しますが、ACTIVEなので削除対象になりません。
よって、2020/1/4以降は、A''のバックアップだけが保管されることになります。
ファイルAのバックアップは最新の1世代しか保管されないため、「念のため3世代分のバックアップを保管」していないことになります。
よって、非活動状態、言い換えれば古いバージョンのバックアップを無制限に3世代保管するという要件があるのであれば、retextra による日数管理を併用してはいけないということになります。
どうしても、世代管理だけでなく、365日という日数管理もしなければいけないということであれば、retextra は無制限(=nolimit) にして、365日以前のバックアップを削除する処理を定期的に実行するといった対応が考えられます。
バックアップを削除する delete backup コマンドは、fromdate / todate オプションで期間を指定することが可能です。