Tchater maintenant avec le support
Tchattez avec un ingénieur du support

NetVault Plug-in for MySQL 4.4 - ユーザーズ・ガイド

Dell™ NetVault™ Backup Plug-in for MySQL － はじめに プラグインのインストールと削除 プラグインの設定 データのバックアップ データのリストア MySQLレプリケーションの使用 フェイルオーバ・クラスタ環境でのプラグインの使用 トラブルシューティング Dellについて

フルおよび増分バックアップによるリストア・シナリオ

DBAはフル・バックアップを毎週日曜日の午後11時に、増分バックアップを月～土曜の午後11時に実行するバックアップ・ポリシーを作成しました。DBAは増分バックアップを実行しているため、各増分バックアップの実行後バイナリ・ログは削除されます。これにより、全体的なバックアップ時間は短くなりますが、リストアにはより多くの時間と手順が必要になります。
フルおよび増分リストアのみ
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の木曜日午前に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、最後の増分バックアップ、つまり水曜日の夜に実行されたバックアップの時点までを完全にリカバリすることを決定しました。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：水曜日からの増分リストア
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始します。
フル・リストアと時間に基づく特定時点リカバリ
以降の例では、フル/増分バックアップ・シナリオを取り上げます。データベース管理者はデータを特定時点にリカバリしようと考えています。
方法1：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が水曜日の夜8:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を19:59、2011年1月31日（水曜日の日付の午後8:00の1分前）に設定しました。
3
ジョブを開始します。
方法2：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、午後8時にdrop tableコマンドが実行された直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順4：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を19:59、2011年1月31日（水曜日の日付の午後8:00の1分前）に設定しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除より後の時刻と日付を［開始日／時間］オプションに入力しました。最後に、バックアップに含まれるバイナリ・ログ・ファイルを最後までリカバリするために、［開始日／時間］オプションで［なし］ラジオ・ボタンを選択しました。
3
ジョブを開始します。
方法3：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が木曜日の午前06:00:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順4：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［現在のバイナリ・ログを含む］ － 水曜日にバックアップが完了してからdrop tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にしました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を5:59、2011年1月31日（木曜日の日付の午前6:00の1分前）に設定しました。
3
ジョブを開始します。
方法4：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［現在のバイナリ・ログを含む］ － 水曜日にバックアップが完了してからdrop tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にしました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を5:59、2011年1月31日（木曜日の日付の午前6:00の1分前）に設定しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除より後の時刻と日付を［開始日／時間］オプションに入力しました。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、［開始日／時間］オプションで［なし］ラジオ・ボタンを選択しました。
3
ジョブを開始します。
フル・リストアと位置に基づく特定時点リカバリ
以降の例では、フル/増分バックアップ・シナリオを取り上げます。データベース管理者は、より確実な方法で時刻を特定し、データを特定時点にリカバリしようと考えています。これは、MySQLバイナリ・ログ・ファイル内で特定した位置の値を使用して行います。
方法1：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。これを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：バックアップされたバイナリ・ログをリストアして誤ったSQLステートメントの位置を特定する
この手順では、水曜日の夜の差分バックアップに記録されたバイナリ・ログについてテンポラリ・ロケーションへのリストアのみを実行します。これにより、データベース管理者はログで、Ordersテーブルが削除された時のマークが付けられた位置を見つけることができます。
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する］ - 水曜日の夜の増分バックアップに含まれるバイナリ・ログ・ファイルについてリストアのみを実行するために、このオプションを選択しました。
•
［時間に基づくPIT］ － データベース管理者は、［Point In Time（特定時点）タイプ］としてこのオプションが選択されていることを確認しましたが、［時間に基づくPITの詳細］セクションに表示されるその他すべてのオプションは選択解除したままにしました。
3
ジョブを開始して完了するまで待つ。
手順5：リストアされたバイナリ・ログでdropped tableコマンドの位置を特定する
リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者は、drop tableステートメントが、MySQLサーバのテンポラリ・ロケーションにリストアされたMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました（また、これらの両方の値をメモしました）。
手順6：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された増分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリからのバイナリ・ログを適用する］ － 一連の操作の最後の手順で、テンポラリ・ロケーションにリストアしたバイナリ・ログをターゲットにするために、このオプションを選択しました。リストアしたバイナリ・ログ・ファイルでdropped tableコマンドが記録されている位置を特定したため、これと同じバイナリ・ログ・ファイルがプラグインで使用されるようにこのオプションを選択します。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル（MYSQLSVR-bin.000009）を選択しました。
3
ジョブを開始します。
方法2：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。これを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：バックアップされたバイナリ・ログをリストアして誤ったSQLステートメントの位置を特定する
この手順では、水曜日の夜の差分バックアップに記録されたバイナリ・ログについてテンポラリ・ロケーションへのリストアのみを実行します。これにより、データベース管理者はログで、Ordersテーブルが削除された時のマークが付けられた位置を見つけることができます。
1
［水曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する］ - 水曜日の夜の増分バックアップに含まれるバイナリ・ログ・ファイルについてリストアのみを実行するために、このオプションを選択しました。
•
［時間に基づくPIT］ － データベース管理者は、［Point In Time（特定時点）タイプ］としてこのオプションが選択されていることを確認しましたが、［時間に基づくPITの詳細］セクションに表示されるその他すべてのオプションは選択解除したままにしました。
3
ジョブを開始して完了するまで待つ。
手順5：リストアされたバイナリ・ログでdropped tableコマンドの位置を特定する
リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者は、drop tableステートメントが、MySQLサーバのテンポラリ・ロケーションにリストアされたMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました（また、これらの両方の値をメモしました）。
手順6：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された増分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリからのバイナリ・ログを適用する］ － 一連の操作の最後の手順で、テンポラリ・ロケーションにリストアしたバイナリ・ログをターゲットにするために、このオプションを選択しました。リストアしたバイナリ・ログ・ファイルでdropped tableコマンドが記録されている位置を特定したため、これと同じバイナリ・ログ・ファイルがプラグインで使用されるようにこのオプションを選択します。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル（MYSQLSVR-bin.000009）を選択しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － データベース管理者はこのオプションを選択し、［開始位置］を806（現在のバイナリ・ログ・ファイルの、mysqlbinlogで特定したdropped tableコマンドの位置の後にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル（MYSQLSVR-bin.000009）を選択しました。最後に、指定したバイナリ・ログ・ファイルを最後までリカバリするために、［開始日／時間］オプションで［なし］ラジオ・ボタンを選択しました。
 
