Admin Alerts: 古い IBM i バックアップ、新しいトリック
あなたが他のほとんどの IBM i 管理者と同じようなら、バックアップ手順はおそらく確定されていて、それほど変更する必要はないでしょう。それは信頼できますし、実際機能します。ところが何かが発生し、新しい状況やニーズに合わせてバックアップを微調整する必要性が出てくるかもしれません。今週は、バックアップ・ソリューションを変更または修正しなければならない可能性がある、3 つのシナリオを見ていきましょう。
我々のバックアップ・シナリオ
ここに、バックアップ手順にわずかですが重要な変更をせざるを得ないような 3 種類のバックアップ状況があります。
- まだ稼働していない新しい IBM i パーティションを作成する
- 日次、週次、または月次 IBM i バックアップからオブジェクトをリストアできることを証明するための新しい監査要件
- バックアップ・ウィンドウが縮小し始めるときにバックアップを変更する
1--まだ稼働していない新しい IBM i パーティションを作成する
実際にあった話です。私が 2000 年初頭に働いていたある会社で、新しく構成した IBM i パーティションで置換 ERP システムを開発していました。システムのロードにまる 1 か月をかけて構成し、サード・パーティー・ソフトウェアを追加し、テストの準備をしました。そのプロジェクトは 10 人体制でした。数十万ドルもの費用を新しいパーティションの開発に費やしました。そのパーティションを稼働させるための期限もありました。
ある日、システムがクラッシュし、ショップは多数の変更をロールバックし、開発用パーティションを以前のバージョンにリストアしなければなりませんでした。
そこでわかったのが、なんと、バックアップがなかったのです。
IT 運用マネージャー (私ではありません) の判断では、これは実動システムではなく開発用システムなので、定期的なバックアップ計画を急いで配備する必要はないということでした。このパーティションのために真新しいバックアップ戦略をいじくりまわすのに、まる 1か月を費やしました。一方、システムはクラッシュし、1 か月分の作業が失われ取り戻すことができませんでした。もう一度最初からやり直さなければならなかったのです。
この話のポイントは、こうです。開発システムが厳密なバックアップ計画なしに済むといった思い違いはしないこと。何かあったら、開発システムはたった 1 つの単純な理由で、実動ボックスより多くのバックアップが必要になります。
開発システムは実動システムほど安定していません。
ソフトウェアとオペレーティング・システムは、実動ボックスよりも開発ボックスでより頻繁に変更されます。実動ソフトウェアとオペレーティング・システムの変更が遅い一部のショップでは、その週のデータをバックアップし、プログラムやオペレーティング・システムを含むシステム全体を週末にだけバックアップして、その場を切り抜けることができる場合があります。
開発用パーティションのバックアップ目標は、実動システムで狙っている目標とは正反対のものになります。
開発ボックスでは、データは常にリフレッシュし、再ロードできるため、プログラミング環境のデータほど重要ではありません。日々のプログラミング、構成、オペレーティング・システムの変更はより頻繁に行われ、確実なバックアップ計画を実装していない場合、それらを再ロードすることはできません。
開発用 OS をバックアップしておらず、プログラミングの変更が毎日発生する場合は、システム障害のときにそれらを失う危険性を負っています。上に書いたように愚かな IT 運用マネージャーのようになってはなりません。開発中、また処理中のシステムを定期的にバックアップし、システム障害が発生しても火傷しないようにしてください。
2--日次、週次、または月次 IBM i バックアップからオブジェクトをリストアできることを証明するための新しい監査要件
実動システムのバックアップについて監査員は、次のような古典的な質問をよく尋ねます。
「バックアップが機能するという証拠はあるのか」
あなたは、世界で最も洗練されたバックアップ手順を備えていると思いますが、バックアップ媒体から IBM i オブジェクトをリストアできない場合、何の役にも立ちません。定期的なバックアップを実行し、文書化するのに加えて、バックアップが機能するかどうか証明するため、バックアップ媒体からオブジェクトのリストアをテストするのが良いでしょう。
私が働いていたあるショップでは、オブジェクトのリストアを文書化するのが Sarbanes Oxley 監査の要件でした。ジョブ・ログを使用して、バックアップが機能していたことを文書化することに加え、各バックアップの最後にバックアップ媒体からテスト・リストアを実行しました。
これら 2 つのステップを実行することで次の点が文書化されました。
1) バックアップが機能し、かつ 2) 作成したバックアップ媒体から問題なくリストアできました。リストアが必要な事態が発生した場合に、メディアが正しく書き込まれ、準備完了になったことを確認しました。
3--バックアップ・ウィンドウが縮小し始めるときにバックアップを変更する
実動システムを年中無休で実行しており、定期的なフル・システム・バックアップ (FSB) ができない場合、次の 3 種類の方法でバックアップを調整し、忙しい実動システムを補うことができます。
- レプリケートされた高可用性 (HA) システムがある場合、HA ボックスからデータをバックアップする。
データおよびプログラムをすべてキャパシティー・バックアップ (CBU) システムまたはクラスター・システムにレプリケートしている場合、実動システムからではなく、レプリケート・データからユーザー・データのバックアップを実行できます。レプリケート・データは目標復旧時点 (RPO) に応じて最新の状態になり、実動システムを停止させずに、実動データをバックアップすることができます。 - GO SAVE 22 バックアップを使用して定期的にシステム・データのみバックアップする (システム・データのみ)。
オプション 22 保存は、システムを制限モードにし、保存操作中に以下のオブジェクトのみバックアップします。- パーティションのライセンス内部コード
- QSYS システム・ライブラリー
- ユーザー・プロファイルを含むすべてのセキュリティー・オブジェクト
- すべてのデバイス構成オブジェクト
- ユーザー・データの入っていないすべての IBM 提供ライブラリーおよびディレクトリー
- システムを制限せずに変更頻度の高い IBM システム・オブジェクトをバックアップする。
オプション 22 バックアップのほとんどの項目は、比較的静的です。ライセンス・プログラム・データ、システム・ライブラリー (QSYS)、IBM 提供ライブラリーはそれほど変更されません。オプション 22 バックアップで定期的に変更される項目は、セキュリティー・オブジェクト (ユーザー・プロファイルを含む) とデバイス構成オブジェクトです。システムがアクティブな状態で、セキュリティー・オブジェクトと構成オブジェクトをバックアップできる点はありがたいです。これにより、回復時のため、必要に応じてそれらのオブジェクトの最新のコピーを保持することができます。以下のコマンドを使用して、これら 2 種類のシステム・オブジェクトのみバックアップします。
- Save Security Data (SAVSECDTA) コマンドは、システムがアクティブな状態ですべてのセキュリティー・データを保存します。
- Save Configuration (SAVCFG) コマンドは、システムがアクティブな状態ですべてのデバイス構成を保存します。
これら 3 つの項目をまとめると、実動システムと HA システムで次の作業を行うことで、より小さなバックアップ・ウィンドウでフル・システム・バックアップを実行できます。
- 数か月ごと、またはオペレーティング・システムを変更したときに、オプション 22 バックアップを実行する。-- これにより、必要に応じて、メディアから実動オペレーティング・システムをリストアするベースラインが作成されます。
- 実動システムで SAVSECDTA コマンドおよび SAVCFG コマンドを定期的に実行する。-- これにより、すべてのセキュリティーとデバイス構成のデータが保存され、ときおり使用するオプション 22 バックアップが最新の状態になります。リストアする必要がある場合は、まずベースライン・オペレーティング・システムをオプション 22 バックアップからリストアし、リストアされたシステムをオプション 22 保存以降発生したセキュリティー・データおよび構成変更で更新することができます。
- レプリケートされた HA システムがある場合、HA システムにプログラム・データおよびプログラムライブラリーを定期的に保存するか、オプション 21 保存を実行する。-- 実動システムをアクティブな状態に保ちつつ、回復時のため、必要に応じてデータが保存されます。
- HA システムがない場合、ユーザー・データを保存するための save while active 戦略を調べる。-- save while active テクノロジーの導入については、「Related Stories」セクションの、私のスターターの save while active バックアップ・プログラムをご覧ください。
