新しい投稿
記事
· 2024年5月16日 26m read

外部バックアップの仕組みとバックアップとリストア方法について

#システム管理 #バックアップ #ヒントとコツ #Caché #Ensemble #Health Connect #HealthShare #InterSystems IRIS #InterSystems IRIS for Health

開発者の皆さん、こんにちは。

この記事は、「インターシステムズ製品をバックアップする前に確認したいこと」に続く記事で、InterSystems製品のバックアップの手法の中の「外部バックアップ」の仕組みと、バックアップ・リストア手順について解説します。

まず、「外部バックアップ」とは、InterSystems製品の専用ルーチン使用せず、InterSystems製品以外のバックアップソリューションを使用してデータベースをバックアップする方法で、現時点の推奨されるバックアップ方法です。

詳細な説明、手順については、ドキュメント「外部バックアップ」をご参照ください。

外部バックアップでは、主に、論理ディスク・ボリュームの有効な "スナップショット" を迅速に作成するテクノロジと共に使用します。

例えば、

  • Windowsサーバの場合は、VSS（ボリューム・シャドウ・コピー・サービス）と組み合わせて利用する
  • AWSのEBS Snapshotと組み合わせて利用する

スナップショット・テクノロジが使用できないシステムであっても、後述する「特別な考慮」で対応できればご利用いただけます。

それでは早速、外部バックアップの前後で必要となるIRIS側の手続きと、バックアップとリストアについて確認していきましょう！

 

外部バックアップ前後で必要となる処理（ライトデーモンの一時停止と再開）

最初に、外部バックアップを実行するために、データベースに未反映の更新ブロックをデータベースに書き込む必要があります。

InterSystems製品では、ライトデーモン（WRTDMN）というシステムプロセスが、データベースに加わった変更をデータベースに書き込む一連の流れを管理しています。

通常時ライトデーモンは、以下の順序でデータベースに更新データを反映します。

① データベースキャッシュにたまった更新ブロックをライトイメージジャーナルファイル(WIJ)に退避し、正常に退避が完了すればリカバリ判定フラグをセットします。

更新ブロックのWIJへの退避が完了すると

② データベースファイルに更新ブロックを反映し、反映が正常に終了するとWIJにつけたリカバリ判定フラグをリセットします。

ライトデーモンは一定間隔（*）で①～②の処理を繰り返し実行します。

(*) この間隔はシステムにより短い頻度に変更される場合もあります。

外部バックアップを実行する場合、データベースへ書き込みを命令するライトデーモンの動作を止めない限り、正常なデータベースの退避が行えません。

タイミングが悪いと、②でIRIS.DATに反映させているブロックが一部のみの状態のデータベースファイルを退避してしまう可能性があり、このデータベースファイルを利用してリストアを行うことでデータベース壊す可能性があります。

この理由から、外部バックアップを実行する前にライトデーモンの処理を一時的に凍結させた状態でスナップショットを取り、スナップショットの取得が終了したらライトデーモンを凍結解除する手続きを行う必要があります。

外部バックアップ前後で利用するメソッドは以下の通りです。

 

ライトデーモンの働きについてさらに詳しく確認されたい場合は、ウェビナーアーカイブ：IRISデータベースの内部動作をご参照ください。

https://www.youtube.com/embed/VeSmItD_jHw?list=PLzSN_5VbNaxCeC_ibw2l-xneMCwCVf-Or
[これは埋め込みリンクですが、あなたはサイト上の埋め込みコンテンツへのアクセスに必要な Cookie を拒否しているため、それを直接表示することはできません。埋め込みコンテンツを表示するには、Cookie 設定ですべての Cookie を受け入れる必要があります。]

 

外部バックアップ手順

バックアップ手順は以下の通りです。

1) ライトデーモンの一時凍結（BackUp.GeneralクラスのExternalFreeze()）

具体的なコマンドは以下の通りです。 InterSystems製品にログインし、%SYSネームスペースに移動します。

Linuxやコンテナ利用時は、iris session インスタンス名 -U %SYS／ ccontrol session インスタンス名 -U %SYS でログインできます。
set status=##class(Backup.General).ExternalFreeze()
write status

必ずExternalFreeze()の実行結果を確認してください。ライトデーモン（WRTDMN）の凍結が成功するとステータスOKとして1が返ります（$$$OK）。