* 
IMPORTANT: 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。
3
ジョブを開始します。
方法3：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が木曜日の午前06:00:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。これを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：現在のバイナリ・ログでdropped tableコマンドの位置を特定する
現在のバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者はdrop tableステートメントがMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました。
手順5：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された増分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － バックアップに含まれているバイナリ・ログ・ファイルをプラグインで使用するよう指定するために、このオプションを選択します。
•
［現在のバイナリ・ログを含む］ － データベース管理者はこのオプションを選択し、NetVault Backupで現在のバイナリ・ログも使用して、水曜日の夜の増分バックアップの後に実行されたすべてのデータベース・トランザクションを適用するよう指定しました。これにより、水曜日の夜に増分バックアップが完了してからdrop tableコマンドが発行されるまでの間に実行されたすべてのトランザクションがリカバリされます。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを［OTHER FILE］に設定し、現在のバイナリ・ファイルの名前（MYSQLSVR-bin.000009など）をテキスト・ボックスに入力しました。
方法4：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が木曜日の午前06:00:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。これを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：月曜日からの増分リストア
1
［月曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順3：火曜日からの増分リストア
1
［火曜日の夜からの増分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順4：現在のバイナリ・ログでdropped tableコマンドの位置を特定する
現在のバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者はdrop tableステートメントがMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました。
手順5：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された増分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － バックアップに含まれているバイナリ・ログ・ファイルをプラグインで使用するよう指定するために、このオプションを選択します。
•
［現在のバイナリ・ログを含む］ － データベース管理者はこのオプションを選択し、NetVault Backupで現在のバイナリ・ログも使用して、水曜日の夜の増分バックアップの後に実行されたすべてのデータベース・トランザクションを適用するよう指定しました。これにより、水曜日の夜に増分バックアップが完了してからdrop tableコマンドが発行されるまでの間に実行されたすべてのトランザクションがリカバリされます。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを［OTHER FILE］に設定し、現在のバイナリ・ファイルの名前（MYSQLSVR-bin.000009など）をテキスト・ボックスに入力しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － データベース管理者はこのオプションを選択し、［開始位置］を806（現在のバイナリ・ログ・ファイルの、mysqlbinlogで特定したdropped tableコマンドの位置の後にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを［OTHER FILE］に設定し、現在のバイナリ・ファイルの名前（MYSQLSVR-bin.000009など）をテキスト・ボックスに入力しました。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、［停止位置］オプションで［なし］ラジオ・ボタンを選択しました。
 
