test

Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド

第 9 章 Directory Server のバックアップと復元

Directory Server で管理されるデータは、まとめてインポートされることがよくあります。Directory Server Enterprise Edition には、サフィックス全体のインポートとエクスポートを行うツールが用意されています。また、一度にすべてのサフィックスのバックアップを作成したり、すべてのデータをバックアップから復元したりするツールも用意されています。

バックアップや復元の操作を始める前に、現在の状況に合うバックアップおよび復元戦略を設計するようにしてください。さまざまなバックアップオプション、考慮事項、バックアップおよび復元戦略を計画する際のガイドラインの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「バックアップと復元のポリシーの設計」を参照してください。

この章の内容は次のとおりです。

バイナリバックアップ

この節では、ディレクトリデータのバイナリバックアップを実行する方法について説明します。この節で説明するバイナリバックアップ手順以外にも、サフィックスをレプリケーショントポロジで初期化するためのバイナリコピーを作成できます。「バイナリコピーを使用したレプリケートされたサフィックスの初期化」を参照してください。

ディレクトリデータのみのバックアップ

バイナリデータのバックアップでは、あとでデータベースファイルが破損したり削除されたりする場合に使用できる、ディレクトリデータのコピーを保存できます。この操作では、設定データはバックアップされません。障害回復のために Directory Server 全体をバックアップする場合は、「障害からの回復」を参照してください。

注意 – 注意 –

バックアップの処理中には、サーバーを停止しないでください。

バックアップは、「削除の遅延」よりも頻繁に実行する必要があります。nsDS5ReplicaPurgeDelay 属性によって指定される削除の遅延は、更新履歴ログに対して内部削除操作を開始するまでの期間 (秒単位) です。デフォルトの削除の遅延は 604800 秒 (1 週間) です。更新履歴ログは、レプリケートが完了している、またはレプリケートが完了していない更新の記録を保持しています。

更新の頻度が削除の遅延より低い場合、バックアップを行う前に更新履歴ログの内容がクリアされてしまう可能性があります。この場合、バックアップからデータを復元しようとしても、バックアップ前にクリアされた更新記録は失われています。

この節で説明するバックアップ手順では、サーバーファイルのコピーがデフォルトで同じホスト上に格納されます。セキュリティー強化のために、このバックアップを別のマシンや別のファイルシステムにコピーして格納してください。

Procedureディレクトリデータをバックアップする

Directory Server を停止して dsadm backup コマンドを実行する必要があります。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. ディレクトリデータをバックアップします。


    $ dsadm backup instance-path archive-dir

    次に例を示します。


    $ dsadm backup /local/ds /local/tmp/20051205
    注 –

    サーバーの稼働中は、dsconf backup コマンドを使用してディレクトリデータをバックアップできます。ただし、バックアップの実行中にディレクトリデータに変更を加えると、適切に復旧することが難しくなります。dsconf backup の使用時にこの問題を回避するには、レプリケーションのリフェラルを設定するか、サーバーを読み取り専用にします。

    dsadm コマンドと dsconf コマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

Proceduredse.ldif ファイルをバックアップする

サーバーを復元する場合、dse.ldif 設定ファイルに、サーバーのバックアップ時と同じ設定情報を指定する必要があります。

  1. dse.ldif 設定ファイルをバックアップします。 


    $ cp instance-path/config/dse.ldif archive-dir

    次の操作を実行すると、Directory Server は自動的に dse.ldif 設定ファイルのバックアップをディレクトリ instance-path/config に作成します。

    • Directory Server を起動すると、dse.ldif ファイルのバックアップが、dse.ldif.startOK というファイルに作成されます。

    • cn=config ブランチの内容を変更する場合は、サーバーが dse.ldif ファイルに変更を書き込む前に、ファイルが onfigディレクトリの dse.ldif.bak ファイルにバックアップされます。

ファイルシステムのバックアップ

この手順では、「凍結モード」機能を使用します。凍結モードでは、ディスク上のデータベース更新を停止できるため、ファイルシステムのスナップショットを安全に撮ることができます。堅固なバックアップを確実にするため、凍結モードを追加の手段として使用できます。

ファイルシステムのバックアップの進行中は、サーバーでディスク上のユーザーデータを書き込むことはできません。特定の時間内に更新が行われないことが確実な場合は、この時間内にバックアップを行います。更新が行われないことを保証できない場合は、バックアップを行う前にサーバーを凍結モードにします。

