BACKUP (Transact-SQL)

バックアップ操作で使用するオプションを指定します。

• DIFFERENTIAL
  BACKUP DATABASE でのみ使用できます。前回の完全バックアップ以降に変更が加えられたデータベースやファイルだけをバックアップすることを指定します。完全バックアップに比べ、差分バックアップの方が使用領域が少なくてすみます。前回の完全バックアップ以降に実行された各ログ バックアップをすべて適用する必要がない場合に、このオプションを使用します。

  注意
  BACKUP DATABASE では、既定で完全バックアップが作成されます。

  詳細については、「差分バックアップの使用」を参照してください。

バックアップ セット オプション

以下のオプションは、このバックアップ操作で作成されるバックアップ セットに対して有効なオプションです。

注意
復元操作用のバックアップ セットを指定するには、FILE =<backup_set_file_number> オプションを使用します。バックアップ セットの指定方法の詳細については、「RESTORE の引数 (Transact-SQL)」の「バックアップ セットの指定」を参照してください。

• COPY_ONLY
  通常のバックアップの順序には影響しない、コピーのみのバックアップであることを指定します。コピーのみのバックアップは定期的に行われる従来のバックアップとは別に作成するもので、コピーのみのバックアップを行っても、データベースの全体的なバックアップと復元の手順に影響はありません。

  コピーのみのバックアップは、オンラインでファイルを復元する前にログをバックアップするなど、特殊な目的でバックアップを作成する場合を想定して SQL Server 2005 に導入されたオプションです。通常、コピーのみのログ バックアップは 1 回だけ使用して、その後削除します。

  • BACKUP DATABASE で COPY_ONLY オプションを使用した場合、作成される完全バックアップは差分ベースとして使用できません。差分ビットマップは更新されず、後に実行する差分バックアップではコピーのみのバックアップは無視され、従来のバックアップで作成された最新の完全バックアップがベースとして使用されます。

    重要
    COPY_ONLY を DIFFERENTIAL と共に使用した場合、COPY_ONLY は無視され、差分バックアップが作成されます。

  • BACKUP LOG と共に使用した場合、COPY_ONLY オプションによってコピーのみのログ バックアップが作成されます。トランザクション ログは切り捨てられません。コピーのみのログ バックアップはログ チェーンに影響せず、他のログ バックアップはコピーのみのバックアップが存在しない場合と同様に動作します。

  詳細については、「コピーのみのバックアップ」を参照してください。

• { COMPRESSION | NO_COMPRESSION }
  SQL Server 2008 Enterprise 以降のバージョンでのみ、バックアップでバックアップの圧縮を実行するかどうかを指定し、サーバー レベルの既定値を上書きできます。

  インストール時の既定の動作では、バックアップの圧縮は行われません。ただし、この既定の動作は、backup compression default サーバー構成オプションを設定することで変更できます。このオプションの現在の値を表示する方法については、「サーバーのプロパティを表示する方法 (SQL Server Management Studio)」を参照してください。

  • COMPRESSION
    バックアップの圧縮を明示的に有効にします。

    注意
    既定では、バックアップが圧縮されるとき、チェックサムが実行されてメディアの破損が検出されます。

  • NO_COMPRESSION
    バックアップの圧縮を明示的に無効にします。

• DESCRIPTION = { 'text' | **@**text_variable }
  バックアップ セットを記述したテキストを自由な形式で指定します。文字列の長さは最大 255 文字です。

• NAME = { backup_set_name| **@**backup_set_var }
  バックアップ セットの名前を指定します。名前の長さは最大 128 バイトです。NAME を指定しないと、名前は空白になります。

