災害時の復旧対策の準備は十分ですか？｜e-bellnet.com（IBM i （AS/400）ユーザーのための関連技術情報サイト）

IBM i 資料集

IBMｉ海外記事2008.04.10

災害時の復旧対策の準備は十分ですか？

ブライアン・ボーナー著

あなたが管理するシステムが災害に見舞われたときの対策の準備は整っていますか。たった一度の出来事で、絶好調だったビジネスがつまずくこともありえます。本稿を執筆するにあたり、災害時の復旧対策を専門とするサポートセンターの担当者として、私は他の専門家から情報を入手し、彼らからの返答をいくつか取り入れました。本稿では、災害発生時にすばやく対策をとるために必要な一般的な知識をご紹介します。

災害時の復旧対策をする際にはさまざまな事項が関わってきますが、簡単なチェックリストではバックアップ計画と復旧計画のみを取り上げます。

バックアップ計画

災害時の復旧対策の中でも、バックアップ計画は最重要項目であり、実行すべき最も重要なシステム・オペレーションの一つです。何故でしょうか。それは、データを失ってしまったら復旧できないからです。それ以上の理由があるでしょうか。

バックアップ計画は、簡素なものにも複雑なものにもすることができます。しかし、あなたがどのようなタイプの環境をお持ちでも、ミッション・クリティカルなデータを毎日バックアップする必要があります。

まず、システムが提供するバージョンのシステムの完全保存で実行される保存コマンド(GO SAVE option 21)の、さまざまなオプションを考察してみましょう。

SAVSYS
SAVLIB LIB(*NONSYS)
SAVDLO
SAV

SAVSYS
SAVSYSコマンドに関するよくある誤解は、その名前に起因するものです。SAVSYSはシステム全体を保存するわけではありません。誤解を生みやすいために、サポート担当者と話をする際に「SAVSYS」という単語を口にすると、その担当者はSAVSYSとシステムの完全保存との違いを明確にしてほしいと聞いてくるでしょう。

SAVSYSコマンドでは、ライセンス内部コード(LIC: Licensed Internal Code)、オペレーティング・システム、ユーザー・プロファイル、構成オブジェクトの4つが対象となります。

LICはオペレーティング・システムの下層にあるコードです。LICとオペレーティング・システムはともに、SAVSYSコマンドだけで保存することができます(この他にも例外的な方法がいくつかありますが、お勧めできる方法ではないのでここでは紹介しません)。

オペレーティング・システムは*BASE OSのみで、他のライセンス・プログラムを含みません。

ユーザー・プロファイルはSAVECDTAコマンドで保存できます。このコマンドはSAVSYSコマンドに含まれています。また、SAVSECDTAコマンドはパスワード、権限リスト、権限ホルダーも保存します。

構成オブジェクトはSAVCFGコマンドで保存できます。このコマンドはSAVSYSコマンドで利用できます。このコマンドでは、デバイス、コントローラ、ラインなどといった記述(リソースへの紐付け)が対象となっています。たとえば、テープ・ドライブの記述(例: TAP01)などがこれにあたります。

SAVLIB LIB(*NONSYS)
ここでもこのコマンドの名前が誤解を招きやすいものとなっています。*NONSYSにはシステムの重要なライブラリと、システムのものではないライブラリが両方含まれています。*NONSYSという名前がついているのは、QDOC、QDOCxxxx、QRCYxxxxx、QRECOVERY、QRPLOBJ、QRPLxxxxx、QSPL、QSPLxxxx、QSRV、QSYS、QSYSxxxxx、QTEMPなどの正式な「システム」ライブラリ以外の全てのライブラリを保存するからです。ただし、システムの重要なライブラリも対象となっています。SAVLIB LIB(*NONSYS)は、*IBMと*ALLUSRという2つの特別な値の組み合わせになっています。

SAVLIB LIB(*IBM)は、ユーザー・データを含んだライブラリ以外のIBMが提供しているすべてのライブラリを対象とします。

SAVLIB LIB(*ALLUSR)は、(QUSRSYSなどの)ユーザー・データを含んでいるためにユーザー・ライブラリとみなされる一部のライブラリを除き、Qという文字で始まらない全てのユーザー・ライブラリを対象とします。これらのライブラリの一覧については、SAVLIBコマンドのLIBパラメータ上でF1キーを押して表示されるヘルプ・テキストを参照するか、またはWRKLIB *ALLUSRを発行してください。(注記: Qという文字で始まるライブラリを誰かが作成した場合、*ALLUSRコマンドの一部としてはそのライブラリは保存されません。)

SAVDLO
DLOとは、Document Library Object(ドキュメント・ライブラリ・オブジェクト)の略です。DLOにはドキュメントとフォルダが含まれ、これらは元々メール(配布オブジェクト)が保存されていた場所になります。DLOは依然として使用されていますが、ほとんどのオブジェクトはIFS中に存在し、次のコマンドで記述されます。
WRKFLRコマンドを発行することでDLOを確認することができます。

SAV
SAVコマンドはIFSを保存します。IFSは、ディレクトリやディレクトリ・オブジェクトが存在している場所です。今日の多くのシステムでは、(運用ライブラリ中ではなく)IFSに大量のデータが保管されています。

V3R2以前のバージョンではIFSがありませんでしたが、システムの重要な部分となっています。したがって、昔のCLやアプリケーションを使用してバックアップを実行する場合は、IFSも対象となるように更新してください。V3R2はかなり昔のバージョンですが、IFSが存在する前に作成されたスケジュール・バックアップだったため(あるいは作成者がライブラリだけが重要であると勘違いしたため)にIFSが対象となっていなかった災害時の復旧対策を何度か経験したことがあるので、ここで敢えて触れました。

バックアップ戦略の選択

では、あなたにとってベストなバックアップ戦略とは、どんなものでしょう。一言で答えるとすれば、重要なデータを含んだシステムの可能な限りを対象として、できるだけ頻繁にバックアップを作成すべき、となるでしょう。

毎晩システムの完全バックアップを実行できるだけのバックアップ・ウィンドウが確保できれば、毎晩システムの完全保存を実行すべきです。バックアップが1本のテープに収まらず、オペレータが途中でボリュームを交換する必要がある場合でも、セキュリティよりも手軽さを優先してはいけない、ということを思い出してください。

手軽さを優先するのではなく、テープ・ライブラリや仮想テープ(V5R4以降の場合)などといった他の方策を検討してください。(SystemiNetwork.comの2007年1月、20780の記事「仮想テープ：真の意味での取り決め」を参照。)誰の予算にも限りがありますが、適切なバックアップがなかったらいかに余計にコストがかかるかを統計的に見てみれば、納得できるでしょう。システムの完全バックアップが作成されていれば復旧は最も簡単になりますし、小規模なシステムであればこれが一番速い方法である場合がほとんどです。

システムの完全バックアップを毎晩作成することが困難な場合は、少し頭をひねらなければなりません。多くの場合、バックアップを複数回に分けて実行するということになります。では、どの部分のバックアップをどれくらいの頻度で実行すべきなのか、どのように決めたらいいのでしょうか。

バックアップ戦略を計画するとき、まずシステム管理者が誤った質問をしてしまうことがよくあります。たとえば、「ダウンタイムはどれくらいまで許されるのか」とか、「最小限の予算で入手できる最高速のドライブはどれか」といった質問です。

こういった質問をするかわりにまず、「システム全体が使用不能になった場合、重要なデータについてどれくらい古いデータで運用が続けられるか」と、問うべきです。次の質問は、「ビジネスに損害が出ない範囲で最大どれくらいまでダウンタイムを許容できるか」となるでしょう。この２つの質問から、バックアップ戦略の計画を開始することができます。

データを、重要なユーザー・データ、重要でないユーザー・データ、システム・データの３つのカテゴリに分けて一覧にするといいでしょう。バックアップ・ウィンドウが狭い場合は、この一覧は重要度の高い順に並べておきます。

重要なユーザー・データ
とは、(受注データや財務データなど)ビジネスを遂行するにあたって重要なあらゆるデータです。重要なユーザー・データは毎日バックアップを作成すべきで、場合によっては１日に何度か作成すべきです。たとえば、3時間以内の重要なユーザー・データを喪失することが許されないのであれば、最低限3時間ごと(1日8回)バックアップを作成すべきです。

重要でないユーザー・データ
とは、ビジネスに関係したデータではあるものの、喪失したとしても壊滅的な損害にはつながらないものです。ある種のユーザー・データは、一つのシステムでは重要ではなくても他のシステムでは重要な場合があります。アプリケーションのカスタマイズや履歴項目が対象になる場合もありますし、ならない場合もあります。

システム・データ
は、配布メディアや他のシステムからいつでも復旧できるので、最も重要度が低いデータです。しかし、復旧に必要な時間が問題となる場合は、システム・データを何らかの方法で保存しておくことが重要な場合があるかもしれません。システム・データには、LIC、オペレーティング・システム、*IBMのプログラム・ライブラリ、ライセンス・プログラム・ライブラリ、IBM DLO、IBMディレクトリ(/QIBM/ProdData および、/QOpenSys/QIBM/ProdData)が含まれます。システム・データは、通常はそれほど頻繁に変更されませんので、バックアップ・ウィンドウが狭いようであれば、それほど頻繁にバックアップを作成する必要はありません。

バックアップ・ウィンドウが狭い場合は、バックアップのパフォーマンスも重要になってきます。バックアップのパフォーマンスを迅速化するためのオプションをいくつか以下に示します。

より高速なハードウェア(テープ・ドライブ、光ケーブル、高速なIOA/IOPカード)を使用する
ハードウェア用の最新のファームウェアをインストールする
メモリを増やす
プロセッサやCPWを増やす
最新のPTFをインストールする
システム稼動が最も少ない時間帯にバックアップを実行する
稼動状態のまま保存する方法を検討する
複数のテープ・ドライブの使用を検討する
仮想テープの使用を検討する(より高速にするには適切な設定が必要)
変更されたオブジェクトだけを保存することを検討する
保存コマンドのDTACPRとCOMPACTに*DEVを指定する
パフォーマンス・アジャスタ(システム値QPFRADJ)やサード・パーティー製のチューニング・ツールを使用する
並列バックアップの実行を検討する

バックアップ戦略を設定するときは、復旧時に時間が節約できるように、いずれかの時点でシステムの全ての部分が保存されるように設定してください。また、メディアに項目がどのように保存されるかについても注意を払ってください。データやシステムを復旧する特定の順序というものがあるからです。(これについては後述します。)

一般的なバックアップ戦略例を以下に示します。ただし、これは一例であり、環境によっては必ずしも最善の選択肢ではないかもしれないということを忘れないでください。バックアップ戦略の計画にはじっくり時間をかけるようお勧めします。コンサルタントに相談するのもいいかもしれません。

日次 ― 重要な運用ライブラリの変更されたオブジェクトの保存。重要な運用ディレクトリに対するSAVの実行。
週次 ― 重要な運用ライブラリ、重要でないユーザー・ライブラリ、重要なユーザー・ディレクトリの完全保存。
月次 ― システムの完全保存。

また、バックアップが正常に完了したことを検証する必要もあります。バックアップがチェックされていないためにバックアップが正常に完了していないかもしれないと気づくサポート・センターの担当者が時々います。スケジュール・バックアップのジョブが通常通りに終わっているように見えるからといって、バックアップが正常に終了していると勘違いするのはよくあることです。

バックアップが正常に完了しているか否かを検証する方法はいくつかありますが、最善の方法はジョブ・ログを見てみることでしょう。探したい情報がはっきりしている場合は、DSPTAP DATA(*SAVRST) OUTPUT(*PRINT)を使用して、保存した全てのオブジェクトのスプール・ファイルを作成できます。(IFSオブジェクトは別の出力先に一覧にされます。)

システムの完全保存を実行しているのであれば、IBMのナレッジ・ベース・ドキュメント387819982を参照して履歴ログを検索し、バックアップが正常に完了しているかどうかをすばやく検証してください。保存されなかったものがある場合に原因を調べるには、実際のジョブ・ログ自体が(詳細なログ・レベルで)必要となります。システムの完全保存を実行していない場合でも、ドキュメント中のメッセージIDは有用です。

DSPLOG PERIOD(('xx:xx:xx'
　'dd/mm/yy'))
MSGID(CPC3702 CPC3707
　CPC9410 CPC370C CPF3771
　CPF3777 CPF9410 CPF3837
　CPC2356 CPF2361)

バックアップが正常に作成されていることが確認できたら、メディア自体に不良が発生したときに備えてコピーを作成しておくとよいでしょう。少なくとも１つはオンサイトに保管し、もう１つは別の場所に保管することをお勧めします。仮想メディアを使用している場合は、物理メディアの複製も作成して別の場所に保管するか、または少なくともイメージか仮想ボリュームを別のサイトに設置されている別システムに送信しておくのがよいでしょう。

バックアップの１つはすばやく復旧できるようにオンサイトに置き、サイトが災害に見舞われて物理システムやメディアが全滅してしまったときのために、別のコピーを別の場所に保管しておきます。別の場所をどこにするかは重要な判断となります。データを安全に保管し復旧がすばやくできるかどうかが決まるからです。

復旧計画

実際に災害が発生したときに貴重な時間を無駄にしないために、災害時の復旧計画に今すぐ時間をかけるべきです。次の5つの「W」の質問に答えていくことで、災害時の復旧の基本的なステップがわかります。

Why？
問題の原因が分かれば、通常はすばやく解決できます。

たとえば、ある朝出社したらシステムがダウンしていた。だからといって、災害が発生したとは言わないでしょう。まずは、問題を引き起こした原因は何かを知りたいはずです。以前お客様から伺った話ですが、夜中にシステムがダウンしたので原因を調べてみたら、清掃担当者が掃除機をかけようとしたところコンセントが足りないので電源プラグを引き抜いたことが原因だとわかりました。この場合は、単に電源プラグを挿し直してIPLを実行すればよかっただけでした。

また、システムにサインオンしたときに全てのユーザーでエラーが発生していれば、これは大問題だと判断するかもしれません。が、最初のメニューに対する権限の問題に過ぎないかもしれません。問題の原因が判断できたら、あるいは原因の究明にこれ以上時間がかけられないのなら、何を復旧するかを判断する時です。

What？
何を復旧すべきかを判断するのが、おそらく一番大事な復旧のステップです。この判断によって、どのように復旧するかが決まります。

まず、復旧するデータが重要なユーザー・データなのか、重要でないユーザー・データなのか、システム・データなのかを調べます。データの重要度に応じて、システムを稼動状態にしたまま復旧するのか、システムを制限された状態にするのか、他のシステムに復旧するのか、決定します。(これは復旧の前に決定すべきですが、おそらくバックアップ計画前に決めておくべきでしょう。)

重要なデータを一覧にし、そのデータが失われたら運用にどんな影響があるかを調べます。各データがバックアップ・ステップのどの段階に保存されるのかを調べます。これにより、そのデータをいつ復旧したらよいのかがわかります。

When？
システムを稼動状態に保ったままデータを復旧できる場合は、すぐにそのデータを復旧してください。データを復旧する間、システムの他の部分をシャットダウンする必要がある場合は、問題となっているデータを今すぐに復旧することのほうが重要なのか、運用の残りが停止できる状態になるまで待ったほうがよいのかを判断します。ハードウェアやソフトウェアなどが原因でシステム全体が影響を受けている場合は、すぐに復旧に取りかからなければなりません。

Where？
障害が発生したシステムと同じシステムに復旧する場合は、「どこを復旧するか」が問題になります。ただし、障害が発生したシステムと同じシステムに復旧できないかもしれない場合に備えた計画を、常に作成しておくべきです。この検討には十分時間をかけることになるでしょう。

万が一、障害が発生したシステムとは別のシステムに復旧する必要がある場合、そのシステムで利用できるようにしておく必要のあるものは何かを決めておきます。これを同じ部屋にあるバックアップ・システムまたはパーティションとしても構いませんし、別の部屋にあるシステム、あるいは地理的に別の場所にあるシステムでも構いません。自然災害に見舞われた場合、同じ場所にあるシステムはいずれも損害を受ける可能性が高いでしょう。多くの企業が災害時の復旧対策用サイトを備えるようになってきているのは、こうした理由によるものです。

どのサイトがいいのかはどのようにして決めるのでしょうか。テクノロジに関するその種の質問への答えと同様に、条件によって異なる、というのが答えです。以下のような要件を考慮に入れて検討する必要があります。

移動時間
電源要件
ハードウェアの互換性
セキュリティ要件
システムの可用性
技術的支援
使用コスト

Who？
今まで述べてきたような項目が全て決まったら、復旧作業を誰が実施するかを決定します。この作業担当者は、復旧作業を実施するのに十分な権限と経験を持った人とすべきです。また、この作業担当者が復旧作業を万一実行できないときに備えて、バックアップ要員を何人か配置しておくべきでしょう。

十分な技術スキルを備えた要員がいない場合(あるいは要員がいたとしても)、災害時の復旧対策の専門家を事前に探して決めておいたほうが賢明でしょう。誰を選ぶにしろ、災害時の復旧対策のテストを実行した人と同じ人であることが重要です。

災害時の復旧対策のテスト

保存/復旧担当チームに災害時の復旧対策で最も注意すべき事項は何かと尋ねたところ、75%の人が同じことを答えました。「本当の災害発生時を想定してテストすることである」と。

実際に災害が発生したときと全く同じテストをしてください。つまり、実際に復旧作業を担当するであろう人たちが、復旧作業のテストを実行してください。システムの完全保存をするだけではなく、月次、週次、日次など全ての保存を実行してください。

災害に襲われたとしたら最も厄介だと思われる時間帯を選んで、その時間に復旧のテストを開始するようにしてください。実際に災害が発生したときに復旧の対象となるシステムとは整合性のない、プリロード・システムや一時的システムを有しているという災害対策サイトが、非常に多くあります。実際の災害時復旧シナリオと全く同じように設定されているターゲット・システムを準備してください。そして、LIC以外のものはプリロードしないように警告しておきます。

災害時の復旧対策テストは、全てが正しくなっているかを確かめるための絶好の機会です。災害時の復旧対策テストを既に実施済みで、システムや災害対策サイトに大きな変更が必要であることがわかったら、再度テストしてください。テスト中に問題を発見したら、それを記録、修正し、復旧手順を調整して、復旧をよりよく、より速く完了できるものに改善してください。

サポート・センターに寄せられる質問や問い合わせは、クライアントが災害時の復旧対策テスト中に発見した問題に関するものがほとんどです。そしてこのような問い合わせは、実際に災害に見舞われたときに受ける問い合わせとは異なるものなのです。

復旧ステップの順序

復旧ステップは、保存がどのように行われたかによって異なります。バックアップと復旧のガイド、復旧のテスト、その他の復旧時のレポートを活用してください。システムを復旧する際の主なステップを、以下に順に示します。

LICを復旧する(save = SAVSYS)
オペレーティング・システムを復旧する(save = SAVSYS)
GO RESTOREを実行する(option 21 ― 下記の手動ステップを参照)
必要があればPTFをインストールする
システムのB側でIPLを実行する

GO RESTOREの手動ステップは次の通りです。

ユーザー・プロファイルを復旧する ― RSTUSRPRF (save = SAVSYSまたはSAVSECDTA)
構成オブジェクトを復旧する ― RSTCFG (save = SAVSYSまたはSAVCFG)
ライブラリを復旧する ― RSTLIB (save = SAVLIB)。ここではIBMライブラリ(SAVLIB *NONSYSまたは*IBM)およびユーザー・ライブラリ(SAVLIB *NONSYSまたは*ALLUSR)が対象
DLOを復旧する ― RSTDLO (save = SAVDLO)
IFSを復旧する ― RST (save = SAV)
スプール・ファイルを復旧する ― 使用するコマンドはリリースと使用するプログラムによる
権限を復旧する ― RSTAUT (saveコマンドはなし。メディア不要)

よくある問題点

実際に災害に襲われたときではなく、災害時の復旧対策テスト中に全ての問題点を洗い出したほういいでしょう。サポート・センターに寄せられる、よくある問題点のいくつかを以下にご紹介します。

ユーザー・データのバックアップの一部が正常に終了していない
保存する必要のあるものが保存されるように、バックアップが正しく設定されているか確認してください。また、バックアップが正常に完了しているか検証してください。

どのデータがどのテープに保存されているのか不明
メディアにはラベルを正しくつけてください。保存用コマンドでは、OUTPUT(*PRINT)を指定して、保存されるオブジェクトのスプール・ファイルを作成することができます。また別の方法としては、DSPTAP OUTPUT(*PRINT)を使用して、必要な詳細レベルに応じてDATAを*LABELSまたは*SAVRSTとして指定してください。

最善の方法は、BRMSなどのメディア管理プログラムを使用することです。メディア管理プログラムはデータベースを使用して、メディアとそのコンテンツを記録してくれます。

ターゲット・システムと互換性がない、もしくはターゲット・システムが正しいシステムではない
ターゲット・システムのハードウェアが、OSやアプリケーションに対応できることを確認してください。

ターゲット・システムのテープ・ドライブに互換性がない
ターゲット・システムのテープ・ドライブが保存用テープと互換性があることを確認してください。システムを復旧する際に使用するのはこのドライブですから、この確認はとても重要です。

ターゲット・システムがプレインストールされている
災害時の復旧対策もしくは移行の際に最も多い問題が、ターゲット・システムに既にLIC、オペレーティング・システム、ライセンス・プログラムがインストールされているというものです。これは、PTFレベルに適合性がない、ライブラリQSYS中にユーザーやライセンス・プログラムのデータがない、ファイルが重複して存在する可能性がありポインタやアドレスのエラーを引き起こす可能性がある、などの問題につながります。

災害時の復旧対策では、LIC以外のものがインストールされていないこと、ディスクが適切な外部記憶プールに追加されていること、を確認してください。こうしておけば、何もない状態からディスク装置を追加するための時間を節約できますが、それでもLICはバックアップ・メディアから再インストール/復旧し、次にその他のデータをバックアップ・メディアから復旧する必要があります。

代替のIPLデバイスを使用する際の問題
代替のIPLデバイスとしてターゲットのテープ・デバイスを使用する(バックアップ・デバイスから直接IPLを実行してLICをインストールする)と、問題が発生することがあります。この問題に突き当たったときは、問題をデバッグして修正するよりも、そのデバイスを代替インストール・デバイスとして設定するほうがずっと速く解決できます。唯一違うのは、システムがLICメディアからIPLを実行して「ブート」できるようにLICメディア(I_BASE_01)を光学式ドライブで読み取らせ、次にテープ・ドライブを代替のインストール・デバイスとして選択しなければならないという点です。

使用するメディアがオリジナルの配布メディアであることを確認してください。また、光ケーブルが接続されているテープ・ドライブを代替のIPLデバイスとして使用することはできないので、代替のインストール・デバイスとして使用する必要があるという点にも注意してください。

パスワードが間違っている、またはパスワードを忘れた
テープからインストールする際には、テープ上にあるパスワードを使用しなければなりません。パスワードを忘れてしまって、パスワードを変更する権限のあるユーザーとしてサインオンできない場合は、DST QSECOFRプロファイル(i5/OS QSECOFRプロファイルとは異なる)を使用してDedicated Service Tools (DST)にサインオンし、i5/OS QSECOFRパスワードをリセットします。

ただし、このパスワードも忘れてしまった場合は、配布メディアを使って何もない状態からシステムをインストールしなければなりません。再インストールではセキュリティ・データが上書きされないからです。裏口はありません。

構成オブジェクトが正しいリソースを指し示していない
障害が発生したシステムとは異なるシステムに復旧するときは、GO RESTOREコマンドのoption 21パラメータに、「Restore to a different system = Y」を指定することが重要です。復旧用のコマンドを手作業で発行する場合は、ALWOBJDIF(*ALL)を指定し、RSTCFGコマンドにSRM(*NONE)を指定してください。

重複/拡張ファイルが作成されてしまった。
ターゲット・システム上に既にデータが存在し、復旧時にALWOBJDIF(*YES)を指定したらファイルレベルの問題が発生した場合、システムはこれを無視して拡張子*0001を追加して、ファイルの名前を変えます。

ターゲット・システムにはデータが存在していないことを確認してください。もし存在していたら、バックアップと復旧のガイドの同期に関する章を参照してください。

復旧されない権限がある
ターゲット・システムにデータを復旧するときは、正しい順序で復旧することが重要です。オブジェクトを復旧する前にRSTUSRPRF *ALLを実行し、次にオブジェクトが復旧されたらRSTAUTを実行して、全ての権限と権限リストが正しい状態にしてください。

NPTFのレベルの不整合
PTFはバグの修正です。これを適用しないと、システムが予期せぬ結果をもたらすことがあります。LIC、オペレーティング・システム、ライセンス・プログラムに対して同じメディアからPTFをインストールすることが重要です。その理由は、ライセンス・プログラム製品のPTFは、前提とするLICやOSのPTFファイルに依存している場合があるからです。そうしたPTFが適用されていないと、ライセンス・プログラムのPTFが期待しているコードは存在しないことになります。

PTFはオブジェクトに含まれているので、テープからシステム全体を復旧する場合は、PTFも含まれます。PTFが含まれていなければ、最新のcume/group/individualセットから再インストールしてください。

ライセンス・プログラムが正しくインストールされない。
ライセンス・プログラムをインストールするときは、そのプロセスの一部として、特定のメニュー、コマンド、ユーザー空間オブジェクトをQSYSライブラリにコピーします。オペレーティング・システム(QSYSライブラリ)を光学式メディアからインストールした場合は、その後ライセンス・プログラムが復旧されたのであって「インストール」されたわけではないので、QSYSには何もコピーされていないため、上記のオブジェクトは存在しません。

このような場合には、オペレーティング・システムをバックアップ・メディアから再インストールするか、またはGO LICPGM option 1でライセンス・プログラムを全て再インストール(current = Yであれば置換)してください。ただしこの場合、PTFを全て再インストールする必要もありますので、オペレーティング・システムをバックアップ・メディアから滑り込ませる(再インストールする)ことをお勧めします。

ライセンス・プログラムとサード・パーティー製アプリケーションの初期化やセットアップ。
ライセンス・プログラムやサード・パーティー製アプリケーションの中には、復旧のしかたによっては追加のセットアップや初期化が必要なものがあります。こうしたプログラムやアプリケーションの提供元に連絡し、文書化してテストしておいてください。

将来に備える

ビジネスの未来を守るためには、災害時の復旧対策の計画は必要不可欠です。実際のところ最も重要なのは、バックアップの計画をたてることです。重要なユーザー・データはビジネス上最も重要なデータであり、再作成ができない場合もあります。ユーザー・データのバックアップが作成されていれば、システムが災害に見舞われても復旧できるはずです。

災害時の復旧対策の計画を作成するときは、「W」で始まる5つの質問、Why、What、When、Where、Whoに対する答えをきちんと検討してください。互換性、メディアからの取り出し時間、セキュリティなどといった事項も考慮してください。災害時の復旧対策の計画が完成したら、実際に災害が発生した場合と全く同じように、必ずテストしておきましょう。