* 
IMPORTANT: 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。

フルおよび差分バックアップによるリストア・シナリオ

DBAはフル・バックアップを毎週日曜日の午後11時に、差分バックアップを月～土曜の午後11時に実行するバックアップ・ポリシーを作成しました。DBAは差分バックアップを実行するため、このバックアップの各フォーム後にバイナリ・ログが保持されます。そのため、バックアップは長くなりますが、総合的なリストアは高速になります。
フルおよび差分リストアのみ
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の木曜日午前に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、最後の差分バックアップ、つまり水曜日の夜に実行されたバックアップの時点までを完全にリカバリすることを決定しました。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：水曜日からの増分リストア
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － ［オプション］タブのどのオプションも使用しません。
3
ジョブを開始します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
フル・リストアと時間に基づく特定時点リカバリ
以降の例では、フル/差分バックアップ・シナリオを取り上げます。データベース管理者はデータを特定時点にリカバリしようと考えています。
方法1：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が水曜日の夜8:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。このことから、以下の手順を実行します。
手順1：日曜日の夜からのフル・リストアを実行
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を19:59、2011年1月31日（水曜日の日付の午後8:00の1分前）に設定しました。
3
ジョブを開始します。
方法2：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、午後8時にdrop tableコマンドが実行された直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を19:59、2011年1月31日（水曜日の日付の午後8:00の1分前）に設定しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除より後の時刻と日付を［開始日／時間］オプションに入力しました。最後に、リストアしたバイナリ・ログ・ファイルを最後までリカバリするために、［開始日／時間］オプションで［なし］ラジオ・ボタンを選択しました。
3
ジョブを開始します。
方法3：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が木曜日の午前06:00:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［現在のバイナリ・ログを含む］ － 水曜日にバックアップが完了してからdrop tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にしました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を5:59、2011年1月31日（木曜日の日付の午前6:00の1分前）に設定しました。
3
ジョブを開始します。
方法4：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。このことから、以下の手順を実行します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：水曜日からの時間に基づくPITリストア
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定しました。
•
［現在のバイナリ・ログを含む］ － 水曜日にバックアップが完了してからdrop tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にしました。
•
［時間に基づくPIT］ － リストア・タイプとして選択しました。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［中止日／時間］を5:59、2011年1月31日（木曜日の日付の午前6:00の1分前）に設定しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除より後の時刻と日付を［開始日／時間］オプションに入力しました。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、［開始日／時間］オプションで［なし］ラジオ・ボタンを選択しました。
3
ジョブを開始します。
フル・リストアと位置に基づく特定時点リカバリ
以降の例では、フル/増分バックアップ・シナリオを取り上げます。データベース管理者は、より確実な方法で時刻を特定し、データを特定時点にリカバリしようと考えています。これは、MySQLバイナリ・ログ・ファイル内で特定した位置の値を使用して行います。
方法1：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ
手順2：バックアップされたバイナリ・ログをリストアして誤ったSQLステートメントの位置を特定する
この手順では、水曜日の夜の差分バックアップに記録されたバイナリ・ログについてテンポラリ・ロケーションへのリストアのみを実行します。これにより、データベース管理者はログで、Ordersテーブルが削除された時のマークが付けられた位置を見つけることができます。
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する］ － 水曜日の夜の差分バックアップに含まれるバイナリ・ログ・ファイルについてリストアのみを実行するために、このオプションを選択しました。
•
［時間に基づくPIT］ － データベース管理者は、［Point In Time（特定時点）タイプ］としてこのオプションが選択されていることを確認しましたが、［時間に基づくPITの詳細］セクションに表示されるその他すべてのオプションは選択解除したままにしました。
3
ジョブを開始して完了するまで待つ
手順3：リストアされたバイナリ・ログでdropped tableコマンドの位置を特定する
リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者は、drop tableステートメントが、MySQLサーバのテンポラリ・ロケーションにリストアされたMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました（また、これらの両方の値をメモしました）。
手順4：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された差分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された差分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリからのバイナリ・ログを適用する］ － 一連の操作の最後の手順で、テンポラリ・ロケーションにリストアしたバイナリ・ログをターゲットにするために、このオプションを選択しました。リストアしたバイナリ・ログ・ファイルでdropped tableコマンドが記録されている位置を特定したため、これと同じバイナリ・ログ・ファイルがプラグインで使用されるようにこのオプションを選択します。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル（MYSQLSVR-bin.000009）を選択しました。
3
ジョブを開始します。
方法2：リストアされたバイナリ・ログのみを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、水曜日の夜8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：バックアップされたバイナリ・ログをリストアして誤ったSQLステートメントの位置を特定する
この手順では、水曜日の夜の差分バックアップに記録されたバイナリ・ログについてテンポラリ・ロケーションへのリストアのみを実行します。これにより、データベース管理者はログで、Ordersテーブルが削除された時のマークが付けられた位置を見つけることができます。
1
［水曜日の夜からの差分バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する］ － 水曜日の夜の差分バックアップに含まれるバイナリ・ログ・ファイルについてリストアのみを実行するために、このオプションを選択しました。
•
［時間に基づくPIT］ － データベース管理者は、［Point In Time（特定時点）タイプ］としてこのオプションが選択されていることを確認しましたが、［時間に基づくPITの詳細］セクションに表示されるその他すべてのオプションは選択解除したままにしました。
3
ジョブを開始して完了するまで待つ
手順3：リストアされたバイナリ・ログでdropped tableコマンドの位置を特定する
リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者は、drop tableステートメントが、MySQLサーバのテンポラリ・ロケーションにリストアされたMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました（また、これらの両方の値をメモしました）。
手順4：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された差分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［テンポラリ・ディレクトリからのバイナリ・ログを適用する］ － 一連の操作の最後の手順で、テンポラリ・ロケーションにリストアしたバイナリ・ログをターゲットにするために、このオプションを選択しました。リストアしたバイナリ・ログ・ファイルでdropped tableコマンドが記録されている位置を特定したため、これと同じバイナリ・ログ・ファイルがプラグインで使用されるようにこのオプションを選択します。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル（MYSQLSVR-bin.000009）を選択しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － データベース管理者はこのオプションを選択し、［開始位置］を806（現在のバイナリ・ログ・ファイルの、mysqlbinlogで特定したdropped tableコマンドの位置の後にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル（MYSQLSVR-bin.000009）を選択しました。最後に、指定したバイナリ・ログ・ファイルを最後までリカバリするために、［停止位置］オプションで［なし］ラジオ・ボタンを選択しました。
 