• PASSWORD = { password | **@**password_variable }
  バックアップ セットのパスワードを設定します。PASSWORD は文字列です。

  重要
  この機能は、Microsoft SQL Server の次のバージョンで削除されます。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

  バックアップ セットのパスワードが定義されている場合は、パスワードを指定して、バックアップ セットから SQL Server 復元操作を実行する必要があります。ただし、バックアップ セットのパスワードを指定しても、バックアップ ファイルの上書きを防止することはできません。バックアップ ファイルが上書きされないようにするには、代わりにメディア セットのパスワードを使用します (後の MEDIAPASSWORD オプションの説明を参照)。パスワードの使用の詳細については、後の「権限」を参照してください。

  セキュリティに関する注意
  パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。バックアップ保護に最適な方法は、バックアップ テープを安全な場所に保管するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。

• { EXPIREDATE = 'date'| RETAINDAYS = days }
  このバックアップのバックアップ セットがいつ上書きできるようになるかを指定します。オプションを両方とも使用した場合は、RETAINDAYS が EXPIREDATE よりも優先されます。

  どちらのオプションも指定しない場合、失効日は mediaretention (メディア保持期間) の設定によって決まります。詳細については、「サーバー構成オプションの設定」を参照してください。

  重要
  これらのオプションは、SQL Server でのファイルの上書きを防ぐことのみを目的としています。テープは別の方法で消去することができ、ディスク ファイルはオペレーティング システムで削除できます。有効期限の確認の詳細については、このトピックの「SKIP」および「FORMAT」を参照してください。

  • EXPIREDATE = { 'date'| **@**date_var }
    バックアップ セットが失効して上書きできるようになる日を指定します。この日付を変数 (@date_var) として指定する場合、構成されたシステムの datetime 形式に従い、次のいずれかを使用して指定する必要があります。

    • 文字定数 (@date_var = date)

    • 文字列型 (ntext データ型または text データ型を除く) の変数

    • smalldatetime 変数

    • datetime 変数

    次に例を示します。

    • 'Dec 31, 2020 11:59 PM'

    • '1/1/2021'

    datetime 値の指定方法の詳細については、「日時データの使用」を参照してください。

    注意
    失効日を無視するには、SKIP オプションを使用します。

  • RETAINDAYS = { days| **@days_var }
    このバックアップ メディア セットに上書きできるようになるまでの経過日数を指定します。この日数を変数 (@**days_var) として指定する場合は、整数で指定する必要があります。

メディア セットのオプション

以下のオプションはメディア セット全般に適用されます。