このコマンドがO/Sスクリプトの一部として使用された場合、システムの凍結に成功すると、Status値として5が返されます。凍結に失敗した場合は、Status値として3が返されます。実行例文はBackUp.GeneralクラスのExternalFreeze()をご参照ください。

またジャーナルファイルが切り替わります。

リストア作業を行う場合、ExternalFreeze()の実行により切り替わったジャーナルファイルからリストアを開始するため、ファイル名を記録しておきます。

ファイル名は、管理ポータル > [システムぺレーション] > [ジャーナル] より確認できます。「原因」列に「バックアップにより」と記載されている行のファイル名がバックアップにより切り替わったファイルです。

エラーの場合は、エラーステータスが戻るためエラー情報を確認するため、以下メソッドを実行してください。

write $system.Status.GetErrorText(status)

エラーステータスの取得方法について詳しくは、ObjectScriptクックブックの%Statusのエラーが返ってきたらをご参照ください。

＊＊注意！＊＊
ExternalFreeze()でライトデーモン（WRTDMN）を凍結できる時間は10分（600秒）に設定されています。タイムアウト以内にExternalThaw()を実行しないとシステムの更新処理が一時停止状態になり、システムがハングアップした状態になります。ご注意ください。

なお、タイムアウト値を延長する方法については後述の「特別な考慮」をご覧ください。

2) 外部のスナップショット・ユーティリティを使用して、ファイル・システムのスナップショットを作成します。

リストアの目的別で退避内容が異なります。

✅ システム全体をリストアすることが目的の場合

以下をバックアップ対象として退避します。

  • データベースディレクトリ
  • インストールディレクリ
  • WIJディレクトリ
  • ジャーナルディレクトリ
  • 構成ファイル(cpf)

※ ジャーナルファイルについては、バックアップ時点のファイルだけでなく、バックアップ以降のファイルがリストアで必要となるため、バックアップ以降のファイルも何らかの方法で退避する必要があります。

✅ データベースのみのバックアップ

対象となるデータベースディレクトリ以下を退避します。

 

3) 2)が終了したら、ライトデーモンを再開（BackUp.GeneralクラスのExternalThaw()）させます。

1) と同様に、InterSystems製品にログインし、%SYSネームスペースに移動し、以下実行します。

set status=##class(Backup.General).ExternalThaw()
write status

必ずExternalThaw()の実行結果もご確認ください。ライトデーモン（WRTDMN）の再開が成功するとステータスOKとして1が返ります（$$$OK）。 エラーの場合は、エラーステータスが戻るためエラー情報を確認するため、以下メソッドを実行してください。

write $system.Status.GetErrorText(status)

 

特別な考慮

スナップショット・テクノロジが利用できない環境であっても、BackUp.GeneralクラスのExternalFreeze()の引数を利用することで実行することができます。

最初に注目すべき引数について説明します。

なお、引数を指定しない場合はデフォルト設定値で動作します。

 

第7引数：ExternalFreezeTimeOut

ExternalFreeze()でライトデーモンを休止する秒数を指定できます。（デフォルトは600秒（10分）に設定されています。

タイムアウトを迎えた場合、システムの更新処理が一時停止状態になり、システムがハングアップした状態になります。 ExternalThaw()を実行するまで、新規プロセスでInterSystems製品へログインすることができません。

※ ExternalFreeze()前から稼働中のプロセスは継続利用できますが、書き込みできなくなります。

 

第10引数：WDSuspendLimit

ライトデーモンを再開する時間を秒数で指定できます。 デフォルトは設定されていないため、ExternalThaw()の実行まで再開しません。

 

目的別留意点

第7、10引数に利用については、目的別の留意点があります。

 

A. バックアップを確実に成功させたい場合

第7引数：ExternalFreezeTimeOut を バックアップ時間より長めに設定 します。ただし、指定可能な値の上限は1200秒です(それ以上長い値を指定しても1200秒が使用されます)。

留意点としては、バックアップ中のユーザプロセスからの更新で、データベースキャッシュが満杯になると、書き込みを行おうとするユーザプロセスは一時停止します。

 

B. バックアップ中にユーザプロセスの一時停止を避けたい場合