凍結モードのサーバーでは、アクセスログとエラーログへの書き込みが継続されます。シングルサーバーのトポロジでは、凍結モードがオンの場合に受信される操作によって LDAP エラーが返されます。ログに記録されるエラーメッセージは、オフラインのデータベースに対する標準的なエラーです。レプリケートされたトポロジでは、リフェラルが返されます。凍結モードを適切に機能させるには、データベース上でほかのタスクを実行しないようにしてください。

凍結モードのサーバーのデータベースは、読み取り専用モードのデータベースより安定しています。凍結モードとは異なり、読み取り専用モードでは、タスクの作成と設定エントリの変更ができます。凍結モードがオンの場合、設定されたすべてのデータベースはオフラインになります。進行中の内部操作には、オフラインになるデータベースが通知されます。進行中の LDAP 操作は完了し、データベース環境はフラッシュします。ユーザーデータの検索を含むそれ以降の着信操作は、凍結モードがオフに設定されるまで拒否されます。ただし、凍結モードがオンの場合でも設定パラメータの検索はできます。

Procedureファイルシステムをバックアップする

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. (省略可能) サーバーを凍結モードにします。


    $ dsconf set-server-prop -h host -p port read-write-mode:frozen

  2. ファイルシステムのタイプに合うツールを使って、ファイルシステムをバックアップします。

  3. サーバーが凍結モードになっている場合は、再度サーバーを読み書き可能にします。


    $ dsconf set-server-prop -h host -p port read-write-mode:read-write

    サーバーがレプリケーションの更新を別のサーバーから受け取った場合は、凍結モードがオフになるとすぐにレプリケーションの更新が始まります。

LDIF へのバックアップ

LDIF へのバックアップにより、ディレクトリデータを書式付き LDF ファイルにバックアップできます。

LDIF へのエクスポート

LDIF でサフィックスの内容をエクスポートすることで、ディレクトリデータをバックアップできます。データのエクスポートは、次のような場合に便利です。

エクスポート処理を実行しても、設定情報 (cn=config) はエクスポートされません。

注意 – 注意 –

エクスポート処理の実行中には、サーバーを停止しないでください。

Procedureサフィックスを LDIF にエクスポートする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. サフィックスを LDIF ファイルにエクスポートするには、次のコマンドのいずれかを使用します。

    • サーバーがローカルにあり、停止している場合は、次のように入力します。


      $ dsadm export instance-path suffix-DN LDIF-file

    • サーバーがリモートにあり、実行中の場合は、次のように入力します。


      $ dsconf export -h host -p port suffix-DN LDIF-file

    次の例では、dsconf export を使用して、2 つのサフィックスを単一の LDIF ファイルにエクスポートします。


    $ dsconf export -h host1 -p 1389 ou=people,dc=example,dc=com \
 ou=contractors,dc=example,dc=com /local/ds/ldif/export123.ldif

    dsadm export コマンドと dsconf export コマンドでは、--no-repl オプションを指定して、レプリケーション情報がエクスポートされないように指定することもできます。デフォルトでは、レプリケートされたサフィックスはレプリケーション情報とともに LDIF ファイルにエクスポートされます。結果として作成される LDIF ファイルには、レプリケーションメカニズムで使用される属性サブタイプが含まれています。あとでこの LDIF ファイルをコンシューマサーバーにインポートして、コンシューマレプリカを初期化できます。この手順については、「レプリカの初期化」を参照してください。

    これらのコマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

バイナリ復元

次に示す手順では、サフィックスをディレクトリに格納する方法を示します。サーバーは、「ディレクトリデータのみのバックアップ」で説明した手順で、あらかじめバックアップされている必要があります。レプリケーションアグリーメントに関連するサフィックスを復元する前に、「レプリケートされたサフィックスの復元」をお読みください。

注意 – 注意 –

復元の処理中には、サーバーを停止しないでください。サーバーを復元すると既存のデータベースファイルが上書きされるため、バックアップのあとに行なった変更は失われます。

Procedureサーバーを復元する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. サーバーを復元するには、次のコマンドのいずれかを使用します。

    • サーバーがローカルにあり、停止している場合は、次のように入力します。


      $ dsadm restore instance-path archive-dir

      たとえば、バックアップをバックアップディレクトリから復元するには、次のように入力します。


      $ dsadm restore /local/ds/ local/ds/bak/2006_07_01_11_34_00

    • サーバーがリモートにあり、実行中の場合は、次のように入力します。


      $ dsconf restore -h host -p port archive-dir

      たとえば、バックアップをバックアップディレクトリから復元するには、次のように入力します。


      $ dsconf restore -h host1 -p 1389 /local/ds/bak/2006_07_01_11_34_00

    これらのコマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

dse.ldif 設定ファイルの復元