• { NOINIT | INIT }
  バックアップ操作で、バックアップ メディア上の既存のバックアップ セットに追加するか、上書きするかを制御します。既定では、メディア上の最新のバックアップ セットに追加します (NOINIT)。

  注意
  { NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。

  • NOINIT
    バックアップ セットを指定のメディア セットに追加します。この場合、既存のバックアップ セットは維持されます。メディア セットのメディア パスワードが定義されている場合は、パスワードを指定する必要があります。既定値は NOINIT です。

    詳細については、「既存のバックアップ セットへの追加」を参照してください。

  • INIT
    すべてのバックアップ セットを上書きします。ただし、メディア ヘッダーは維持されます。INIT を指定した場合は、条件が満たされる限り、そのデバイス上にある既存のすべてのバックアップ セットが上書きされます。既定では、BACKUP によって次の状況が確認され、いずれかの状況に該当する場合はバックアップ メディアは上書きされません。

    • バックアップ セットがまだ期限切れではない。詳細については、EXPIREDATE オプションおよび RETAINDAYS オプションの説明を参照してください。

    • BACKUP ステートメントにバックアップ セットの名前が指定されていて、その名前がバックアップ メディア上の名前と一致していない。詳細については、前の「NAME」オプションを参照してください。

    これらのチェックを無効にするには、SKIP オプションを使用します。

    注意
    バックアップ メディアがパスワードで保護されている場合、メディア パスワードを指定しない限り、SQL Server がメディアに書き込みを行うことはありません。このチェックは、SKIP オプションでも無効になりません。パスワードで保護されているメディアを上書きするには、メディアを再フォーマットするのが唯一の方法です。再フォーマットすると、メディア上のバックアップ データは削除されます。メディア パスワードの詳細については、前の「MEDIAPASSWORD」を参照してください。メディアの再フォーマットについては、前の「FORMAT」を参照してください。

    詳細については、「バックアップ セットの上書き」を参照してください。

• { NOSKIP | SKIP }
  バックアップ操作で、上書き前にメディア上のバックアップ セットの失効日と失効時刻を確認するかどうかを制御します。

  注意
  { NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。

  • NOSKIP
    上書きを許可する前に、メディア上のすべてのバックアップ セットの有効期限を確認することを BACKUP ステートメントに指示します。これは既定の動作です。

  • SKIP
    バックアップ セットの有効期限と名前の確認を無効にします。この確認は、通常、バックアップ セットの上書きを防止するために BACKUP ステートメントによって実行されます。{ INIT | NOINIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。

    バックアップ セットの失効日を確認するには、backupset 履歴テーブルの expiration_date 列をクエリします。

• { NOFORMAT | FORMAT }
  このバックアップ操作で使用するボリュームに新しいメディア ヘッダーを書き込み、既存のメディア ヘッダーとバックアップ セットを上書きするかどうかを指定します。

  • NOFORMAT
    このバックアップ操作に使用するメディア ボリューム上の、既存のメディア ヘッダーとバックアップ セットを保持するよう指定します。これは既定の動作です。

  • FORMAT
    新しいメディア セットを作成します。FORMAT を指定した場合、バックアップ操作に使用するすべてのメディア ボリュームに、新しいメディア ヘッダーを書き込みます。この場合、ボリューム上の既存のメディア ヘッダーとバックアップ セットは上書きされるので、それまであった内容は無効になります。

    重要
    FORMAT の使用には注意が必要です。メディア セットに属するボリュームを 1 つでも初期化すると、メディア セット全体が使用できなくなります。たとえば、既存のストライプ メディア セットに属するテープを 1 つ初期化すると、このメディア セット全体が使用できなくなります。

    FORMAT を指定することは SKIP を実行することを意味します。SKIP を明示的に指定する必要はありません。

• MEDIADESCRIPTION = { text | **@**text_variable }
  メディア セットを記述した自由形式のテキストを最大 255 文字で指定します。

• MEDIANAME = { media_name | **@**media_name_variable}
  バックアップ メディア セット全体に対するメディア名を指定します。メディア名は最長 128 文字まで入力できます。MEDIANAME を指定する場合、バックアップ ボリュームに既に存在する、前回指定したメディア名と一致する必要があります。MEDIANAME を指定しない場合、または SKIP オプションを指定した場合、メディア名の照合チェックは行われません。

• MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
  メディア セットのパスワードを設定します。MEDIAPASSWORD は文字列です。

  重要
  この機能は、Microsoft SQL Server の次のバージョンで削除されます。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

  メディア セットのパスワードが定義されている場合は、そのメディア セットにバックアップ セットを作成する前にパスワードを指定する必要があります。また、そのメディア セットから復元操作を実行する際にも、そのメディア パスワードを指定する必要があります。パスワードで保護されているメディアを上書きするには、再フォーマットするしかありません。詳細については、FORMAT オプションの説明を参照してください。パスワードの使用の詳細については、後の「権限」を参照してください。

  セキュリティに関する注意
  パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。バックアップ保護に最適な方法は、バックアップ テープを安全な場所に保管するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。

• BLOCKSIZE = { blocksize | **@**blocksize_variable }
  物理ブロック サイズをバイト単位で指定します。サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。通常は、BACKUP でデバイスに適するブロック サイズが自動的に選択されるので、このオプションは不要です。ブロック サイズは、自動的に選択された値よりも明示的に指定された値が優先されます。

  バックアップを作成して CD-ROM に格納したり、CD-ROM からバックアップを復元する場合は、BLOCKSIZE=2048 と指定します。

  注意
  このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。

データ転送オプション

• BUFFERCOUNT = { buffercount | **@**buffercount_variable }
  バックアップ操作に使用される I/O バッファの総数を指定します。任意の正の整数を指定できますが、バッファ数が多いと Sqlservr.exe プロセスで仮想アドレス空間が不足し、"メモリ不足" エラーの原因となる場合があります。

  バッファで使用される仮想アドレス空間の合計は、buffercount*****maxtransfersize の計算によって算出されます。

• MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
  SQL Server とバックアップ メディア間で使用される最大転送単位をバイト単位で指定します。有効値は 65536 バイト (64 KB) の倍数で、最大有効値は 4194304 バイト (4 MB) です。

エラー管理オプション

以下のオプションは、バックアップ操作に際してバックアップのチェックサムを有効にするかどうかと、エラー発生時に操作を停止するかどうかを指定するオプションです。

• { NO_CHECKSUM | CHECKSUM }
  バックアップのチェックサムを有効にするかどうかを制御します。

  • NO_CHECKSUM
    バックアップ チェックサムの生成 (およびページ チェックサムの検証) を明示的に無効にします。これは圧縮されたバックアップ以外の既定の動作です。

  • CHECKSUM
    バックアップのチェックサムを有効にします。この場合 BACKUP で次の処理を行えるようになります。

    1. バックアップ メディアにページを書き込む前に、BACKUP によってページ (ページ チェックサムまたは破損したページ) を確認し、この情報がページ上に存在するかどうかを検証します。

    2. ページ チェックサムが存在するかどうかに関係なく、BACKUP によってバックアップ ストリームに個別のバックアップ チェックサムが生成されます。復元操作でバックアップ チェックサムを使用し、バックアップが破損していないかどうかを検証することもできます。バックアップ チェックサムは、データベース ページにではなくバックアップ メディアに格納されます。バックアップ チェックサムは、復元時に使用することもできます。

    バックアップ チェックサムを使用すると、ワークロードとバックアップのスループットに影響する場合があります。

    これは圧縮されたバックアップの既定の動作です。

• { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
  ページ チェックサム エラーの発生時、バックアップ操作を停止するか続行するかを制御します。

  • STOP_ON_ERROR
    ページ チェックサムが正しくない場合、BACKUP を失敗させます。これは既定の動作です。

  • CONTINUE_AFTER_ERROR
    無効なチェックサム、ページの破損などのエラーが検出されても、BACKUP を継続します。

    データベースが破損したとき、NO_TRUNCATE オプションを使用してもログの末尾をバックアップできない場合は、NO_TRUNCATE の代わりに CONTINUE_AFTER_ERROR を指定してログ末尾のバックアップを試してください。

互換性オプション

• RESTART
  機能しません。このオプションが利用できるのは、以前のバージョンの SQL Server と互換性を維持するためです。

監視オプション

• STATS [ **=**percentage ]
  指定した percentage の完了ごとにメッセージを表示します。進行状況を判断する場合に使用できます。percentage を省略した場合、SQL Server では 10% 完了するごとにメッセージが表示されます。

  STATS オプションでは、次のパーセンテージをレポートするためのしきい値に達した時点で、完了したパーセンテージがレポートされます。このしきい値は、指定したパーセンテージを正確に反映するものではありません。たとえば STATS=10 の場合、40% が完了しても、43% の時点でメッセージが表示されることがあります。大きいバックアップ セットの場合、これは重要な問題にはなりません。これは、完了した I/O 呼び出し間で、完了パーセンテージの変化が非常に遅くなるためです。

テープ オプション

このオプションはテープ デバイスにのみ適用されます。テープ以外のデバイスが使用される場合、このオプションは無視されます。

• { REWIND | NOREWIND }

  • REWIND
    SQL Server でテープを解放して巻き戻します。既定値は REWIND です。

  • NOREWIND
    SQL Server でバックアップ操作の後テープを開いたままにしておくことを指定します。このオプションを使用すると、1 つのテープに複数のバックアップ操作を実行する場合のパフォーマンスを向上できます。

    NOREWIND は暗黙的に NOUNLOAD も意味しています。この 2 つのオプションを同一 BACKUP ステートメント内で同時に使用することはできません。

    注意
    NOREWIND を使用する場合、テープ ドライブの所有権は SQL Server インスタンスによって保持されます。同じプロセス内で実行される BACKUP ステートメントや RESTORE ステートメントで REWIND オプションまたは UNLOAD オプションが使用されるか、サーバー インスタンスがシャットダウンすると、所有権は解放されます。テープを開いたままにすると、他のプロセスはそのテープにアクセスできません。開いているテープの一覧を表示する方法、および開いているテープを閉じる方法については、「バックアップ デバイス」を参照してください。

• { UNLOAD | NOUNLOAD }

  注意
  UNLOAD または NOUNLOAD はセッションの設定であり、セッションが終了するまで、または代わりとなるオプションの指定によりリセットされるまで有効です。

  • UNLOAD
    バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行います。UNLOAD はセッション開始時の既定の設定です。

  • NOUNLOAD
    BACKUP 操作の後、テープ ドライブにテープを読み込んだままにすることを指定します。

注意
テープ バックアップ デバイスへのバックアップの場合、BLOCKSIZE オプションはバックアップ操作のパフォーマンスに影響します。このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。

ログ関係のオプション

以下のオプションは、BACKUP LOG でのみ使用するオプションです。

注意
ログ バックアップを作成しない場合は、単純復旧モデルを使用します。詳細については、「単純復旧モデルでのバックアップ」を参照してください。

• { NORECOVERY | STANDBY **=**undo_file_name }

  • NORECOVERY
    ログの末尾をバックアップし、データベースを RESTORING の状態のままにします。NORECOVERY は、セカンダリ データベースにフェールオーバーする場合、または RESTORE 操作の前にログの末尾を保存する場合に便利です。

    ログの切り捨てをスキップするベストエフォートのログ バックアップを実行して、データベースを自動的に RESTORING 状態にするには、NO_TRUNCATE および NORECOVERY オプションを同時に使用します。

  • STANDBY **=**standby_file_name
    ログの末尾をバックアップし、データベースを読み取り専用および STANDBY 状態のままにします。STANDBY 句では、スタンバイ データが書き込まれます。ロールバックが実行されますが、追加の復元を行うこともできます。STANDBY オプションの使用は、BACKUP LOG WITH NORECOVERY の後に RESTORE WITH STANDBY を使用する場合と同じ効果があります。

    スタンバイ モードの使用にはスタンバイ ファイルが必要で、これは standby_file_name で指定します。その位置はデータベースのログに格納されます。指定したファイルが既に存在する場合、データベース エンジンによってファイルが上書きされます。ファイルが存在しない場合、データベース エンジンによってファイルが作成されます。スタンバイ ファイルはデータベースの一部となります。

    このファイルには、ロールバックされた変更内容が含まれています。RESTORE LOG 操作を後で適用する場合、これらの変更内容の順序を逆にする必要があります。スタンバイ ファイルでは、ファイル サイズが増加するので、ディスクに十分な空き容量が必要です。これは、コミットされていないトランザクションのロールバックによって変更が加えられた、データベース内にあるすべてのページを保存できるようにするためです。

• NO_TRUNCATE
  ログが切り捨てられないように指定し、データベースの状態に関係なく、データベース エンジンによってバックアップが行われるようにします。その結果、NO_TRUNCATE で実行されるバックアップに不完全なメタデータが含まれる場合があります。このオプションを使用すると、データベースが破損している場合でもログをバックアップできます。

  BACKUP LOG の NO_TRUNCATE オプションを指定すると、COPY_ONLY と CONTINUE_AFTER_ERROR の両方を指定する場合と同じ結果が得られます。

  NO_TRUNCATE オプションを使用しない場合は、データベースが ONLINE 状態である必要があります。データベースが SUSPENDED 状態の場合は、NO_TRUNCATE を指定することによってバックアップを作成できる可能性がありますが、データベースが OFFLINE または EMERGENCY 状態の場合、NO_TRUNCATE を使用しても BACKUP を実行できません。データベースの状態については、「データベースの状態」を参照してください。

データベースのトランザクション ログがいっぱいにならないように、トランザクション ログを定期的にバックアップする必要があります。ログの切り捨ては、単純復旧モデルではデータベースのバックアップ後に、完全復旧モデルではトランザクション ログのバックアップ後に自動的に行われます。ただし、切り捨ての処理が遅れる場合もあります。この遅延の要因の特定および対処の方法については、「ログの切り捨てが遅れる原因となる要因」を参照してください。

注意
BACKUP LOG WITH NO_LOG オプションと WITH TRUNCATE_ONLY オプションは廃止されました。完全復旧モデルまたは一括ログ復旧モデルの復旧を使用している場合に、ログ バックアップ チェーンをデータベースから削除するには、単純復旧モデルに切り替える必要があります。詳細については、「完全復旧モデルまたは一括ログ復旧モデルからの切り替え」を参照してください。

ログの切り捨て全般の詳細については、「トランザクション ログの切り捨て」を参照してください。

SQL Server では、オンライン バックアップを使って、使用中のデータベースをバックアップできます。バックアップ中はほとんどの操作が可能です。たとえば、INSERT、UPDATE、または DELETE ステートメントはバックアップ操作中でも使用できます。

データベース バックアップやトランザクション ログ バックアップ中に実行できない操作には次のものがあります。

• ADD FILE または REMOVE FILE のいずれかのオプションが指定された ALTER DATABASE ステートメントなどのファイル管理操作。

• データベースまたはファイルの圧縮操作。これには自動圧縮操作も含まれます。

バックアップ操作がファイル管理または圧縮操作と重複すると、競合が発生します。どの競合操作が最初に始まったかに関係なく、最初の操作によって設定されたロックがタイムアウトになるまで、2 番目の操作は待機します (タイムアウト時間はセッション タイムアウト設定で制御されます)。ロックがタイムアウト期間内に解放されると、2 番目の操作が開始されます。ロックがタイムアウトになると、2 番目の操作は実行されません。

次の条件のいずれか 1 つでも該当する場合は、BACKUP ステートメントでバックアップ メディアがフォーマットされます。

• FORMAT オプションが指定されている。

• メディアが空である。

• 連続するテープに書き込んでいる。

詳細については、「新しいメディア セットの作成」を参照してください。

実行できるバックアップの種類は、次のようにデータベースの復旧モデルに依存します。

• データの完全バックアップと差分バックアップはすべての復旧モデルで実行できます。

  バックアップの範囲	バックアップの種類
  データベース全体	データベース バックアップでは、データベース全体が対象となります。
  データベースの部分バックアップ	部分バックアップでは、読み取り/書き込みファイル グループと、必要に応じて 1 つ以上の読み取り専用ファイルまたはファイル グループが対象となります。
  ファイルまたはファイル グループ	ファイル バックアップでは、1 つ以上のファイルまたはファイル グループが対象となります。複数のファイル グループを含むデータベースにのみ関連します。単純復旧モデルでは、ファイル バックアップは原則として読み取り専用セカンダリ ファイル グループに限定されます。

• 完全復旧モデルまたは一括ログ復旧モデルでは、従来のバックアップの必須作業として、シーケンシャル トランザクション ログ バックアップ (またはログ バックアップ) も含まれます。各ログ バックアップでは、トランザクション ログのうち、バックアップが作成された時点でアクティブだった部分と、前回のログ バックアップでバックアップされなかったすべてのログ レコードが対象となります。

  作業損失の可能性を最小に抑えるには、管理のオーバーヘッドが発生するという犠牲を払っても、ログ バックアップを頻繁に行うようスケジュールする必要があります。完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。

  ログ バックアップは、データベースのバックアップとは別のボリュームに配置することをお勧めします。

  注意
  最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。

  詳細については、「トランザクション ログのバックアップ」を参照してください。

• コピーのみのバックアップは、従来のバックアップで行われる一連の作業とは別に、特別な目的で行われる完全バックアップまたはログ バックアップです。コピーのみのバックアップを作成するには、BACKUP ステートメントで COPY_ONLY オプションを指定します。詳細については、「コピーのみのバックアップ」を参照してください。

次の表に、{ NOINIT | INIT } と { NOSKIP | SKIP } オプションの相関関係を示します。

注意
テープ メディアが空の場合、またはディスクのバックアップ ファイルが存在しない場合は、これらすべての相関関係に基づいて、メディア ヘッダーが記述され、操作が継続します。ただしメディアが空でなく、有効なメディア ヘッダーが含まれない場合、これらの操作では有効な MTF メディアでないことが返され、バックアップ操作は中断されます。

1 妥当性チェックには、MTF のバージョン番号およびその他のヘッダー情報が含まれます。指定されたバージョンがサポートされていないか、予期しない値の場合、エラーが発生します。

2 ユーザーがバックアップ操作を実行するためには、適切な固定データベース ロールまたはサーバー ロールに属し、正しいメディア パスワードを指定する必要があります。

SQL Server には次のようなバックアップ履歴テーブルがあり、これによってバックアップ処理が追跡されます。

• backupfile (Transact-SQL)

• backupfilegroup (Transact-SQL)

• backupmediafamily (Transact-SQL)

• backupmediaset (Transact-SQL)

• backupset (Transact-SQL)

復元を実行する場合、バックアップ セットが msdb データベースにまだ記録されていないと、バックアップ履歴テーブルが変更される可能性があります。

注意
SQL Server によって作成されたバックアップは、それより前のバージョンの SQL Server では復元できません。

BACKUP には、以前のバージョンの SQL Server との互換性を維持するため、RESTART オプションが用意されています。ただし、RESTART は SQL Server 2005 以降のバージョンでは無効です。

ストライプ セットとは、データがブロックに分割され、一定の順序で分散される、一連のディスク ファイルです。ストライプ セットで使用されるバックアップ デバイスの数は、(FORMAT でメディアを再初期化する場合を除いて) 常に同じである必要があります。

次の例では、AdventureWorks データベースのバックアップを、3 つのディスク ファイルを使用する新しいストライプ メディア セットに書き込みます。

BACKUP DATABASE AdventureWorks
TO DISK='X:\SQLServerBackups\AdventureWorks1.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
   MEDIANAME = 'AdventureWorksStripedSet0',
   MEDIADESCRIPTION = 'Striped media set for AdventureWorks database;
GO

バックアップ デバイスをいったんストライプ セットの一部として定義すると、FORMAT を指定しない限り、ファイル単位のバックアップに使用することはできません。同様に、非ストライプ バックアップを含むバックアップ デバイスは、FORMAT を指定しない限り、ストライプ セットでは使用できません。ストライプ バックアップ セットを分割するには、FORMAT を使用します。

メディア ヘッダーを書き込むときに MEDIANAME と MEDIADESCRIPTION のいずれも指定しない場合、空白項目に該当するメディアのヘッダー フィールドは空になります。

通常、バックアップはミラー化せず、BACKUP ステートメントには TO 句のみを指定しますが、メディア セットあたり 4 つまでミラーを指定できます。ミラー化されたメディア セットの場合、バックアップ操作では、バックアップ デバイスの複数のグループに書き込みが行われます。このバックアップ デバイスの各グループが、ミラー化されたメディア セット内の 1 つのミラーとなります。それぞれのミラーでは同じ容量および種類の物理バックアップ デバイスを使用する必要があり、プロパティがすべて同じである必要があります。

ミラー化されたメディア セットにバックアップを作成するには、ミラーがすべて存在している必要があります。ミラー化されたメディア セットにバックアップするには、TO 句に 1 つ目のミラーを指定し、MIRROR TO 句にその他のミラーをそれぞれ指定します。

ミラー化されたメディア セットの場合、各 MIRROR TO 句では、TO 句と同じ数および種類のデバイスのリストを指定する必要があります。次の例では、ミラー化されたメディア セットに書き込みます。このメディア セットには 2 つのミラーが含まれ、それぞれで 3 つのデバイスが使用されています。

BACKUP DATABASE AdventureWorks
TO DISK='X:\SQLServerBackups\AdventureWorks1a.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2a.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2b.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks3b.bak';
GO

重要
この例は、ローカル システム上でテストできるように設計されています。実際には同じドライブ上にある複数のデバイスにバックアップすると、パフォーマンスが低下するおそれがあり、ミラー化されたメディア セットの設計目的でもある冗長性が損なわれる可能性があります。

ミラー化されたメディア セットのメディア ファミリ

次の例では、AdventureWorks データベースをディスク ファイルにバックアップします。

BACKUP DATABASE AdventureWorks 
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
   WITH FORMAT;
GO

次の例では、既定により単純復旧モデルを使用する AdventureWorks サンプル データベースをバックアップします。ここではまず、ログをバックアップするため、AdventureWorks データベースを修正して完全復旧モデルを使用するようにします。

次に sp_addumpdevice を使用して、データのバックアップ用に論理バックアップ デバイスAdvWorksData を作成し、ログのバックアップ用に別の論理バックアップ デバイス AdvWorksLog を作成します。

その後、AdvWorksData に完全データベース バックアップを作成し、更新操作の期間をおいた後、ログを AdvWorksLog にバックアップします。

-- To permit log backups, before the full database backup, modify the database 
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks
   SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices. 
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData', 
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog', 
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks database.
BACKUP DATABASE AdventureWorks TO AdvWorksData;
GO
-- Back up the AdventureWorks log.
BACKUP LOG AdventureWorks
   TO AdvWorksLog;
GO

注意
運用データベースでは、ログを定期的にバックアップしてください。ログのバックアップは、データ損失を防ぐため、頻繁に行ってください。

次の例では、両方のセカンダリ ファイル グループ内のすべてのファイルについて、完全ファイル バックアップを作成します。

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1',
   FILEGROUP = 'SalesGroup2'
   TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
GO

次の例では、両方のセカンダリ ファイル グループ内のすべてのファイルについて、差分ファイル バックアップを作成します。

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
   FILEGROUP = 'SalesGroup1',
   FILEGROUP = 'SalesGroup2'
   TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
   WITH 
      DIFFERENTIAL
GO

次の例では、単一メディア ファミリと 4 つのミラーを含むミラー化メディア セットを作成し、そこに AdventureWorks データベースのバックアップを作成します。

BACKUP DATABASE AdventureWorks
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
   FORMAT,
   MEDIANAME = 'AdventureWorksSet0'

次の例では、各ミラーが 2 つのメディア ファミリで構成されているミラー化メディア セットを作成します。ここでは、両方のミラーに AdventureWorks データベースのバックアップが作成されます。

BACKUP DATABASE AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
   FORMAT,
   MEDIANAME = 'AdventureWorksSet1'

次の例では、前の例で作成されたメディア セットにバックアップ セットを追加します。

BACKUP LOG AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorksSet1'

注意
NOINIT は既定値ですが、ここではわかりやすくするために記載しています。

[例の先頭に戻る]

次の例では、メディアをフォーマットして新しいメディア セットを作成し、AdventureWorks データベースの圧縮された完全バックアップを実行します。

BACKUP DATABASE AdventureWorks TO DISK='Z:\SQLServerBackups\AdvWorksData.bak' 
WITH 
   FORMAT, 
   COMPRESSION

[例の先頭に戻る]