第10引数：WDSuspendLimit を使用して、ライトデーモン再開までの秒数を指定します（デフォルトは設定されていないため、ExternalThaw()の実行までライトデーモンは再開しません）。

留意点としては、バックアップ途中でライトデーモンが再開した場合、バックアップは失敗します。バックアップが失敗したかどうかを確認するには、ExternalThaw()の実行前に IsWDSuspended()メソッド の戻り値を利用して、ライトデーモンが休止中かどうかを確認します。

1が戻ると休止中、0が戻ると動作中を表します。

 

その他の引数

第1引数：LogFile

ログファイル名をフルパスで指定できます。指定したファイル名が存在しない場合は作成し、存在する場合はログはファイルの末尾から追加されます。デフォルトでは、すべてのメッセージをmessages.log（またはcconsole.log）に記録します。

 

第2引数：Text

ジャーナル・マーカーに格納するオプションのテキスト文字列を指定できます。

 

第3引数：SwitchJournalFile

0/1 で、システムをフリーズする前に新しいジャーナル・ファイルに切り替え、ジャーナル・マーカを追加するかどうかを指定します。デフォルトは1（ジャーナルを切り替えます）。

 

第4引数：TimeOut

（クラスタ化されていないシステムでは無視される引数）クラスタ化されたシステムの場合、システムが静止するまでの待ち時間 (秒)を指定できます。デフォルト10秒。

 

第5引数：Hibernate

（クラスタ化されていないシステムでは無視される引数）クラスタ化されたシステムの場合、失敗を返す前に（データベースの更新を再開して）ハイバネートし、ブロックと待機の全プロセスを再試行する回数を指定できます。デフォルトは0。

 

第6引数：Verbose

（クラスタ化されていないシステムでは無視される引数）0/1 クラスタ化されたシステムの場合、何が起こっているかについてのメッセージを画面に出力するかどうか指定できます。デフォルトは0。

 

第8引数：Username

ExternalThaw() メソッドに渡すユーザ名を指定できます。デフォルトは "" です。

 

第9引数：Password

ExternalThaw() メソッドに渡すパスワードを指定できます。デフォルトは""です。

 

第11引数：RequiredFile

参照渡しで指定します。バックアップがリストアされた後、トランザクションのロールバックに必要な最も古いジャーナル・ファイル名が設定されます。

 

バックアップからのリストア方法

リストアの目的に合わせ、バックアップファイルを使用してリストアします。

システム全体のリストアを目的としている場合、バックアップ時点に退避したWIJを利用するか／しないか、で方法が異なります。

データベースのみのリストア方法については 「データベースのみのリストア方法」 をご参照ください。

外部バックアップ実行時（＝ExternalFreeze()）WIJには、データベースの更新ブロックの情報以外にジャーナルファイルへのポインタ情報が含まれています。

  • トランザクションを開始している場合はトランザクションのオープン位置
  • データベースに正常に書き込まれたデータに対するジャーナルエントリへのポインタ

上記ポインタ情報を利用したリストア方法については 「システム全体のリストア：バックアップ時点に退避したWIJを利用したリストアの手順」 をご参照ください。

ポインタを利用せずにリストアを行う方法については 「システム全体のリストア：バックアップ時点のWIJを使用しないでリストアを行う手順」 をご参照ください。

 

システム全体のリストア：バックアップ時点に退避したWIJを利用したリストアの手順

このリストアのシナリオでは、外部バックアップ時にデータベースファイル（IRIS.DATまたはCACHE.DAT）とともにWIJをバックアップする必要があります。

1) InterSystems製品がダウンした状態のままとします。

2) データベースファイル（IRIS.DATまたはCACHE.DAT）とバックアップ時に退避したWIJをリストアします。

ダウンしたInterSystems製品の構成通りに配置します。

3) InterSystems製品を開始します。

開始時、WIJの情報を元に、その時利用していたジャーナルファイルを利用して、自動的にロールフォーワードを行います。

4) 妥当性の検証やメンテナンスを行う目的で、ジャーナルファイルをリストアします（オプション）。

ジャーナルリストアの流れは、10、ジャーナルリストアを実行をご参照ください。

※上記例の中ではジャーナルに記録されている情報の中から、特定のデータベースディレクトリに対する記録のみをリストアする方法を解説しています。データベースディレクトリを目的のディレクトリに読み替えてご利用ください。

5) InterSystems製品を停止します。

6) InterSystems製品を通常開始します。ユーザからの接続が許可されます。

 

システム全体のリストア：バックアップ時点のWIJを使用しないでリストアを行う手順

このリストアのシナリオでは、バックアップ時に退避しているWIJファイルを使用せずにリストアする方法を説明します（＝バックアップ時点のWIJがない場合でもリストアできる方法）。

1) InterSystems製品がダウンした状態のままとします。

2) データベースファイル（IRIS.DATまたはCACHE.DAT）をリストアします。

ダウンしたInterSystems製品の構成通りに配置します。

3) InterSystems製品を開始します。

4) ダウンしたときのWIJを使用せず、開始します。

5) ジャーナルファイルをリストアします。

ジャーナルリストアの流れは、10、ジャーナルリストアを実行をご参照ください。

※上記例のジャーナルリストアではジャーナルに記録されている情報の中から、特定のデータベースディレクトリに対する記録のみをリストアする方法を解説しています。データベースディレクトリを目的のディレクトリに読み替えてご利用ください。

6) InterSystems製品を停止します。

7) InterSystems製品を通常開始します。ユーザからの接続が許可されます

 

データベースのみのリストア方法

他の正常なデータベースを通常状態に戻すため、以下の手順でリストアします。

1) 障害発生時のWIJを用いてリストアを行うため InterSystems製品を開始します。

WIJをロールフォーワードし、さらに障害発生直前まで使用していたジャーナルファイルを使用して、リストア対象ではない他の正常なデータベースを直近の状態までロールフォーワードします。

2) InterSystems製品を一旦停止します。

バックアップしていたデータベースファイル（IRIS.DATまたはCACHE.DAT）を利用して、データベースファイルを置き換えます。

3) InterSystems製品を開始します。

4) ジャーナルファイルをリストアします。

リストアを開始するため、的確なジャーナルファイルを決定します。通常、バックアップ前に切り替えられたジャーナルファイルを利用して、リストアを開始します。

ジャーナルリストアの流れは、10、ジャーナルリストアを実行をご参照ください。

※上記例のジャーナルリストアでは、ジャーナルに記録されている情報の中から、特定のデータベースディレクトリに対する記録のみをリストアする方法を解説しています。データベースディレクトリを目的のディレクトリに読み替えてご利用ください。

※ 手順1で障害発生時点のWIJを使用したロールフォーワードリカバリが正常に終了しない場合もあります。その場合はサポートセンターまでお問い合わせください。

 

演習：外部バックアップとリストア

この演習では、単一のデータベースのバックアップを例に、外部バックアップ、バックアップファイルのリストア、ジャーナルリストアについて練習します。

演習では、以下データベースを外部バックアップで退避します。

  • T1データベース＝/usr/irissys/mgr/t1

以下例では、T1データベースのあるディスクが壊れたことを想定し、リストア時のT1データベースディレクトリがバックアップ時点とは異なるディレクトリにリストアしなくてはならない場合の流れで解説します。

なお、バックアップファイルのリストア後、ジャーナルファイルを利用したリストアも行う必要がありますので以下の流れで試していきます。

1、バックアップ前にT1データベースに任意データ登録する（^prebackup=1）

2、外部バックアップを実行する

3、切り替わったジャーナルファイル名を確認する

4、バックアップ後だとわかる任意データをT1データベースに登録する（^postbackup=1）

5、ジャーナルファイルに 4で登録した情報が含まれているか確認する

6、T1データベース（/usr/irissys/mgr/t1）を削除

7、T1データベースを別ディレクトリ（/usr/irissys/mgr/t1rest）に再作成

8、バックアップからのリストアを実行する

退避していたT1データベースのIRIS.datをリストア対象ディレクトリに置換します。

  • リストア対象ディレクトリ：/usr/irissys/mgr/t1rest

9、^prebackup=1 が戻ることを確認する

10、ジャーナルリストアを実行

T1データベースのみリストアするように指定します。

  • バックアップ時点のディレクトリ：/usr/irissys/mgr/t1
  • リストア時に指定するディレクトリ：/usr/irissys/mgr/t1rest

11、^postbackup=1 が戻ることを確認する

 

1、バックアップ前にT1データベースに任意データ登録する（^prebackup=1）

ネームスペースT1に接続し、以下実行します。

Linuxやコンテナを利用されている場合は、iris session インスタンス名 -U T1 でログインすると簡単です。

set $namespace="T1"
set ^prebackup=1

 

管理ポータルでデータを確認します。

[システムエクスプローラ] > [グローバル] > T1ネームスペース選択

グローバル変数名が多く一覧される場合、画面左端の「フィルタ」の「グローバル名」に pre* と書くとフィルタされた結果が表示されます。

 

2、外部バックアップを実行する

ライトデーモンを凍結させるため、以下実行します。

なお、ExternalFreeze()実行から10分後にタイムアウトを迎えます。タイムアウト前にExternalThaw()を必ず実行し、ライトデーモンの凍結解除を行ってください。

set status=##class(Backup.General).ExternalFreeze()
write status

変数statusに1が設定されていれば実行が成功したことを示します。

T1データベースディレクトリ（/usr/irissys/mgr/t1）を退避エリアにコピーします。

コピーが完了したら、凍結解除用メソッドを実行します。

set status=##class(Backup.General).ExternalThaw()
write status

 

3、切り替わったジャーナルファイル名を確認する

管理ポータル > [システムオペレーション] > [ジャーナル] 「バックアップにより」切り替わったジャーナルファイルを確認します。

以下の例でジャーナルリストアの開始ファイルとして指定するファイル名は「/usr/irissys/mgr/journal/20240426.002」です。

 

4、バックアップ後だとわかる任意データをT1データベースに登録する（^postbackup=1）

ネームスペースT1に接続し、以下実行します。

Linuxやコンテナを利用されている場合は、iris session インスタンス名 -U T1 でログインすると簡単です。

set $namespace="T1"
set ^postbackup=1

 

5、ジャーナルファイルに 4で登録した情報が含まれているか確認する

管理ポータル > [システムオペレーション] > [ジャーナル] で現在のジャーナルファイルを開き、^postbackupが記録されているか確認します。

画面右端のデータベースディレクトリ名を確認し、「/usr/irissys/mgr/t1」で記録されていることを確認します。

 

6、T1データベース（/usr/irissys/mgr/t1）を削除

管理ポータルメニューから削除します。

稼働中に削除する場合、一旦データベースをディスマウントすることをお勧めします。

管理ポータル > [システムオペレーション] > [データベース] > T1を選択 > ディスマウントボタンをクリック

ディスマウント後、構成メニューに移動しデータベースを削除します。

管理ポータル > [システム管理] > [構成] > [システム構成] > [ローカルデータベース] > T1を削除

この削除時に ”チェックしたネームスペースを削除します” の T1 にチェックを入れてT1ネームスペースも削除します。

 

7、T1データベースを別ディレクトリ（/usr/irissys/mgr/t1rest）に再作成

管理ポータルでT1ネームスペース、データベースを作成します。

このときのデータベースは最初に作成したディレクトリとは異なるディレクトリで作成します。

例では、/usr/irissys/mgr/t1rest としています。

 

8、バックアップからのリストアを実行する

作成したT1データベース（/usr/irissys/mgr/t1rest）をディスマウントします。

管理ポータル > [システムオペレーション] > [データベース] > T1を選択 > ディスマウントボタンをクリック

ディスマウント中に、退避していたT1データベースのIRIS.dat（元/usr/irissys/mgr/t1以下にあったIRIS.dat）を　/usr/irissys/mgr/t1rest　に置換します。

置換後、マウントボタンでデータベースをマウントします。

 

9、^prebackup=1 が戻ることを確認する

管理ポータル > [システムエクスプローラ] > [グローバル] > T1ネームスペース選択

^prebackupは表示されますが、^postbackupがまだ戻っていないことを確認します。

 

10、ジャーナルリストアを実行

続いて、ジャーナルリストアを実行します。

ご参考：^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア

ジャーナルのリストアもジャーナルファイルに記録されている全データベースディレクトリではなく、/usr/irissys/mgr/t1 で記録されていた情報のみをリストアするようにします。グローバル変数まで指定してリストアできますが、今回は /usr/irissys/mgr/t1 のグローバルをすべてリストアするようにします。

%SYSネームスペースで^JOURNALルーチンを実行します。