Directory Server では、次のディレクトリ内に、dse.ldif ファイルのバックアップコピーが 2 つ作成されます。


instance-path/config

dse.ldif.startOK ファイルには、サーバー起動時に dse.ldif ファイルのコピーが記録されます。dse.ldif.bak ファイルには、dse.ldif ファイルに加えられた最新の変更内容のバックアップが含まれます。最新の変更内容を含むファイルを自分のディレクトリにコピーします。

Proceduredse.ldif 設定ファイルを作成する

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. サーバーを停止します。


    $ dsadm stop instance-path

  2. 設定ファイルが入っているディレクトリに移動します。


    $ cd instance-path/config

  3. 有効であることがわかっているバックアップ設定ファイルで dse.ldif ファイルを上書きします。たとえば、次のように入力します。


    $ cp dse.ldif.startOK dse.ldif

  4. 次のコマンドでサーバーを起動します。


    $ dsadm start instance-path

LDIF ファイルからのデータのインポート

次のような方法で、データを Directory Server サフィックスにインポートできます。

次の表は、サフィックスの初期化と、エントリの一括の追加、変更、削除の違いを示しています。

表 9–1 サフィックスの初期化とデータの一括インポートの比較

比較ドメイン 

サフィックスの初期化 

エントリの一括の追加、変更、削除 

内容の上書き 

内容の 

上書き 

内容を上書きしない 

LDAP 処理 

追加のみ 

追加、変更、削除 

性能 

高速 

低速 

サーバーの障害への対応 

不可 (障害が発生するとすべての変更内容は失われる) 

ベストエフォート (障害発生時までの変更内容はそのまま残る) 

LDIF ファイルの位置 

クライアントまたはサーバーと同じマシン上 

クライアントマシン上 

設定情報のインポート (cn=config)

設定情報をインポートする 

設定情報をインポートしない 

コマンド (Commands) 

サーバーがローカルにあり、停止している場合: 

dsadm import

サーバーがリモートにあり、実行中の場合: 

dsconf import

ldapmodify -B

サフィックスの初期化

サフィックスを初期化すると、サフィックスに含まれている既存のデータが、追加するエントリだけを含む LDIF ファイルの内容によって上書きされます。

サフィックスを初期化するユーザーは、ディレクトリマネージャーまたは管理者としての認証を受けている必要があります。

サーバーが実行中の場合、ルートエントリを含む LDIF ファイルをインポートできるのは、ディレクトリマネージャーと管理者のみです。セキュリティー上の理由により、これらのユーザーのみが、たとえば dc=example,dc=com. のようなサフィックスのルートエントリへのアクセス権を持ちます。

レプリケーションアグリーメントに関連するサフィックスを復元する前に、「レプリケートされたサフィックスの復元」をお読みください。

Procedureサフィックスを初期化する

注 –

インポートする LDIF ファイルでは、UTF-8 文字セットエンコードが使用されている必要があります。

サフィックスを初期化するときは、ルートエントリと、対応するサフィックスのすべてのディレクトリツリーノードが LDIF ファイルに含まれている必要があります。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. 次のコマンドのいずれかを使用して、LDIF ファイルからサフィックスを初期化します。つまり、データベースの内容を LDIF ファイルにインポートします。

    注意 – 注意 –

    次のコマンドで、サフィックスのデータを上書きします。

    • サーバーがローカルにあり、停止している場合は、次のように入力します。


      $ dsadm import instance-path LDIF-file suffix-DN

      次の例では、dsadm import コマンドを使用して、LDIF ファイルを 1 つのサフィックスにインポートします。


      $ dsadm import /local/ds /local/file/example/demo1.ldif \
 /local/file/example/demo2.ldif dc=example,dc=com

    • サーバーがリモートにあり、実行中の場合は、次のように入力します。


      $ dsconf import -h host -p port LDIF-file suffix-DN

      次の例では、dsconf import を使用して LDIF ファイルをインポートします。このコマンドを実行するために root 権限は必要ありませんが、ディレクトリマネージャーなどの root 権限を持つユーザーとして認証される必要があります。


      $ dsconf import -h host1 -p 1389 /local/file/example/demo1.ldif \
 ou=People,dc=example,dc=com
    注 –

    dsconf import か dsconf reindex のいずれか、または複数のサフィックスで並行して両方のコマンドを実行すると、トランザクションログが大きくなり、パフォーマンスに悪影響を及ぼすことがあります。

    これらのコマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

エントリの一括の追加、変更、削除

ldapmodify 操作を実行すると、エントリをまとめて追加、変更、削除できます。エントリは、既存のエントリを変更または削除するための更新文を含む LDIF ファイルに指定されています。この操作では、すでに存在しているエントリは消去されません。

