Perforceのサポート: バックアップとリカバリ

Perforceサービスは2種類のデータを保存します。バージョン化ファイルとメタデータです。

  • バージョン化ファイルは、Perforceユーザによってサブミットされたファイルです。バージョン化ファイルは、ディポというディレクトリツリーに保存されます。

    Perforceでは、サーバのルートディレクトリの下にサブディレクトリがディポごとに1つ設けられます。各ディポでは、このサブディレクトリ直下のディレクトリツリーにバージョン化ファイルが保存されます。

  • データベースファイルにはメタデータが保存されます。メタデータには、チェンジリスト、作業状態のファイル、クライアントワークスペース仕様、ブランチマッピング、バージョン化ファイルの履歴と現状に関するデータなどが含まれます。

    データベースファイルは、サーバルートディレクトリの最上位階層にdb.*ファイルとして表示されます。それぞれのdb.*ファイルには、バイナリエンコードされた単一のデータベーステーブルが格納されています。

バックアップとリカバリに関する基本的な考え方

ディスク容量の不足、ハードウェアの故障、システムのクラッシュなどが発生すると、それによりPerforceサーバのファイルの一部または全部が破損する場合があります。このため、Perforceルートディレクトリ構造(バージョン化ファイルおよびデータベース)の全体を、定期的にバックアップしておく必要があります。

バージョン化ファイルはPerforceサーバルート以下のサブディレクトリ内に保存されており、バックアップから完全な形で直接復元することができます。

一方、Perforceのデータベースを構成しているファイルは、従来のバックアッププログラムによってアーカイブされた場合、トランザクションの整合性は保証されません。その結果、定期的に作成したシステムバックアップからdb.*ファイルを復元すると、不完全なデータベースが復元される可能性があります。損傷したデータベースの整合性を確保しながら復元するには、db.*ファイルをPerforceチェックポイントおよびジャーナルファイルから再構築するしかありません。

  • チェックポイントは、特定の時点におけるデータベースのスナップショットまたはコピーです。

  • ジャーナルは、最後のスナップショットが取得されてからそのデータベースに行われた更新の記録です。

チェックポイントファイルのサイズは、たいていの場合、オリジナルのデータベースと比べてかなり小さいです。圧縮すると、さらに小さくすることができます。他方、ジャーナルファイルは場合によってかなり大きくなります。こちらは、チェックポイントが作成されるたびに切り詰められ、より古いジャーナルは別の名前に変更されて保存されます。その後、古いジャーナルファイルをオフラインでバックアップすると、ローカルのディスク容量をより多く解放できます。

チェックポイントとジャーナルは両方ともテキストファイルであり、同一の形式です。チェックポイントと(使用可能な場合)それ以降のジャーナルファイルから、Perforceデータベースを復元することができます。

Warning

チェックポイントとジャーナルにアーカイブされているのはPerforceデータベースファイルのみです。各ディポのディレクトリに保存されているバージョン化ファイルは含まれないことに注意してください。

チェックポイントを作成するたびに、必ず作成後にOS標準のバックアップコマンドを実行することにより、ディポファイル(バージョン化ファイルツリー)をバックアップする必要があります。

Perforceのデータベースに保存されている情報は、バージョン化ファイルと同様、失ったら取り返しのつかないデータです。したがって、チェックポイント作成とジャーナル作成は、Perforceの管理のなかでも不可欠な要素であり、定期バックアップサイクルに組み込んでおく必要があります。

チェックポイントファイル

チェックポイントは、Perforceのデータベース内のメタデータを作成しなおすのに必要なすべての情報を格納しているファイルです。チェックポイントを作成すると、そのPerforceのデータベースはロックされます。これは、そのデータベースの完全に一貫したスナップショットを確実に取得できるようにするためです。

バージョン化ファイルはチェックポイントとは別にバックアップされます。つまり、チェックポイントはバージョン化ファイルの内容を含まないということであり、したがってバージョン化ファイルをチェックポイントから復元することはできません。ただし、すべてのチェンジリスト、ラベル、ジョブなどは、チェックポイントから復元することができます。

確実に完全なデータベースを復元するには、ディポにおけるバージョン化ファイルと同じ時点かそれ以前に作成されたチェックポイントを使用する必要があります。つまり、バージョン化ファイルのバックアップを開始する前に、データベースのチェックポイントを作成してその生成を完了しておく必要があるということです。