* 
IMPORTANT: 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。
3
ジョブを開始します。
方法3：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が木曜日の午前06:00:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：現在のバイナリ・ログでdropped tableコマンドの位置を特定する
現在のバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者はdrop tableステートメントがMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました。
手順3：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された差分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された差分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － バックアップに含まれているバイナリ・ログ・ファイルをプラグインで使用するよう指定するために、このオプションを選択します。
•
［現在のバイナリ・ログを含む］ － データベース管理者はこのオプションを選択し、NetVault Backupで現在のバイナリ・ログも使用して、水曜日の夜の差分バックアップの後に実行されたすべてのデータベース・トランザクションを適用するよう指定しました。これにより、水曜日の夜に差分バックアップが完了してからdrop tableコマンドが発行されるまでの間に実行されたすべてのトランザクションがリカバリされます。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを［OTHER FILE］に設定し、現在のバイナリ・ファイルの名前（MYSQLSVR-bin.000009など）をテキスト・ボックスに入力しました。
方法4：リストアされたバイナリ・ログと現在のバイナリ・ログを使用して誤った/不良のSQLステートメントの前および後をリカバリする
データベース管理者は木曜日の午前9：00に、ユーザがOrdersテーブルでtable not found（テーブルが見つかりません）エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前06:00:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。以下に手順を示します。
手順1：日曜日からのフル・リストア
1
［日曜日の夜からのフル・バックアップを選択する］ － まず、データベース管理者は［リストア・ジョブ作成 － セーブセットの選択］ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする － どのオプションも使用しません。
3
ジョブを開始して完了するまで待つ。
手順2：現在のバイナリ・ログでdropped tableコマンドの位置を特定する
現在のバイナリ・ログに対してmysqlbinlogユーティリティを使用する － リストアしないdrop table SQLステートメントの位置を特定するために、この作業をNetVault Backupの外で実行します。この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください。この処理で、データベース管理者はdrop tableステートメントがMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました。
手順3：位置に基づくPITリストアを実行する
リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された差分バックアップを使用してPITリストアを実行します。
1
水曜日の夜に実行された差分バックアップを選択する － データベース管理者は再度［リストア・ジョブ作成 － セーブセットの選択］タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
 