変更されたエントリは、Directory Server で管理されるサフィックスの対象となることがあります。エントリを追加するほかの処理と同様に、インポートされた新しいエントリすべてにインデックスが付けられます。

ldapmodify コマンドにより、LDAP によって LDIF ファイルがインポートされ、このファイルに含まれるすべての操作が実行されます。このコマンドを使用すると、すべてのディレクトリサフィックスのデータを同時に変更できます。

レプリケーションアグリーメントに関連するサフィックスを復元する前に、「レプリケートされたサフィックスの復元」を参照してください。

Procedureエントリをまとめて追加、変更、削除する

注 –

インポートする LDIF ファイルでは、UTF-8 文字セットエンコードが使用されている必要があります。

LDIF をインポートするときは、ディレクトリ内に親エントリが存在するか、ファイルから親エントリを最初にコピーする必要があります。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. LDIF ファイルからまとめて追加、変更、または削除します。


    $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -B baseDN -f LDIF-file

    次の例では、ldapmodify コマンドを使用してインポートが実行されます。このコマンドを実行するために root 権限は必要ありませんが、cn=Directory Manager や cn=admin,cn=Administrators,cn=config などの root 権限を持つユーザーとして認証される必要があります。最後のパラメータは、インポートする LDIF ファイルの名前を指定するものです。


    $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - \
 -B dc=example,dc=com -f /local/ds/ldif/demo.ldif

レプリケートされたサフィックスの復元

サプライヤサーバーとコンシューマサーバーの間でレプリケートされるサフィックスを復元する場合は、特別な注意が必要です。可能な場合は、サフィックスをバックアップから復元するのではなく、レプリケーションメカニズムにより更新するようにしてください。

サプライヤまたはハブインスタンスを復元する場合、サーバーはバックアップ時と同じ設定にする必要があります。これを確実に実行するには、Directory Server データを復元する前に、dse.ldif ファイルを復元します。「dse.ldif 設定ファイルの復元」を参照してください。

ここでは、レプリカを復元すべき場合とその方法、および復元後にほかのレプリカとの同期を確保する方法について説明します。レプリカの初期化については、「レプリカの初期化」を参照してください。

レプリケートされたサフィックスが大規模で、多数のエントリを追加し、レプリケーションの更新を確実に正しく追加されるようにする場合は、「大量のレプリケートされたサフィックスへの多数のエントリの段階的追加」を参照してください。

この節では、次の情報について説明します。

シングルマスターモデルでのサプライヤの復元

シングルマスターサプライヤであるサフィックスには、レプリケーショントポロジ全体に対して重要なデータ (authoritative data) が含まれています。したがって、このサフィックスを復元することは、トポロジ全体のすべてのデータを初期化し直すことと同じです。シングルマスターを復元するのは、復元するバックアップの内容ですべてのデータを初期化し直す場合に限定してください。

エラーのためにシングルマスターのデータを復旧できない場合は、コンシューマ上のデータを使用することも検討してください。これは、バックアップされたデータより新しい更新がコンシューマ上のデータに含まれている可能性があるためです。この場合は、コンシューマレプリカから LDIF ファイルにデータをエクスポートし、この LDIF ファイルを使用してマスターを初期化し直します。

バックアップから復元する場合でも、LDIF ファイルをインポートする場合でも、このマスターレプリカから更新を受け取るすべてのハブレプリカとコンシューマレプリカをあとで初期化し直す必要があります。コンシューマの再初期化が必要であることを示すメッセージが、サプライヤサーバーのログファイルに記録されます。

マルチマスターモデルでのサプライヤの復元

マルチマスターレプリケーションでは、ほかの各マスターも、レプリケートされるデータに対してコピーする権限を持っています。現在のレプリカの内容が反映されていない可能性があるため、古いバックアップを復元することはできません。可能な場合は、レプリケーションメカニズムにより、ほかのマスターの内容を使用してマスターを更新するようにしてください。

それが不可能な場合は、次のどちらかの方法でマルチマスターレプリカを復元してください。

復元や再初期化の方法にかかわらず、初期化後のマスターレプリカは読み取り専用モードになります。この動作により、このレプリカとほかのマスターとの同期をとったあとに、書き込み操作を許可できます。詳細は、「マルチマスターモデルでのマスターの復元」を参照してください。

復元または初期化し直したマスターに書き込み操作を許可する前に、すべてのレプリカを反映させることができるので、ハブサーバーやコンシューマサーバーを初期化し直すことが不要になるという利点があります。

ハブの復元

この節の内容は、レプリケーションメカニズムで自動的にハブレプリカを更新できない場合だけに適用されます。このような状況として、データベースファイルが破損した場合や、レプリケーションが長時間にわたって中断された場合が含まれます。このような場合は、次のいずれかの方法で、ハブレプリカを復元または初期化し直す必要があります。

注 –

ハブレプリカの復元や再初期化の方法にかかわらず、あとでこのハブのコンシューマをすべて初期化し直す必要があります。ほかのレベルのハブもすべて初期化し直す必要があります。

専用コンシューマの復元

この節の内容は、レプリケーションメカニズムで自動的に専用コンシューマレプリカを更新できない場合だけに適用されます。このような状況として、データベースファイルが破損した場合や、レプリケーションが長時間にわたって中断された場合が含まれます。このような場合は、次のいずれかの方法で、コンシューマを復元または初期化し直す必要があります。

マルチマスターモデルでのマスターの復元

マルチマスターレプリケーションでは、あるマスターの復元中に他のマスターが変更を処理することもあります。このため、復元が完了した時点で、新しいマスターは復元データに含まれていなかった新しい更新を受け取る必要があります。マスターの復元には時間がかかるため、その間に発生する未適用の更新の数も問題となることがあります。

これらの未適用更新が適用されるように、新たに復元されたマスターは、復元後、クライアント側からの操作に対して自動的に読み取り専用モードに設定されます。これは、コマンド行で LDIF ファイルからデータをインポートするか、バックアップを使用してバイナリコピーを実行することで、マスターを復元する場合のみに当てはまります。

したがって、マルチマスター設定の復元後のマスターは、レプリケーションの更新を処理し、クライアントからの読み取り操作を受け付けますが、すべての書き込み操作に対してはリフェラルを返します。

更新を許可する前に、新しいマスターがほかのマスターと完全に同期していることを確認するには、初期化されたマスターを手動で更新できるようにします。

注 –

この新しい対応方法によってマスターレプリカがリフェラルを送信する場合、書き込み処理を待機しているクライアントのホップ回数が、制限回数に達してしまうことも考えられます。利用可能なマスターにアクセスできるように、クライアントのホップ制限の設定を変更する必要があるかもしれません。すべてのマスターレプリカを初期化または再初期化するときは、どのレプリカもクライアントからの更新を受け付けられないため、すべての書き込み処理が失敗します。

サーバーの応答を最大化するには、いかなる場合も初期化したマスターを注意深く監視し、リフェラルの属性を適切に設定してください。

Procedureコマンド行による更新の受け付けを開始する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

次のコマンドは、マルチマスターレプリカの初期化プロセスを自動化するスクリプトで使用できます。

  1. insync ツールを使用して、レプリカの状態が他のすべてのマスターと一致していることを確認します。

    すべてのサーバーで変更の遅れがゼロである場合、またはそのレプリカに適用する更新がなかった場合 (遅れが -1 となる場合) は、すべてのレプリカが同期しています。詳細については、insync(1) のマニュアルページを参照してください。

  2. 更新の受け付けを始めます。


    $ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on

    このコマンドは、サーバーを自動的に読み書きモードに設定します。

障害からの回復

Directory Server を障害回復の目的でバックアップまたは復元する場合は、次の手順に従います。

Procedure障害回復用のバックアップを作成する

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. dsadn backup コマンドまたは dsconf backup コマンドを使用して、データベースファイルのバックアップを作成します。

    「バイナリバックアップ」で説明する手順に従い、バックアップファイルを安全な場所に保管します。

  2. 設定ディレクトリ instance-path /config を安全な場所にコピーします。

  3. スキーマディレクトリ instance-path/config/schema を安全な場所にコピーします。

  4. 別名ディレクトリ instance-path/alias を安全な場所にコピーします。

Procedure障害回復のために復元する

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. すでにホスト上にあるものと同じバージョンの Directory Server をインストールします。

  2. dsadm create コマンドを使用して、サーバーインスタンスを作成します。

    バックアップ時に使用したものと同じインスタンスを使用します。「サフィックスの作成」を参照してください。

  3. 設定ディレクトリ instance-path /config を復元します。

  4. スキーマディレクトリ instance-path/config/schema を復元します。

  5. 別名ディレクトリ instance-path/alias を復元します。

  6. 復元されたサーバーの設定が正しいことを確認します。

    たとえば、ディレクトリ構造とプラグイン設定は、バックアップサーバー上のものと同じものにする必要があります。

  7. dsconf restore コマンドを使用して、データベースファイルを復元します。

    「バイナリ復元」で説明した手順に従います。