ジャーナルが大きくなり過ぎないようにするには、チェックポイントを定期的に作成することが重要です。システムをバックアップする直前にチェックポイントを作成することを推奨します。

チェックポイントを作成する

チェックポイントが自動的に作成されることはありません。手動またはその他の方法で、チェックポイント作成コマンドをPerforceサーバマシン上で実行する必要があります。チェックポイントを作成するには、p4dプログラムを、-jc(ジャーナル作成)フラグ付きで起動します。

p4d -r server_root -jc

Perforceサービス(p4d)の動作中にチェックポイントを作成することができます。チェックポイントの作成先は、サーバルートディレクトリ(server_rootが指定されていない場合はP4ROOT)です。

チェックポイント作成時に、データベースはp4dによってロックされ、その内容がP4ROOTディレクトリ内のcheckpoint.nというファイルにダンプされます。ここでnはシーケンス番号を表します。

データベースのロックを解除する前に、p4dはジャーナルファイルをP4ROOTディレクトリのjournal.n-1というファイルにコピーし(UNIX上でジャーナルが圧縮されていない場合はジャーナルファイルの名前を前述のファイル名に変更し)、そのうえでカレントジャーナルを切り詰めます。チェックポイントのMD5チェックサムは別のファイル(checkpoint.n.md5)に書き込まれます。そしてlastCheckpointActionカウンタが正常に完了したことを表す値に更新されます。

Note

圧縮されたチェックポイントのMD5シグネチャを検証する際には、まずそのチェックポイントを作成したシステムに固有の行末規則を反映した形式に、チェックポイントを解凍する必要があります。(すなわち、Windowsサーバによって生成された圧縮済みチェックポイントでは、行末にCR/LFが使用されている必要があり、またUNIXシステムで生成された圧縮済みチェックポイントでは、行末にLFが使用されている必要があります。)

これにより、最新のチェックポイント(checkpoint.n)とカレントジャーナル(journal)との組み合わせに、チェックポイント作成時点のデータベースの完全な内容が確実に反映されることになります。

シーケンス番号は、そのジャーナルのロールフォワードの性質を示しています。より古いチェックポイントのデータベースを復元するには、シーケンス番号を参照します。つまり、checkpoint.6の時点のデータベースを復元するには、まずcheckpoint.5に保存されているデータベースを復元し、さらにjournal.5に記録されている変更をロールフォワードします。ほとんどの場合は、カレントデータベースを復元すれば十分です。これは、最大のシーケンス番号を持つcheckpoint.nに、現在のjournal内の変更をロールフォワードすることにより反映されます。

チェックポイントおよびジャーナルのプレフィックスやディレクトリの場所を指定するには、-jcオプションを使用します。例えば、以下のコマンドでチェックポイントを作成するとしましょう。

p4d -jc prefix

この場合、チェックポイントのファイル名はprefix.ckp.n、ジャーナルファイル名はprefix.jnl.nとなります。このうちprefixの部分はコマンドラインで指定することができ、nはシーケンス番号です。prefixが指定されていない場合は、既定のファイル名checkpoint.nおよびjournal.nが使用されます。任意のディレクトリにチェックポイントとジャーナルを保存するには、プレフィックスの一部にそのディレクトリを指定します。

サーバのプレフィックスを事前に指定するには、以下のように記述します。

p4 configure set journalPrefix=prefix

構成可能変数journalPrefixを設定すると、設定したprefixが既定のファイル名よりも優先的に使用されます。この動作は、とくにマルチサーバ環境や複製環境で有用です。

Perforceサービスを実行しているマシンにログインせずにチェックポイントを作成するには、以下のコマンドを使用します。

p4 admin checkpoint [-z | -Z] [prefix]

p4 admin checkpointを実行すると、p4d -jcを実行した場合と同じ結果になります。Perforceスーパーユーザでなければp4 adminを使用できません。

定期的にチェックポイントを作成する自動化プログラムを設定することができます。ただし、その場合、チェックポイントの作成が開始されたかどうか、プログラムの出力を頻繁に確認するようにしてください。チェックポイントの実際のMD5チェックサムと、.md5に記録されているチェックサムを比較し、.md5ファイルとチェックポイントのバックアップを取得してください。正常に作成されたことが確認されたら、チェックポイントファイルを圧縮したり、アーカイブしたり、他のディスクに移動してもよいでしょう。それとほぼ同時に、ディポのサブディレクトリに保存されたバージョン化ファイルをバックアップします。

バックアップから復元する場合、チェックポイントは、少なくともディポのファイルと同じくらい古いものでなければなりません。つまり、バージョン化ファイルがチェックポイントより新しい場合には問題は生じませんが、より古い場合には正常に復元できません。当然ながら、作成された時期のずれはできるだけ小さいほうが望ましいといえます。

チェックポイントコマンド自体が機能しない場合、ただちにPerforceテクニカルサポートにご連絡ください。チェックポイントの不具合は、通常、リソース(ディスク容量、パーミッションなど)に問題がある場合に発生します。こうした問題を正しく処理しなければ、データベースに何らかのリスクが生じるおそれがあります。

Note

チェックポイントの整合性を検証するには、p4d -jvコマンドを使用します。

ジャーナルファイル

ジャーナルは、最後のチェックポイントの作成後にデータベースに加えられたすべての変更点を追跡する実行トランザクションログです。これは2つのチェックポイントの架け橋です。

月曜日に作成されたチェックポイントと、その時点から水曜日まで収集されたジャーナルがある場合、それら2つのファイル(月曜日のチェックポイントと累積ジャーナル)に含まれる情報は、水曜日に作成されたチェックポイントに含まれる情報と同じです。例えば、水曜日の正午にディスククラッシュが発生してPerforceデータベースが破損したとします。この場合、たとえ水曜日のチェックポイントがまだ作成されていなくても、データベースを復元することができます。

Warning

既定では、カレントジャーナルファイル名はjournal、格納されているディレクトリはP4ROOTです。ただし、ディスクの故障によりルートディレクトリが破損した場合、ジャーナルファイルにアクセスできなくなってしまいます。

したがって、ジャーナルファイルがP4ROOT以外のファイルシステムに書き込まれるようにシステムを設定することを強く推奨します。そのためには、環境変数P4JOURNAL内にジャーナルファイル名を指定するか、p4d起動時に-J filenameフラグを使用します。

データベースを復元するには、最新のジャーナルファイルに常にアクセスできるようにしておくだけで十分です。ただし、より古いチェックポイントを復元する必要が生じるなら、古いジャーナルを古いチェックポイントと一緒にアーカイブしておくと安心です。

ジャーナル作成は、すべてのWindowプラットフォームおよびUNIXプラットフォームで自動的に有効になります。P4JOURNALが未設定のままである(かつコマンドラインで場所が指定されない)場合、ジャーナルの既定の場所は$P4ROOT/journalになります。

ジャーナルファイルは、新しいチェックポイントが作成されるまで増大し続けます。ジャーナルファイルのサイズを抑制するには、定期的にチェックポイントを作成する必要があります。カレントジャーナルのサイズがきわめて大きくなっている場合、それはチェックポイントを作成する必要があるしるしです。

チェックポイントを作成するたびに(二回目以降)、古いジャーナルファイルの名前が変更され、新しいジャーナルファイルへの記録が開始されます。古いjournalはjournal.nという名前(nはシーケンス番号)に変更され、新しいjournalが作成されます。

既定では、ジャーナルはサーバルートディレクトリ(P4ROOT)内のjournalファイルに書き込まれます。ディスククラッシュが発生しないという保証はどこにもありません。したがってジャーナルファイルは、Perforceサーバルートとは別のファイルシステムに置かれるべきです。理想的なのは別の物理ディスクドライブに置かれることです。ジャーナルの名前と場所を変更することができます。そのためには、環境変数P4JOURNAL内にジャーナルファイル名を指定するか、p4dの起動時に-J filenameフラグを使用します。

Warning

ジャーナルファイル作成時に-J filenameフラグを使用する場合、それ以降のチェックポイントで必ず同じファイルを使ってください。さもなければ、ジャーナルファイルの名前は適切に変更されません。

P4JOURNALを使用するにせよ、-J journalfileにp4dオプションを指定して使用するせによ、ジャーナルファイル名は、絶対パスでも、サーバルートを基準とする相対パスでも指定できます。

Example 2. ジャーナルファイルの指定

以下のコマンドでサービスを起動します。 

$ p4d -r $P4ROOT -p 1666 -J /usr/local/perforce/journalfile

Perforce Server starting...

チェックポイントを作成するのに以下のコマンド 

$ p4d -r $P4ROOT -J /usr/local/perforce/journalfile -jc

Checkpointing to checkpoint.19...
Saving journal to journal.18...
Truncating /usr/local/perforce/journalfile...

を使用するか、P4JOURNALを/usr/local/perforce/journalfileに設定して以下のコマンドを使用します。 

$ p4d -r $P4ROOT -jc

Checkpointing to checkpoint.19...
Saving journal to journal.18...
Truncating /usr/local/perforce/journalfile...

環境変数P4JOURNAL(またはコマンドラインの指定)が、Perforceサービスの起動時に使用された設定と異なる場合、チェックポイントは依然として作成されますが、ジャーナルは保存も切り詰めもされません。これは実に避けるべきことです。

チェックポイントとジャーナルの履歴

p4 journalsコマンドを使用すると、サーバに対するチェックポイントとジャーナルの履歴を表示することができます。この履歴には、次のように、チェックポイント、ジャーナルローテーション、ジャーナルリプレイ、チェックポイントのスケジュールといったイベントの情報も含まれています。出力とオプションに関する詳細については、P4コマンドリファレンスのp4 journalsコマンドの解説を参照してください。

ジャーナルの整合性を検証する

チェックポイントの整合性を検証するには、p4d -jvコマンドを使用します。

ジャーナル作成を無効にする

ジャーナル作成を無効にするには、サービスを停止し、既存のジャーナルファイル(存在する場合)を削除し、環境変数P4JOURNALをoffに設定し、p4dに-Jフラグをつけずに再起動します。

バージョン化ファイル

チェックポイントとジャーナルファイルを使用して再構築されるのは、Perforceのデータベースファイルのみです。バージョン化ファイルは、Perforceサーバルートの下のディレクトリに保存されており、別々にバックアップする必要があります。

バージョン化ファイルの形式

バージョン化ファイルは、サーバルート以下のサブディレクトリ内に保存されます。テキストファイルには、filename,vという形式のファイル名が付けられ、RCS形式で保存されます。総じて、テキストファイル1つにつきRCS形式(,v)ファイル1つが存在します。バイナリファイルはfilename,dという名前の専用ディレクトリに完全な形で保存されます。ユーザがファイルの保存時に選択したPerforceファイルタイプに応じて、各filename,dディレクトリ内に1つ以上のアーカイブされたバイナリファイルが保存されます。1つのfilename,dディレクトリ内に複数のファイルが存在する場合、ディレクトリ中の各ファイルは、同一のバイナリファイルの異なるリビジョンを参照し、1.nという名前が付けられます。nはリビジョン番号です。

Perforceは、AppleSingleファイル形式もサポートしています。これらのファイルは、他のバイナリファイルと同様に、完全な形で圧縮されて保存されます。保存形式はMacのAppleSingleファイル形式です。必要な場合に、サーバルートから直接コピーし、解凍してから、Mancintosh上と同様に使用することができます。

Perforceはディポファイルツリーで圧縮ファイルを使用しているので、バックアップメディアのサイズを調整するときにデータの圧縮を前提にしないでください。テキストファイルもバイナリファイルも、p4dによって圧縮されて(拡張子.gzを与えられ)てから保存されるか、圧縮されないまま保存されます。概して、ディポのサブディレクトリーにある任意のバイナリファイルが圧縮されずに保存されている場合、そのバイナリファイルは圧縮不可能なファイルだと考えられます。(例えば、多くの画像、音楽、映像ファイル形式は圧縮できない形式です。)

チェックポイント作成後にバックアップする

クラッシュからの復元後、バージョン化ファイルのすべての情報をデータベースに確実に反映させるためには、バージョン化ファイルと少なくとも同じ程度に(またはそれ以上に)古いチェックポイントからdb.*ファイルを復元する必要があります。このため、単一または複数のディポディレクトリでバージョン化ファイルをバックアップする前に、チェックポイントを作成してください。

バージョン化ファイルがチェックポイントに保存されているデータより新しいものであったとしても問題はありませんが、その保存時期のずれについては最小限にとどめることを推奨します。一般的には、バックアップスクリプトによって、チェックポイント作成が正常に完了した直後にバージョン化ファイルをバックアップします。

バックアップ手順

インストールされているPerforceをバックアップするには、夜間バックアップ作業の一環として、以下の手順を実行します。

  1. サーバの整合性を検証します。

    p4 verify //...

    p4 verifyに-q(quiet)オプションを指定して使用することもできます。-qオプションを指定して実行すると、p4 verifyはエラーが検出されたときのみ出力を行います。

    バックアップ前にp4 verifyを実行すると、アーカイブの状態を把握することができ、これから作成されるバックアップの一部としてこの情報を確実に保存することができます。

    p4 verifyを定期的に実行することを推奨します。データの破損があった場合にそれをバックアップ前に発見できるばかりではなく、クラッシュが生じた場合にバックアップから復元されたファイルの状態を検出することもできるからです。

    Note

    大規模なサイトでは、p4 verifyの実行に時間がかかる場合があります。さらに、p4 verifyによるファイル検証中はサーバの負荷が増大しているため、他のPerforceコマンドの処理に影響を与える可能性があります。大規模なサイトの管理者は、p4 verifyを実行するペースは毎晩ではなく週1回にしたほうがよいかもしれません。

    p4 verifyコマンドの詳細については、署名によりファイルを認証するを参照してください。

  2. -jc(journal-create)フラグを指定してp4dを呼び出すか、あるいはp4 adminコマンドを使用することにより、チェックポイントを作成します。以下のうち1つを使用します。

    p4d -jc

    または

    p4 admin checkpoint

    p4dはチェックポイント作成中にデータベース全体をロックするので、通常はバックアップ手順の途中でPerforceサービスを停止する必要はありません。

    Note

    非常に大規模なサイトの場合(db.*ファイルが数GBに及ぶ場合)、チェックポイントの作成には相当の時間がかかる可能性があります。

    そのような場合には、システムの活動が低下する時間帯まで、チェックポイントの作成とジャーナルの更新を延期するとよいかもしれません。例えば、夜間バックアップ中にjournalファイルのみアーカイブしておき、週に1度チェックポイントを作成してジャーナルファイルを更新するようにしてもよいでしょう。

  3. 任意のファイルをバックアップする前に、チェックポイントが正常に作成されたことを確認します。(ディスクがクラッシュした後になって、チェックポイントが3週間前から正常に作成されていなかったことをようやく知る、などということがないようにしましょう。)

    チェックポイントコマンドが正常に完了したかどうか点検するには、p4d -jcから返されたエラーコードを検証するか、カレントジャーナルファイルが更新されたことを確認してください。

  4. チェックポイントのMD5チェックサムと、p4d -jcによって作成された.md5ファイルを比較して、チェックポイントが正常にディスクに書き込まれたことを確認します。

    .md5ファイルのチェックサムは、圧縮される前の状態と同じように、チェックポイントファイルのチェックサムと一致し、たとえサービスがWindow上でホストされていたとしても、UNIX形式の行末が想定されます。(チェックポイントのファイルが-z圧縮オプションを使用して作成されていた場合、それを解凍して行末の違いを確認したほうがよい場合があります。)

  5. チェックポイントが正常に作成された後で、チェックポイントファイル、その.md5ファイル、ジャーナルファイル、バージョン化ファイルをバックアップします。(ほとんどの場合、ジャーナルをバックアップする必要は実際にはありませんが、普段からバックアップをとっておくことを推奨します。)

    Note

    まれに、チェックポイントが作成された時点から、バージョン化ファイルがバックアップユーティリティによってバックアップされる時点までのあいだに、バージョン化ファイルツリーが変更されることがあります(例えば、ユーザが、バックアップ中にファイルを消去してしまった場合や、ファイルバックアップのプロセス中にWindowsサーバ上のファイルをサブミットしてしまった場合です)。

    ほとんどのサイトには、こうした問題の影響は及びません。Perforceを1日24時間かつ週7日間ずっと稼働させておいても、メリットに比べてリスクは小さいといえます。システムの活動が低下する時間帯にバックアップを実行する場合は、とくにそうです。

    ただし、毎回確実にバックアップを遂行することを最も重視とする場合は、チェックポイント作成前にPerforceサービスを停止し、バックアップ処理が完了してから再起動することを検討してください。そうすれば、バックアップ処理中にシステムの状態が変更されるリスクをなくせるでしょう。

    db.*ファイルをバックアップする必要はありません。最新のチェックポイントとジャーナルには、それらを再生するのに必要な情報がすべて格納されています。より大切なことは、db.*ファイルから復元されたデータベースが、チェックポイントから復元されたデータベースと同じくらいトランザクションの整合性を保っているとは限らないことです。

    Windows

    Windowsでは、Perforceサービス実行中にシステムバックアップを行う場合、バックアッププログラムがdb.*ファイルのバックアップをしないようにしておく必要があります。

    稼働中のサーバでdb.*ファイルをバックアップしようとすると、それらのファイルはバックアッププログラムによってバックアップされている間Windowsによってロックされます。この間、Perforceはファイルにアクセスできなくなります。ユーザがファイルを更新しようとしても、サーバは受け付けません。

    使用中のバックアップソフトウェアがバックアップのプロセスからdb.*ファイルを除外できない場合、バックアップ開始前にp4 admin stopを実行してサーバを停止させ、バックアップ処理が完了してからサービスを再起動してください。

  6. p4 serveridコマンドを使用してサーバとserver.idファイルを識別していた場合、(サーバのルートディレクトリに存在する)server.idファイルをバックアップする必要があります。

リカバリ手順

データベースファイルが、ディスクエラーにより、あるいはディスククラッシュなどのハードウェア故障により破損または消失してしまったとしても、保存しておいたチェックポイントとジャーナルからデータベースをつくりなおすことができます。

システムにはさまざまな形で不具合が生じるものです。このガイドであらゆる不具合の事例を扱うことはできませんが、少なくとも、以下に最もよく生じやすい2つの状況を想定しながらリカバリの基本的なガイドラインについて解説します。

  • Perforceデータベースのみが破損し、バージョン化ファイルは無事である場合

  • データベースおよびバージョン化ファイルの両方が破損している場合

それぞれの不具合に対するリカバリ手順は少し異なるので、以下の2つのセクションで個別に解説します。

データベースまたはバージョン化ファイルの破損が疑われる場合、Perforceテクニカルサポートまでご連絡ください。

データベースが破損しており、バージョン化ファイルが影響を受けていない場合

データベースのみが破損してしまった場合(つまりdb.*ファイルがクラッシュしたドライブ上に存在する一方で、シンボリックリンクを使用してバージョン化ファイルを別の物理ドライブに保存していた場合)、データベースのみを再作成する必要があります。

必要なものは以下のとおりです。

  • 最後に作成されたチェックポイントファイル。これは、最新のP4ROOTディレクトリバックアップから入手できます。チェックポイントをバックアップした際に対応する.md5ファイルもバックアップしていた場合、チェックポイントのチェックサムと復元された.md5ファイルの内容を比較することにより、チェックポイントが正しく復元されたことを確認できます。

  • カレントジャーナルファイル。これは、P4ROOTディレクトリとは別のファイルシステム上に置かれているため、P4ROOTディレクトリを含むファイルシステムがどんなに破損しようが影響を受けていないはずです。

不要なものは以下のとおりです。

  • バージョン化ファイルのバックアップ。これは、クラッシュの影響を受けていなければ、すでに最新の状態になっています。

データベースをリカバリするには

  1. p4dの現在のインスタンスを停止します。

    p4 admin stop

    (Perforceスーパーユーザでなければp4 adminを使用できません。)

  2. データベース(db.*)のファイル名を変更するか、そのファイルを移動します。

    mv your_root_dir /db.* /tmp

    チェックポイントからリカバリを開始すると、P4ROOTディレクトリにdb.*ファイルが存在しない可能性があります。古いdb.*ファイルがリカバリ中に使用されることはありませんが、復元が正常に完了するまでそれらのファイルを削除しないことを推奨します。

  3. 以下のようなコマンドを使用して、チェックポイントの整合性を検証します。 

    p4d -jv my_checkpoint_file

    以上のコマンドによって検証される項目は以下のとおりです。

    • チェックポイントは冒頭から末尾まで読み取り可能かどうか。

    • 圧縮されている場合、正常に解凍できるかどうか。

    • MD5ファイルがある場合、そのチェックポイントのMD5と一致するかどうか。

    • 想定されるヘッダとトレーラが存在するかどうか。

    圧縮されたチェックポイントの整合性を検証するには、-zフラグと-jvフラグを組み合わせて使用します。

  4. p4dに-jr(journal-restore)フラグを付けて、最近のチェックポイントとカレントジャーナルを指定したうえで起動します。サーバルート(P4ROOT)を明示的に指定する場合、-r $P4ROOT引数を-jrフラグの前方に置く必要があります。また、p4dプロセスはスタートアップ後に作業ディレクトリをサーバルートに変更するので、checkpoint_fileおよびjournal_fileをP4ROOTディレクトリからの相対パスで指定する必要があります。

    p4d -r $P4ROOT -jr checkpoint_file journal_file

    これにより、データベースが最後のチェックポイント作成時点の状態でリカバリされ、その後、チェックポイント作成後のジャーナルファイルのなかに記録されている変更が適用されます。

Note

-z(圧縮)オプションを使用してチェックポイントを作成したと同時に圧縮していた場合、圧縮されたチェックポイントとは別に圧縮されていないジャーナルファイルを復元する必要が生じます。

すなわち、以下のコマンド

p4d -r $P4ROOT -jr checkpoint_file journal_file

を使用する代わりに、以下の2つのコマンドを使用します。

p4d -r $P4ROOT -z -jr checkpoint_file.gz

p4d -r $P4ROOT -jr journal_file

-zフラグを使用する場合、.gz拡張子を手動で指定する必要があります。-r $P4ROOT引数が-jrフラグよりも前に置かれていることを確かめてください。

システムをチェックする

復元は完了しました。復元が正常に完了したことを確認するには、復元後のシステムの整合性を確認するを参照してください。

システムの状態

最近のチェックポイントからリカバリしたデータベースは、カレントジャーナルファイルに保存されていた変更を適用すると、不具合が発生した時点の状態に戻ります。

リカバリ後のデータベースとバージョン化ファイルの両方に、クラッシュした時点までのすべての変更が反映されているはずであり、消失したデータはないはずです。復元が正常に完了した場合、lastCheckpointActionカウンタはチェックポイントの作成完了を示す値に変わります。

データベースおよびバージョン化ファイルの両方が消失または破損している場合

データベースもバージョン化ファイルも破損してしまった場合、データベースとバージョン化ファイルの両方を復元する必要があります。そしてバージョン化ファイルが、復元されるデータベースよりも古くないことを確認する必要があります。

必要なものは以下のとおりです。

  • 最後に作成されたチェックポイントファイル。これは、最新のP4ROOTディレクトリバックアップから入手できます。チェックポイントをバックアップした際に対応する.md5ファイルもバックアップしていた場合、チェックポイントのチェックサムと復元された.md5ファイルの内容を比較することにより、チェックポイントが正しく復元されたことを確認できます。

  • バージョン化ファイル。これは、最新のP4ROOTディレクトリバックアップから入手できます。

不要なものは以下のとおりです。

  • カレントジャーナルファイル。

ジャーナルには、最後のバックアップからクラッシュまでの間に発生したメタデータとバージョン化ファイルに対する変更が記録されています。クラッシュの前に作成されたバックアップからバージョン化ファイルを復元しようとしている以上は、リカバリに役立つメタデータはチェックポイントのみに含まれており、ジャーナルの情報はほとんど役立ちません。

データベースをリカバリするには

  1. p4dの現在のインスタンスを停止します。

    p4 admin stop

    (Perforceスーパーユーザでなければp4 adminを使用できません。)

  2. 破損したデータベース(db.*)のファイル名を変更するか、そのファイルを移動します。

    mv your_root_dir /db.* /tmp

    破損したdb.*ファイルが復元プロセスで使用されることは実際にはありませんが、復元が正常に完了したことを確認するまではそれらのファイルを削除しないことを推奨します。

  3. 最新のチェックポイントのMD5チェックサムと、その作成時点で生成されたチェックサム(対応する.md5ファイルに保存されているチェックサム)とを比較します。

    チェックポイント作成時点で出力された.md5ファイルには、圧縮される前と同じように、ファイルのチェックサムが含まれています。たとえサービスがWindows上でホストされていたとしても、UNIX形式の行末が想定されます。(チェックポイントのファイルが-z圧縮オプションを使用して作成されていた場合、それを解凍して行末の違いを確認したほうがよい場合があります。)

  4. p4dに-jr(journal-restore)フラグを付け、最新のチェックポイントのみを指定しながら起動します。

    p4d -r $P4ROOT -jr checkpoint_file

    これにより、データベースが最後のチェックポイント作成時点の状態でリカバリされます。ただし、ジャーナルファイル中の変更記録は一切適用されていません。(-r $P4ROOT引数を-jrフラグの前方に置く必要があります。また、p4dプロセスはスタートアップ後に作業ディレクトリをサーバルートに変更するので、checkpoint_fileのパスはP4ROOTディレクトリからの相対パスで指定する必要があります。

    データベースをリカバリした後、ジャーナルファイル中の変更記録をロールフォワードしないため、データベースは最後のバックアップ時点の状態になります。この場合、復元後のバージョン化ファイルは最後のチェックポイントと同じ状態のディポのみを反映しているので、ジャーナルファイル中の変更を適用する必要はありません。

バージョン化ファイルをリカバリするには

  1. データベースをリカバリしたら、システム復元手順にしたがって(例えばUNIXrestore(1)コマンドを使用して)バージョン化ファイルがデータベースと同じくらい新しいことを確認し、バージョン化ファイルを復元する必要があります。

システムをチェックする

復元は完了しました。復元が正常に完了したことを確認するには、復元後のシステムの整合性を確認するを参照してください。

最後のシステムバックアップの時点からディスククラッシュの時点までにディポにサブミットされたファイルは、復元後のディポには存在しません。

Note

「新しい」ファイル(言い換えれば、すでにディポにサブミットされていたがまだバックアップされていないファイル)は復元後のディポのなかには現れませんが、そのようなファイルの最新版は1人以上のユーザのクライアントワークスペースに保存されているかもしれません(いえ、きっと保存されています)。

そのようなファイルを見つけるには、各自のクライアントワークスペースにあるファイルとディポのファイルの差異について、以下のPerforceコマンドによる調査をユーザに依頼します。ユーザが

p4 diff -se

というコマンドを実行すると、各自のワークスペースにあるファイルのうち、Perforceが自己の所有ファイルとして認識しないファイルの一覧を取得できます。これらのファイルが実際に復元すべきファイルであることを確認した後で、ユーザのひとりにeditコマンドによってこれらのファイルを開いてもらい、ディポにファイルをチェンジリストとしてサブミットするとよいでしょう。

システムの状態

リカバリ後のディポディレクトリには最新のバージョン化ファイルが存在しない場合があります。すなわち、最後のシステムバックアップからディスククラッシュまでにサブミットされたファイルが消失してしまった場合です。

  • ほとんどの場合、そのようなファイルの最新のリビジョンは、ユーザのクライアントワークスペースに残存しているコピーから復元することができます。

  • バージョン化ファイルのみが失われた場合(つまり、データベースは、別のディスクに保存されていてクラッシュによる影響を受けなかったので、失われていない場合)、データベースのコピーを別に作成し、それにジャーナルを適用して、最近のチェンジリストを調べるという方法をとることもできるでしょう。この方法が成功すれば、最後のバックアップからディスククラッシュまでにサブミットされたファイルを突き止めることができます。

いずれにせよ、さらなる支援が必要な場合にはPerforceテクニカルサポートまでご連絡ください。

復元後のシステムの整合性を確認する

復元後、以下のコマンドを使用してください。

p4 counter lastCheckpointAction

以上のコマンドの目的は、lastCheckpointActionカウンタがチェックポイント作成完了の日時を反映した値に更新されているかどうか確認することにあります。

また、p4 verifyを実行して、バージョン化ファイルがデータベースより古くないことを確認する必要があります。

p4 verify -q //...

以上のコマンドにより、バージョン化ファイルの整合性が検証されます。-q(quiet)オプションを付けることにより、エラーが検出された場合のみ出力が行われます。理想的なのは、このコマンドを実行することによっていかなる出力も行われない状態です。

p4 verifyコマンドによっていずれかのバージョン化ファイルがMISSINGとして報告された場合、データベース関連ファイルのうちに復元されていない情報があることを意味します。この原因は、通常の場合、バージョン化ファイルのバックアップ後に作成されたチェックポイントとジャーナルファイルから復元行ったことにあります(つまり、バージョン化ファイルのバックアップがデータベースよりも古かったのです)。

(推奨しているように)バックアップルーチンの一環としてp4 verifyを使用していた場合、復元後にp4 verifyを実行して、復元が正常に完了したことを確認できます。

クラッシュ後にシステムをうまく復元できない場合、Perforceテクニカルサポートにご連絡いただき、サポートをご依頼ください。