* 
IMPORTANT: 差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されるため、データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません（水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます）。
2
リストア関連の［オプション］タブのオプション設定 － データベース管理者は以下のオプションを選択します。
•
［PITリカバリを実行する］ － このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にしました。
•
［バイナリ・ログをリストアし適用する（時間あるいは位置が、既に判明している場合、使用される）］ － バックアップに含まれているバイナリ・ログ・ファイルをプラグインで使用するよう指定するために、このオプションを選択します。
•
［現在のバイナリ・ログを含む］ － データベース管理者はこのオプションを選択し、NetVault Backupで現在のバイナリ・ログも使用して、水曜日の夜の差分バックアップの後に実行されたすべてのデータベース・トランザクションを適用するよう指定しました。これにより、水曜日の夜に差分バックアップが完了してからdrop tableコマンドが発行されるまでの間に実行されたすべてのトランザクションがリカバリされます。
•
［誤った／不良のSQLステートメントの前に、リカバリを可能にする］ － このオプションを選択し、［停止位置］を804（バイナリ・ログの、mysqlbinlogで特定したdropped tableコマンドの位置の前にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを［OTHER FILE］に設定し、現在のバイナリ・ファイルの名前（MYSQLSVR-bin.000009など）をテキスト・ボックスに入力しました。
•
［誤った／不良のSQLステートメントの後に、リカバリを可能にする］ － データベース管理者はこのオプションを選択し、［開始位置］を806（現在のバイナリ・ログ・ファイルの、mysqlbinlogで特定したdropped tableコマンドの位置の後にある位置）に設定しました。［終了位置を含むバイナリ・ログ］ドロップダウンを［OTHER FILE］に設定し、現在のバイナリ・ファイルの名前（MYSQLSVR-bin.000009など）をテキスト・ボックスに入力しました。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、［停止位置］オプションで［なし］ラジオ・ボタンを選択しました。
 
* 
IMPORTANT: 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。

MySQL Enterpriseバックアップ用リストア・シナリオ例

障害またはデータ損傷から正しくリカバリするには、ジョブの設定時に、リストア対象として選択するデータおよび［オプション］タブのオプションに関してさまざまな設定を行う必要があります。
•
フル・バックアップのみによるリストア・シナリオ
•
フルおよび増分バックアップによるリストア・シナリオ
フル・バックアップのみによるリストア・シナリオ
1
リストアする準備済みフル・バックアップを生成するには、［オプション］タブで選択した［Rawフル・バックアップをリストア、抽出し、ログを適用してTempディレクトリ内に準備済みフル・バックアップを生成］オプションを選択したジョブを実行します。
2
MySQLをシャットダウンし、MySQLサーバ・リポジトリに準備済みバックアップをコピーするには、［オプション］タブで選択した［MySQLサーバをシャットダウンし、準備済みフル・バックアップをMySQLサーバ・リポジトリへコピー・バック］オプションを選択したジョブを実行します。
3
コマンド・プロンプトで利用可能なコマンドを入力してMySQLを再起動します。
フルおよび増分バックアップによるリストア・シナリオ
1
リストアする準備済みフル・バックアップを生成するには、［オプション］タブで選択した［Rawフル・バックアップをリストア、抽出し、ログを適用してTempディレクトリ内に準備済みフル・バックアップを生成］オプションを選択したジョブを実行します。
2
必要な増分バックアップを準備済みフル・バックアップへ、それらがバックアップされた順に適用するには、［オプション］タブで選択した［増分バックアップをリストア、抽出し、Tempディレクトリ内の準備済みフル・バックアップに適用］オプションを選択したジョブを実行します。
3
MySQLをシャットダウンし、MySQLサーバ・リポジトリに準備済みバックアップをコピーするには、［オプション］タブで選択した［MySQLサーバをシャットダウンし、準備済みフル・バックアップをMySQLサーバ・リポジトリへコピー・バック］オプションを選択したジョブを実行します。
4
コマンド・プロンプトで利用可能なコマンドを入力してMySQLを再起動します。

高度なMySQL Standard/Community用リストア手順

このセクションでは、［MySQL Standard/Community］オプション用プラグインを使用して実行することができるその他のリストア操作について説明します。
•
リストア中にデータベース名を変更する
•
同じサーバ上の別のMySQLインスタンスへリストアする
•
異なるMySQLサーバへのリストア
リストア中にデータベース名を変更する
NetVault Backupでは、バックアップしたMySQLデータベースを選択し、リストア時に名前を変更して、既存のデータベースが上書きされないよう設定することができます。これは、既存のデータベースのコピーを作成する場合に便利です。これを実行するには、以下のセクションで説明する手順に従います。
 
* 
IMPORTANT: リストアではデータベース全体の名称変更のみを行います。個別のテーブルの名称を変更しようとするとエラー・メッセージが表示されます。
リストア時の名前変更を実行する前に、この操作に関する以下の既知の制限事項と想定される用途のリストを確認する必要があります。
•
有効なリストア・シーケンスは、フル・バックアップまたは個々のデータベース/テーブル・コピーのみのバックアップに制限されます。
•
増分および差分リストアの実行中に行うことはできません。
•
別のMySQLインスタンスまたはMySQLサーバへのリストアと組み合わせて使用できます。
リストア時にデータベース名を変更するには
1
［ナビゲーション］パネルで［リストア・ジョブ作成］をクリックして、［プラグイン・タイプ］リストから［Plug‑in for MySQL］を選択し、適切なセーブセットを選択して［次へ］をクリックします。
詳しくは、リストアするデータの選択を参照してください。
2
［セレクション セット作成］ページで、名前を変更するデータベースを選択します。
3
［アクション］リストから、［名前変更］を選択します。
4
［名前変更/移動］ダイアログの［名前変更］ボックスに新しい名前を入力して、［OK］をクリックします。
データベース・アイテムでは、追加情報が括弧内に表示されています。
5
「MySQLにおけるデータのリストア」の説明に従い、リストアを続行します。
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation