IBM i の災害復旧で成功するベスト・プラクティス
災害はその種類や程度こそ異なるものの、不可避でほとんど予測不可能なため、災害復旧を成功させることが会社の業務を継続するためには重要になります。テープ・メディアから情報をリカバリーする場合、すべてのデータを確実にリカバリーするための完ぺきなバックアップ戦略を取ることが重要になります。リカバリー戦略をテストしている、または実際に災害復旧をしているの、いずれにおいても、よくある間違いをいくつか簡単に回避して、リカバリーをできるだけスムーズに行うことができます。そのために、よく見られる間違いのトップ 10 とそれらの回避方法を説明します。
第 10 位: テープ・メディアが 1 セットしかない
リカバリー用のテープ・メディアを 1 セットしか送らないのは、よくある間違いです。メディア・エラーや不完全な保存に備えて、少なくとも常に 2 セットのテープを用意しておく必要があります。バックアップ・メディアを重複してコピーするのが最善のオプションです。また、最新のバックアップとともに、前回のバックアップ・セットもリカバリー・サイトに送ってください。
第 9 位: テープ・メディアのラベルが正しくない
メディアのテープ・ラベルが正しいことを確認し、テープ・ラベル情報には推奨するフォーマットを使用します。付せんなど正しくない、あるいは標準以外のラベルを使用すると、テープやテープ装置を損傷するおそれがあります。ラベルは常に、テープ・メディアの正しい位置に正しく貼り付けられていることを確認します。損傷したラベルや欠けているラベルを交換することが重要です。既存のラベルを剥がしてから、新しいラベルを貼り付けてください。ラベルを再利用したり、バーコード・ラベル上に書いたりしないでください。
第 8 位: テープが管理されていない
テープにデータをバックアップしたら、テープの管理が重要になります。管理をするには、テープ管理システムをバックアップとともに使用して、定義されたポリシー・セットにしたがってメディアを見つけ、追跡し、置き換えます。テープ管理がないと、どのデータがテープ・メディアにあるのか、またはそのメディアの場所がわからなくなり、正に悪夢のような災害復旧になる可能性があります。
Backup Recovery and Media Services (BRMS) は、バックアップおよびリカバリー作業だけでなく、IBM i オペレーティング・システムのメディア・インベントリーすべてを管理する IBM の戦略的製品です。BRMS を使用して、災害または故障中にシステムを完全にリカバリーし、すべてのメディアの作成から期限切れまでを追跡できます。どの項目がどのボリュームにあるか手作業で追跡したり、誤ってアクティブなデータを上書きしてしまったりする心配はなくなります。この製品は、保存した内容、保存日時、保存場所を記録します。リカバリーする必要がある場合、BRMS は正しい情報を正しいテープから正しい順番でリストアします。
第 7 位: テープ・メディアが正しく出荷されていない
テープ・メディアをオフサイト保管用の段ボール箱に投げ込み、リカバリー・サイトに送るなどはとんでもない考えです。梱包が不適切なために輸送中に破損したメディアは、リカバリーの際にメディアが読み取れない状態とわかったとき、苦い経験を味あわせてくれます。
テープ・メディアは常に、本来の梱包あるいはそれよりよい状態の梱包で出荷する必要があります。また、テープ・カートリッジは常に宝石箱に入れて出荷し、輸送中に宝石箱のテープ・カートリッジをしっかりとホールドできる推奨された出荷用コンテナーのみ使用します。しかし、一部の出荷用コンテナーでは、宝石箱を使用する必要はありません。
テープ・メディアを市販の出荷用封筒で出荷しないでください。常に箱またはパッケージに入れてください。カートリッジを段ボールや素材がしっかりした箱に入れる場合、次の点を確認してください。
- カートリッジをポリエチレン・プラスチック・ラップまたはバッグに入れて、カートリッジをほこり、湿気、他の汚染物質から守ります。
- カートリッジが移動しないよう、サイズがぴったりフィットするよう梱包します。
- カートリッジを二重に箱詰めし (箱にカートリッジを入れ、その箱を出荷用箱の中に入れます) 箱の間には詰め物をします。
第 6 位: テープ・メディアのオフサイト保管
バックアップを行う主な理由は、重要データのコピーが災害時に確実に存在するようにすることです。災害は、ハードウェアまたはソフトウェアの障害、停電、自然による要因 (火災、洪水、ハリケーン、竜巻、地震など) など多くの形で訪れます。今日では、テロリストによる攻撃も別のタイプの災害として考慮しなければならなくなっています。したがって、テープ・メディアはオフサイトに保管することが重要です。
どの程度の頻度でバックアップ・メディアをオフサイトに送るかは、リカバリー・ポイント・オブジェクティブ (RPO) により異なります。失ってもかまわない最小限のデータ量が 24 時間分のデータの場合、24 時間ごとにテープ・メディアをオフサイトに移動する必要があります。
多数の中小規模の会社が犯す大きな間違いは、テープ容量の無駄をなくす、またはコストの問題でテープ容量が一杯になるまでオフサイトに送らないことです。テープや出荷コストの節約をするのはもっともだと思われますが、1 週間テープを出荷せずに火災や洪水でテープが破損したら、テープそのものよりはるかに多くのものが失われます。したがって、十分な数のテープを購入し、RPO で必要とされた頻度でオフサイトに送ってください。
テープをオフサイトに送らない別の理由として、ユーザーがデータを削除する、またはバックアップ・メディアから破損ファイルをリストアする場合に、オンサイトでテープに簡単にアクセスできるようにするという点があります。しかし、こうした論法に引っ掛からないでください。災害復旧に備えてオンサイトでリストアし、オフサイトで保管するための答えは、テープのコピーを 2 部作成することです。1 部は必要な場合にすばやくファイルをリストアするため、もう 1 部は災害復旧用です。
ハリケーンなどの災害の間、災害が発生する前にフル・システム・バックアップを行うよう十分な警告が与えられます。しかしハリケーンの間、多くの会社は、いったん自分の地域が避難勧告地域に指定されれば、テープ業者はテープ・メディアを引き取りに来ないことを知りました。
どの程度オフサイトにテープを保管するか検討する必要もあります。自然災害から保護するためには、テープ・メディアは常に、オフサイトの災害リスクのおそれがない地域に保管します。使用する計画があるリカバリー・サイトがある場合、テープがそのサイトに到着するまでシステム・リカバリーが開始できない点を忘れないでください。リカバリー・サイトに近いところにあるリカバリー・メディアにすぐにアクセス出来なければなりません。
第 5 位: リカバリー手順に従っていない
しっかりと文書化されたリカバリー手順があることは、どの IBM i ショップにも不可欠です。IBM i - Systems management - Recovering your system (IBM Redbook SC41-5304-10)、ご使用の BRMS リカバリー・レポート、IBM Business Continuity and Resiliency Services (BCRS) で提供された IBM リカバリー・スクリプト、あるいは自分のカスタム・リカバリー・スクリプトの手順を採用しているかもしれませんね。
最も重要なことは、リカバリーを行っている関係者全員がその手順を徹底的に読んで、従うということです。これは一般常識のように思われるかもしれませんが、スタッフ・メンバーが手順を徹底的に読まず正確に従っていない、手順を省略したり、順序に従ったりしていない、またはユーザーがリカバリー方法を知っていると思い込んでいる場合に、リカバリーは失敗します。決して急いで手順を行わないでください。進め方に不安がある場合は、常に適切な技術担当者に支援を求めてください。
第 4 位: リカバリー・テストがきちんと行われていない
単にシステムのリカバリーをテストしていても、災害が発生した場合に貴方の会社をリカバリーできることをテストしているわけではありません。単にデータをリカバリーできるからと言って、IT 環境をリカバリーし、必要な時間枠で会社活動を再開できることを意味しているわけではありません。IBM i システムのリカバリーは簡単な方です。ネットワーク接続を再確立して、システム上のユーザーにアプリケーションとデータの整合性を検証させることが最も重要です。また災害復旧テスト一式には、災害アラート管理、災害の宣言、通知または電話網、指揮命令系統、報告などがあります。
災害復旧で最も難しい手順の 1 つに、いつ災害を宣言するか判断するプロセスがあります。洪水や火災と異なり、実際にいつ宣言するか判断する材料に乏しい災害もあります。最初にトラブルの兆候があったときに災害を宣言する資格のない人間になりたくないし、何をいつ開始すべきかわかる人がいないという理由でリカバリーの開始を遅らせたくないでしょう。
第 3 位: 保存が不完全である
保存されたデータのみリカバリーできます。保存戦略から外れているデータや保存処理中に排他ロックが掛かっているオブジェクトは、不完全なリカバリーの原因になります。間違っても Save System (SAVSYS) コマンドがシステム上のすべてのものを保存するなどとは思い込んではいけません。SAVSYS は、ライセンス内部コード (LIC)、オペレーティング・システム、ユーザー・プロファイル、デバイス構成オブジェクトのみ保存します。次を実行することで、Save メニュー・オプション 21 でシステム全体を保存します。
- すべてのサブシステムの終了
- ライセンス内部コードの保存
- オペレーティング・システムの保存
- セキュリティー・データの保存
- デバイス構成の保存
- すべてのライブラリーの保存
- すべての文書およびフォルダーの保存
- すべてのディレクトリーの保存
オプション 21 save を利用する大きな利点は、システム上のすべてのものを徹底的に保存するということです。欠点は、保存プロセス中ユーザーは、システムを使用できないということです。
より複雑なバックアップ戦略が必要な、非常に短いバックアップ・ウィンドウがある場合、次の方法のいずれか、または複数組み合わせて使用できます。
- システム情報を非制限状態で保存する。
- 複数のテープ装置を使用してデータを同時に保存する。
- 複数のテープ装置を使用してデータを並行して保存する。
- Save While Active プロセスを使用する。
これらの方法を使用する前に、システム全体の完全なバックアップを取っておく必要があります。では、これらの技法をそれぞれ詳しく見てゆきましょう。
システム情報を非制限状態で保存する。
Save System Information (SAVSYSINF) コマンドは、システムを制限状態にすることなく、SAVSYS で保存されたシステム・データおよびオブジェクトのサブセットを累積保存します。SAVSYSINF は SAVSYS の代替コマンドではなく、システムのアップグレードやマイグレーションに使用するものではありません。
基本 SAVSYS を行った後、SAVSYSINF は次を保存します。
- ジョブ記述、ジョブ・キュー、サブシステム記述、および変更されたコマンドなどのシステム・オブジェクト
- システム応答リスト、サービス属性、環境変数、システム・リカバリーに必要なシステム値、およびネットワーク属性
- *SERVICE にコピーされるオペレーティング・システム PTF ; Change Service Attributes (CHGSRVA) コマンドを使用して、PTF を読み込む場合にサービス属性を変更して、PTF セーブ・ファイルを *SERVICE に自動的にコピーします。
システム・リカバリーの場合、SAVSYS メディアから LIC およびオペレーティング・システムをリカバリーします。次に、SAVSYSINF メディアおよび Restore System Information (RSTSYSINF) コマンドを使用して、保存された変更をシステム・オブジェクトと PTF にリストアします。
複数のテープ装置を使用してデータを同時に保存する。
システムが使用できない時間を短縮するため、一度に複数のテープ装置で保存操作を行います。例えば、ライブラリーを 1 台のテープ装置へ、フォルダーを 2 番目のテープ装置へ、ディレクトリーを 3 番目のテープ装置へ保存できます。あるいは、さまざまなセットのライブラリー、オブジェクト、フォルダー、またはディレクトリーを異なるテープ装置に保存できます。BRMS を使用して、異なるテープ装置に対して複数のバックアップ制御グループを同時に実行できます。
複数のテープ装置を使用してデータを並行して保存する。
並行保存は、非常に大きなオブジェクト、ライブラリー、またはディレクトリーに使用します。この方法では、システムは、オブジェクト、ライブラリー、またはディレクトリーのデータを複数のテープ装置全体に「ばらまき」ます。この関数は BRMS で実装します。
Save While Active プロセスを使用する。
Save While Active (SWA) は、アプリケーションが使用できない時間を著しく短縮し、アプリケーションおよびデータへのユーザー・アクセスを向上させます。SWA によりユーザーは、保存処理が同期チェックポイントに達した後にアクティビティーを再開できます。
SWA 機能を最も簡単に使用するには、SWA チェックポイントに達するまで、ユーザーにアプリケーションおよびデータにアクセスさせないことです。この時点で、排他ロックはすべて解除され、ユーザーは通常のアクティビティーを再開できると同時に、システムはデータの保存を継続します。特に大規模ファイルでは、オブジェクトのサイズではなく数によって、実際のオブジェクトを保存するよりはるかに短い時間で、 SWA チェックポイントに達することができます。
IBM i 6.1 から SWA 関数は、複数の保存に対して単一の Save While Active チェックポイントを提供しています。Start Save Synchronization (STRSAVSYNC) コマンドは、ライブラリーおよび IFS 保存または複数の同時ライブラリー保存に単一の一貫性あるチェックポイントを確保します。SWA を使用する場合、オブジェクトを使用できるようにする前に、プロセスを理解し、あらゆる同期チェックポイントをモニターします。
IBM では、秩序ある方法でのバックアップ管理およびシステム・リカバリーに BRMS を使用することをお勧めしています。BRMS ソリューションは、保存戦略に組み込まれていない項目およびオブジェクト・ロックのため保存されていないオブジェクトを識別します。BRMS はバックアップおよびリカバリー戦略の代替手段ではありません。戦略を実装するのに使用するツールです。BRMS または他の製品を使用してバックアップを開始する前に、バックアップおよびリカバリー戦略を計画しておく必要があります。
第 2 位: 「特殊な」リカバリーでリカバリーをテストしている
リカバリーのテストにおける大きな間違いは、いつものバックアップ・テープを使用していないことです。例えば、リカバリー・テストのみにオプション 21 save を行うなどです。これを行えば、データのリカバリーに使用するバックアップ一式を確実に手に入れていることになります。特殊なバックアップでリカバリーをテストするのはトラブルの元です。
定期的な月次、週次、日次のバックアップに問題があり、テストするだけの信頼性がないと思った場合、実際に災害が発生している中で、どのようにこれらのバックアップをリカバリーできるでしょうか。答えは、「できません」です。我々は人間であるということも覚えておいてください。そのため、どのデータがバックアップに必要かわかっていても、バックアップを誤ってセットアップする可能性があるのです。オプション 21 save など特殊なバックアップを行う場合、月次、週次、日次のバックアップで求めるすべてのデータを本当に取得できるのでしょうか。オプション 21 restore ですべてのデータをリカバリーし、リカバリー・テストが成功しても、定期バックアップがどのように行われるのか、また実際の災害でリカバリーできる内容をテストしているわけではありません。
リカバリー・テストを成功させるための重要な要素は、定期的な月次、週次、日次のバックアップで使用しているテープ・メディアを使用してテストすることです。これにより、すべてのシステムのすべてのデータを確実にリストアし、異なるシステムに対して完全なリカバリー・テストを実行できます。
第 1 位: リカバリー戦略をテストしていない
実際にシステムのリカバリーをテストしていない場合、システムをリカバリーできるかどうか実際にはわかりません。制限付きのリカバリー・テストを行う誘惑にかられたとしても、そのようなテストでは実際に何が起きるかを教えてはくれません。
小規模の会社がバックアップのテストを拒否しても驚くにあたりません。しかし、多くの大規模ショップがこうした罪を犯していることは非常に驚きです。彼らはバックアップをセットアップし、自動化し、実行して、リカバリーの必要がない場合はそれでよしとしてしまいます。バックアップが大丈夫と本当に考えているなら、今すぐシステムを完全にリカバリーできるのは気分がいいと思いませんか。思わないなら、なぜ思わないのでしょう。たとえどれだけバックアップが包括的であると思っても、実際にテストしてみるまでは動作するか決してわからないのです。バックアップを本当に検証するなら、リカバリーをテストする必要があります。
テープを使用した災害復旧への優れた代替手段
災害復旧にテープ・メディアを使用すると、早さという点で会社のリカバリー時間オブジェクティブ (RTO) に制限が課せられます。テープの出荷および再収集、テープ・メディアからの実際のリカバリーなどにより、テープ・メディアでは必要な RTO を満たすことができない場合があります。RPO の観点から、最新のバックアップは最長 24 時間古い可能性があり、使用できる最新のテープ・メディアは最長 48 時間古くなります。テープ・メディアでは連続してバックアップできません。そうではなく、ある時点だけのバックアップおよびリカバリーとなります。こうした理由で、多くの会社、特に実際に災害を経験した会社は、テープを使用したリカバリーより優れた代替方法である、論理レプリケーションに移行しました。
ソフトウェアを使用した論理レプリケーションは、IBM i での高可用性 (HA) および災害復旧両方で最も一般的なソリューションです。高可用性 ISV ソリューション・パッケージまたは IBM i 向け IBM の iCluster 製品を通して導入します。論理レプリケーションで、実動システムとバックアップ・システム上のオブジェクトを同一に保ちます。オブジェクトをジャーナリングすることで、ジャーナルの変更を適用することによりソース・システムのトランザクション操作はターゲット・システムで複写されます。ジャーナリングされないデータについては、変更データが保存され、ターゲットに書き込まれます。論理レプリケーション・ソリューションはこれらのアプライ・プロセスをターゲットに提供します。
すべてのジャーナル・オブジェクトについて、リアルタイムあるいはリアルタイムに近いレプリケーション (同期遠隔ジャーナリング) が行われます。通常、ファイルなどのオブジェクトがジャーナリングされると、レプリケーションはレコード・レベルで処理されます。ジャーナリングされないユーザー・スペースなどのオブジェクトについては、レプリケーションは通常オブジェクト・レベルで処理されます。この場合、オブジェクトへの変更のセットがそれぞれ完了した後にオブジェクト全体がレプリケートされます。
論理レプリケーションを使用して効率性と信頼性を達成するベストな方法は、同期遠隔ジャーナリングを実装することです。遠隔ジャーナリングを使用して、IBM i オペレーティング・システムは、ジャーナル・レシーバーに新しく届いたデータを継続してバックアップ・システムのジャーナル・レシーバーに移動します。この時点で、選択されたソフトウェア・ソリューションはジャーナル・アップデートをやり直し、アップデートをバックアップ・システムのオブジェクトに配置します。いったんジャーナル環境を構成すると、同一のオブジェクトが 2 つ作成されます。1 つは実動システム、もう 1 つはバックアップ・システムにできます。
災害が発生した場合、このソリューションはロール・スワップ操作によりバックアップ・システムの実動環境を迅速にアクティブにできます。リカバリーに論理レプリケーションを使用する最大の利点は、バックアップ・システムのデータが稼働中であり、バックアップに切り替えるときに最小限のリカバリー手順で済むということです。また、バックアップ・システムにアクセスして日次バックアップを行ったり、レポート作成など読み取り操作を行ったりすることができます。
災害リカバリー・フェイルオーバー・プロセスは通常 30 分未満で終わりますが、10 分間でフェイルオーバーを達成したユーザーもいます。実際に、ジャーナル・レプリケーションの方向の切り替えは 1 分未満で済み、バックアップとして稼働している間でもすでにデータベースにアクセスして読み取ることができます。30 分未満のフェイルオーバーは、フェイルオーバー前に累積された可能性があるジャーナル・アプライで考えられる時間差を悲観的に見たものです。30 分の見積もり時間内では、ユーザーがシステムにアクセスできるようになる前にデータの同期チェックも行う時間があります。まとめると、論理レプリケーションのフェイルオーバー時間が最短です。理由は、アプリケーションがオンラインになったときに、バックアップ・システムのデータがすでにアクティブで、使用できるようになっているためです。
論理レプリケーションで考慮する重要な点は、レプリケーションで発生する可能性がある待ち時間です。待ち時間は変更がソース・システムに行われた時間と、それらの変更がバックアップ・システムで使用できるようになった時間の時間差です。同期遠隔ジャーナルはこれを大幅に軽減します。選択する伝送メカニズムに関係なく、伝送量を的確に予測し、通信回線と通信速度の大きさを正しく設定して、使用している環境が月末処理などピークに達したときのレプリケーション量を管理できるようにすることが重要です。通常、論理レプリケーション・ソリューションは、レプリケートしているデータ量に対して通信回線と速度の見積もりが適切でない場合に、ニーズを満たすことができなくなります。
定期的なテストがカギ
テープを使用したリカバリーが、貴方の会社のニーズを満たそうと、リカバリー・ポイントとリカバリー時間の改善を考え論理レプリケーションを採用しようと、リカバリーを成功させるための最も重要な要因は、定期的にリカバリーをテストすることです。そうすることで、こうした上位 10 個の間違いを避けることができます。