ジャーナルリストアメニューは、4番を選択します。

%SYS>do ^JOURNAL
 1) Begin Journaling (^JRNSTART)
 2) Stop Journaling (^JRNSTOP)
 3) Switch Journal File (^JRNSWTCH)
 4) Restore Globals From Journal (^JRNRESTO)
 5) Display Journal File (^JRNDUMP)
 6) Purge Journal Files (PURGE^JOURNAL)
 7) Edit Journal Properties (^JRNOPTS)
 8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
 9) Display Journal status (Status^JOURNAL)
10) -not available-
11) -not available-
12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO)
13) -not available-

Option? 4
This utility uses the contents of journal files
to bring globals up to date from a backup.

ジャーナルをリストアしますか？には、Yes（またはEnter）を入力します。

Restore the Journal? Yes => Yes

この質問の回答が重要です。 ジャーナルファイルに記録された全データベースディレクトリの全グローバル変数をリストアする場合は、Yesを入力します。

今回は、指定ディレクトリんの全グローバルをリダイレクトしながらリストアしたいので、no を入力します。

Process all journaled globals in all directories? no

リストアしようとしているジャーナルファイルが別のOSで作成されたものかどうか質問されます。今回は同じマシンで作成されたものなのでNoを入力します。

Are journal files imported from a different operating system? No => No

続いて、リストアするデータベースディレクトリを指定します。

/usr/irissys/mgr/t1 を /usr/irissys/mgr/t1rest にリダイレクトしながらリストアします。

Directory to restore [? for help]: /usr/irissys/mgr/t1  /usr/irissys/mgr/t1/??
No database exists in that directory.
(you will be required to redirect to another directory)
Redirect to Directory: /usr/irissys/mgr/t1/
 => /usr/irissys/mgr/t1rest--> /usr/irissys/mgr/t1rest/

指定したデータベースディレクトリに含まれるすべてのグローバルをリストアしたいですか？と聞かれています。今回は特定のグローバルではなく全てリストアするためyesを指定します。

Process all globals in /usr/irissys/mgr/t1/? No => yes

さらにリストア対象データベースがある場合は同様に指定しますが、ない場合は、Enterを押下します

Directory to restore [? for help]:

ここまで指定したディレクトリリストを表示します。変更がなければyesを入力します。

Processing globals from the following datasets:
 1. /usr/irissys/mgr/t1/   All Globals
    (Redirect to: /usr/irissys/mgr/t1rest/)

Specifications correct? Yes => yes

リストアに使用するジャーナルファイルはこのインスタンスで作成され、ジャーナルディレクトリにあるパスに配置されているかどうか質問されています。（InterSystems製品にはjournal.logファイルがあり、直近までのジャーナルファイルのフルパス情報が記録されています。このファイルを使用できるかどうかの質問です。）

例では、設定どおりにジャーナルファイルが配置されているため、yesを入力します。

Are journal files created by this InterSystems IRIS instance and located in their original paths? (Uses journal.log to locate journals)? yes

次に、どのジャーナルファイルをリストア対象とするか指定します。ファイル名が不明な場合は ? を入力するとリストを出します。リストから選択することもできます。（例では、First fileとFinal fileが同一ですが問題ありません）

最終行の質問は、ひとつのジャーナルファイルのリストアが完了して次のジャーナルファイルをリストアする前にプロンプト(入力待ち)をするかどうかです。自動的に指定したすべてのジャーナルファイルをリストアする場合は no を入力します。

Specify range of files to process

Enter ? for a list of journal files to select the first and last files from
First file to process:  ?
1) /usr/irissys/mgr/journal/20240425.003
2) /usr/irissys/mgr/journal/20240425.004
3) /usr/irissys/mgr/journal/20240426.001
4) /usr/irissys/mgr/journal/20240426.002

First file to process:  4 /usr/irissys/mgr/journal/20240426.002
Final file to process:  /usr/irissys/mgr/journal/20240426.002 =>
Prompt for name of the next file to process? No => no

ジャーナルファイルのリストに欠落がないかどうかチェックするか質問されます。 Enter（またはYes）を入力します。


The following actions will be performed if you answer YES below:

* Listing journal files in the order they will be processed
* Checking for any missing journal file on the list ("a broken chain")

The basic assumption is that the files to be processed are all
currently accessible. If that is not the case, e.g., if you plan to
load journal files from tapes on demand, you should answer NO below.
Check for missing journal files? Yes => Yes

処理対象ジャーナルファイルが表示されます。

続いて、ジャーナルファイル内の整合性チェックを行うか確認されます。（デフォルトはNo）例ではNoを選択しています。

Journal files in the order they will be processed:
1. /usr/irissys/mgr/journal/20240426.002

While the actual journal restore will detect a journal integrity problem
when running into it, you have the option to check the integrity now
before performing the journal restore. The integrity checker works by
scanning journal files, which may take a while depending on file sizes.
Check journal integrity? No => No

リストア処理前後でジャーナルファイルを切り替えるか質問されます。 切り替えたほうがわかりやすいので、例ではYesを指定しています。

The journal restore includes the current journal file.
You cannot do that unless you stop journaling or switch
     journaling to another file.
Do you want to switch journaling? Yes => Yes
Journaling switched to /usr/irissys/mgr/journal/20240426.003

ジャーナルリストア中のジャーナルを無効化したいか質問されています。デフォルトのYes（無効化）を選択します。

※ミラーリングを利用している場合は無効化を選択せず、リストア中のジャーナルを他メンバーに転送し適用することで全メンバーのリストアが自動的に完了させることもできます。

You may disable journaling of updates for faster restore for all
databases other than mirrored databases. You may not want to do this
if a database to restore is being shadowed as the shadow will not
receive the updates.
Do you want to disable journaling the updates? Yes => Yes
Updates will NOT be journaled

リストアを開始する前にデフォルトオプションを確認しています。

デフォルトは、

  • データベースに関連するエラーが発生した場合でもリストアを続行します。
  • ジャーナルに関連するエラーが発生した場合、リストアを中止します。

別の方法は、

  • データベースに関連するエラーが発生した場合中止します。
  • ジャーナルファイルに関連する問題が発生した場合でもリストアを続行します。

変更しない場合は、デフォルトのNoを指定します。

Before we job off restore daemons, you may tailor the behavior of a
restore daemon in certain events by choosing from the options below:

     DEFAULT:    Continue despite database-related problems (e.g., a target
     database cannot be mounted, error applying an update, etc.), skipping
     updates to that database. Affected database(s) may not be self-consistent
     and will need to be recovered separately

     ALTERNATE:  Abort if an update would have to be skipped due to a
     database-related problem (e.g., a target database cannot be mounted,
     error applying an update, etc.). Databases will be left in a
     self-consistent state as of the record that caused the restore to be
     aborted. Parallel dejournaling will be disabled with this setting

     DEFAULT:    Abort if an update would have to be skipped due to a
     journal-related problem (e.g., journal corruption, some cases of missing
     journal files, etc.)

     ALTERNATE:  Continue despite journal-related problems (e.g., journal
     corruption, some missing journal files, etc.), skipping affected updates

Would you like to change the default actions? No => No

リストアを開始する場合は、Yesを入力します。

Start the restore? Yes => Yes

ジャーナルリストアを開始し、リダイレクト先のデータベースディレクトリが更新されます。

メニューが表示されるので特に他の作業がなければEnterを押下し%SYSネームスペースのプロプト表示に戻ります。

Journal file being applied: /usr/irissys/mgr/journal/20240426.002
/usr/irissys/mgr/journal/20240426.002
  0.81% 100.00%
[Journal restore completed at 20240426 14:10:16]

The following databases have been updated:

1. /usr/irissys/mgr/t1rest/


 1) Begin Journaling (^JRNSTART)
 2) Stop Journaling (^JRNSTOP)
 3) Switch Journal File (^JRNSWTCH)
 4) Restore Globals From Journal (^JRNRESTO)
 5) Display Journal File (^JRNDUMP)
 6) Purge Journal Files (PURGE^JOURNAL)
 7) Edit Journal Properties (^JRNOPTS)
 8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
 9) Display Journal status (Status^JOURNAL)
10) -not available-
11) -not available-
12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO)
13) -not available-

Option?
%SYS>

 

11、^postbackup=1 が戻ることを確認する

管理ポータル > [システムエクスプローラ] > [グローバル] > T1ネームスペース選択

^postbackupが存在するか確認します。

 

ご参考

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください