データベースおよびバージョン化ファイルの両方が消失または破損している場合
データベースおよびバージョン化ファイルが破損した場合、データベースとバージョン化ファイルの両方を復元する必要があります。そしてバージョン化ファイルが、復元されるデータベースよりも古くないことを確認する必要があります。
必要なものは以下のとおりです。
- 最後に作成されたチェックポイントファイル。これは、最新の
P4ROOTディレクトリバックアップから入手できます。チェックポイントをバックアップした際に対応する.md5ファイルもバックアップしていた場合、チェックポイントのチェックサムと復元された.md5ファイルの内容を比較することにより、チェックポイントが正しく復元されたことを確認できます。 - バージョン化ファイル。これは、最新の
P4ROOTディレクトリバックアップから入手できます。
不要なものは以下のとおりです。
- カレントジャーナルファイル。
ジャーナルには、最後のバックアップからクラッシュまでの間に発生したメタデータとバージョン化ファイルに対する変更が記録されています。クラッシュの前に作成されたバックアップからバージョン化ファイルを復元しようとしているため、リカバリに役立つメタデータはチェックポイントのみに含まれており、ジャーナルの情報はほとんど役立ちません。
データベースをリカバリする
-
p4dの現在のインスタンスを停止します。$ p4 admin stop
(Helixサーバスーパーユーザでなければ
p4 adminを使用できません。) -
破損したデータベース(
db.*)のファイル名を変更するか、そのファイルを移動します。$ mv your_root_dir /db.* /tmp
破損した
db.*ファイルが復元プロセスで使用されることは実際にはありませんが、復元が正常に完了したことを確認するまではそれらのファイルを削除しないことを推奨します。 -
最新のチェックポイントのMD5チェックサムと、その作成時点で生成されたチェックサム(対応する
.md5ファイルに保存されているチェックサム)とを比較します。チェックポイント作成時点で出力された
.md5ファイルには、圧縮される前と同じように、ファイルのチェックサムが含まれています。たとえサービスがWindows上でホストされていたとしても、UNIX形式の行末が想定されます。(チェックポイントのファイルが-z圧縮オプションを使用して作成されていた場合、それを解凍して行末の差異を確認したほうがよい場合があります。) -
p4dに-jr(journal-restore)フラグを付け、最新のチェックポイントのみを指定しながら起動します。$ p4d -r $P4ROOT -jr checkpoint_file
これにより、データベースが最後のチェックポイント作成時点の状態でリカバリされます。ただし、ジャーナルファイル内の変更は適用しません。(
-r $P4ROOT引数を-jrフラグの前方に置く必要があります。また、p4dプロセスは起動時に作業ディレクトリをサーバルートに変更するので、checkpoint_fileのパスはP4ROOTディレクトリからの相対パスで指定する必要があります。ジャーナルファイル内の変更をロールフォワードせずにデータベースをリカバリすると、データベースは最後のバックアップ時点の状態になります。この場合、復元後のバージョン化ファイルは最後のチェックポイントと同じ状態のディポのみを反映しているため、ジャーナルファイル内の変更を適用する必要はありません。
バージョン化ファイルをリカバリする
データベースをリカバリした後、システム復元手順にしたがって(例えば、UNIXrestore(1)コマンドを使用して)バージョン化ファイルがデータベースと同じ程度新しいことを確認し、バージョン化ファイルを復元する必要があります。
システムをチェックする
復元は完了しました。復元が正常に完了したことを確認するには、「復元後のシステムの整合性を確認する」を参照してください。
最後のシステムバックアップからディスククラッシュまでの間にディポにサブミットされたファイルは、復元後のディポには存在しません。
「新しい」ファイル(既にディポにサブミットされていたがまだバックアップされていないファイル)は復元後のディポ内には表示されませんが、そのようなファイルの最新のコピーが1人以上のユーザのクライアントワークスペースに保存されている可能性があります(保存されている可能性はきわめて高いです)。
ユーザがそのようなファイルを見つけるには、各自のクライアントワークスペースにあるファイルとディポのファイルの差異を、次のHelixサーバコマンドを使用して調べます。以下のコマンドを実行します。
$ p4 diff -se
これにより、各自のワークスペースにあるファイルのうち、Helixサーバが自己の所有ファイルとして認識しないファイルの一覧を取得できます。これらのファイルが実際に復元すべきファイルであることを確認した後、ユーザの1人にeditコマンドによってこれらのファイルを開いてもらい、チェンジリスト内のディポにファイルをサブミットするとよいでしょう。
システムの状態
リカバリ後のディポディレクトリには最新のバージョン化ファイルが存在しない場合があります。すなわち、最後のシステムバックアップからディスククラッシュまでにサブミットされたファイルが消失してしまった場合です。
- ほとんどの場合、そのようなファイルの最新のリビジョンは、ユーザのクライアントワークスペースに残存しているコピーから復元することができます。
- バージョン化ファイルのみが失われた場合(つまり、データベースは、別のディスクに保存されていてクラッシュによる影響を受けなかったため、失われていない場合)、データベースのコピーを別に作成し、それにジャーナルを適用して、最近のチェンジリストを調べるという方法をとることもできます。この方法が成功すれば、最後のバックアップからディスククラッシュまでにサブミットされたファイルを突き止めることができます。
いずれの場合も、追加のサポートが必要な場合は、Perforceテクニカルサポートまでご連絡ください。
