次の方法で共有


BACKUP (Transact-SQL)

更新 : 2006 年 12 月 12 日

データベース全体、または、1 つ以上のファイルまたはファイル グループをバックアップします (BACKUP DATABASE)。完全復旧モデルまたは一括ログ復旧モデルの場合に、トランザクション ログをバックアップします (BACKUP LOG)。

トピック リンク アイコンTransact-SQL 構文表記規則

構文

 Backing Up a Whole Database  BACKUP DATABASE { database_name | @database_name_var }    TO <backup_device> [ ,...n ]    [ <MIRROR TO clause> ] [ next-mirror-to ]   [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ] [;]  Backing Up Specific Files or Filegroups BACKUP DATABASE { database_name | @database_name_var }   <file_or_filegroup> [ ,...n ]    TO <backup_device> [ ,...n ]    [ <MIRROR TO clause> ] [ next-mirror-to ]   [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ] [;]  Creating a Partial Backup BACKUP DATABASE { database_name | @database_name_var }   READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]   TO <backup_device> [ ,...n ]    [ <MIRROR TO clause> ] [ next-mirror-to ]   [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ] [;] 
 Backing Up the Transaction Log (full and bulk-logged recovery models) BACKUP LOG { database_name | @database_name_var }    TO <backup_device> [ ,...n ]    [ <MIRROR TO clause> ] [ next-mirror-to ]   [ WITH { <general_WITH_options> | <log-specific_optionspec> } [ ,...n ] ] [;]  Truncating the Transaction Log (breaks the log chain)  BACKUP LOG { database_name | @database_name_var }    WITH { NO_LOG | TRUNCATE_ONLY }  [;]  <backup_device>::=   {    { logical_device_name | @logical_device_name_var }   | { DISK | TAPE } =       { 'physical_device_name' | @physical_device_name_var }  }   <MIRROR TO clause>::=  MIRROR TO <backup_device> [ ,...n ]  <file_or_filegroup>::=  {    FILE = { logical_file_name | @logical_file_name_var }   | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }  }   <read_only_filegroup>::= FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }  <general_WITH_options> [ ,...n ]::=  --Backup Set Options       COPY_ONLY    | DESCRIPTION = { 'text' | @text_variable }   | NAME = { backup_set_name | @backup_set_name_var }   | PASSWORD = { password | @password_variable }   | [ EXPIREDATE = { date | @date_var }          | RETAINDAYS = { days | @days_var } ]   | NO_LOG   --Media Set Options    { NOINIT | INIT }   | { NOSKIP | SKIP }   | { NOFORMAT | FORMAT }   | MEDIADESCRIPTION = { 'text' | @text_variable }   | MEDIANAME = { media_name | @media_name_variable }   | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }   | BLOCKSIZE = { blocksize | @blocksize_variable }   --Data Transfer Options    BUFFERCOUNT = { buffercount | @buffercount_variable }   | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }  --Error Management Options    { NO_CHECKSUM | CHECKSUM }  | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }  --Compatibility Options    RESTART   --Monitoring Options    STATS [ = percentage ]   --Tape Options    { REWIND | NOREWIND }   | { UNLOAD | NOUNLOAD }   --Log-specific Options    { NORECOVERY | STANDBY = undo_file_name }  | NO_TRUNCATE 

引数

  • DATABASE
    データベース全体のバックアップを指定します。ファイルとファイル グループのリストを指定した場合、指定したファイルとファイル グループだけがバックアップされます。データベース全体のバックアップまたは差分バックアップ中、SQL Server では、バックアップが復元された場合に一貫性のあるデータベースを生成できるよう、必要十分なトランザクション ログをバックアップします。

    ms186865.note(ja-jp,SQL.90).gifメモ :
    master データベース上では、データベース全体のバックアップのみが可能です。
  • LOG
    トランザクション ログのみのバックアップを指定します。前回正しく実行されたログ バックアップの位置から、ログの現在の末尾まで、ログのバックアップが行われます。最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。

    ms186865.note(ja-jp,SQL.90).gifメモ :
    WITH NO_TRUNCATE または COPY_ONLY を指定する以外の標準的な方法でログ バックアップを行うと、一部のトランザクション ログ レコードはアクティブでなくなります。1 つ以上の仮想ログ ファイル内ですべてのレコードがアクティブでなくなった場合、ログは切り捨てられます。定期的なログ バックアップの後ログが切り捨てられない場合は、何らかの原因によりログの切り捨てが遅れている可能性があります。詳細については、「トランザクション ログの管理」を参照してください。
  • { database_name| @database_name_var }
    トランザクション ログ、データベースの一部、またはデータベース全体をバックアップする場合の、バックアップ元となるデータベースを指定します。この名前を変数 (@database_name_var) として指定する場合は、文字列定数 (@database_name_var
    =
    database name) として指定するか、ntext データ型と text データ型を除く文字列型の変数として指定できます。

    ms186865.note(ja-jp,SQL.90).gifメモ :
    データベース ミラーリング パートナーシップ内のミラー データベースは、バックアップできません。
  • <file_or_filegroup> [ ,...n ]
    BACKUP DATABASE でのみ使用できます。ファイル バックアップに含めるデータベース ファイルまたはファイル グループを指定するか、部分バックアップに含める読み取り専用ファイルまたはファイル グループを指定します。

    • FILE = { logical_file_name| **@**logical_file_name_var }
      バックアップに含めるファイルの論理名、またはこの論理名を値として保持する変数を指定します。
    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      バックアップに含めるファイル グループの論理名、またはこの論理名を値として保持する変数を指定します。単純復旧モデルでは、ファイル グループのバックアップは、読み取り専用のファイル グループに対してのみ使用できます。

      ms186865.note(ja-jp,SQL.90).gifメモ :
      データベースのサイズやパフォーマンス要件によりデータベース バックアップの実行が難しい場合は、ファイル単位のバックアップを検討してください。
    • n
      複数のファイルおよびファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダです。数値の制限はありません。

    詳細については、「ファイルの完全バックアップ」および「ファイルおよびファイル グループをバックアップする方法 (Transact-SQL)」を参照してください。

  • READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var } [ ,...n ] ]
    部分バックアップを指定します。部分バックアップには、データベース内のすべての読み取り/書き込みファイル (プライマリ ファイル グループ、存在する場合は読み取り/書き込みセカンダリ ファイル グループ、および指定の読み取り専用ファイルまたはファイル グループ) が含まれます。

    • READ_WRITE_FILEGROUPS
      部分バックアップで、すべての読み取り/書き込みファイル グループをバックアップすることを指定します。データベースが読み取り専用の場合、READ_WRITE_FILEGROUPS にはプライマリ ファイル グループのみが含まれます。

      ms186865.note(ja-jp,SQL.90).gif重要 :
      READ_WRITE_FILEGROUPS の代わりに FILEGROUP を使用して、読み取り/書き込みファイル グループのリストを明示的に指定すると、ファイル バックアップが作成されます。
    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      部分バックアップに含める読み取り専用ファイル グループの論理名、またはこの論理名を値として保持する変数を指定します。詳細については、前の「<file_or_filegroup>」を参照してください。
    • n
      複数の読み取り専用ファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダです。

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

  • TO <backup_device> [ ,...n]
    関連するバックアップ デバイスのセットが、ミラー化されてないメディア セット、またはミラー化されたメディア セット内にあるミラーの 1 つ目 (1 つ以上の MIRROR TO 句が宣言されている場合) であることを示します。

    • <backup_device>
      バックアップ操作に使用する論理または物理バックアップ デバイスを指定します。

      • { logical_device_name | @logical_device_name_var }
        データベースのバックアップが作成されるバックアップ デバイス (sp_addumpdevice によって作成) の論理名を指定します。論理名は、識別子のルールに従う必要があります。バックアップ デバイス名を変数 (@logical_device_name_var) として指定する場合は、文字定数 (@logical_device_name_var
        =
        logical backup device name) として指定するか、ntext データ型と text データ型を除く文字列型の変数として指定できます。
      • { DISK | TAPE } = { 'physical_device_name' | **@**physical_device_name_var }
        ディスク ファイルまたはテープ デバイスを指定します。指定するデバイスは、BACKUP ステートメントの実行前に存在しなくてもかまいません。物理デバイスが既に存在し、BACKUP ステートメントに INIT オプションが指定されていない場合、バックアップはデバイスに追加されます。

        詳細については、「バックアップ デバイス」を参照してください。

    • n
      最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダです。
  • MIRROR TO <backup_device> [ ,...n]
    TO 句で指定したバックアップ デバイスをミラー化する、1 つ以上のバックアップ デバイスのセットを指定します。MIRROR TO 句には、TO 句で指定した同じ種類と数のバックアップ デバイスを指定する必要があります。MIRROR TO 句の最大数は 3 です。

    このオプションは、SQL Server 2005 Enterprise Edition 以降のバージョンでのみ使用できます。

    ms186865.note(ja-jp,SQL.90).gifメモ :
    MIRROR TO = DISK の場合、BACKUP によって、ディスク デバイスに応じた適切なブロック サイズが自動的に決まります。ブロック サイズの詳細については、後の「BLOCKSIZE」の説明を参照してください。
    • <backup_device>
      詳細については、前の「<backup_device>」を参照してください。
    • n
      最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダです。各 MIRROR TO 句内のデバイス数は、TO 句内のデバイス数と同じである必要があります。
  • [ next-mirror-to ]
    単一の BACKUP ステートメントに、1 つの TO 句と 3 つまでの MIRROR TO 句を含めることができることを示すプレースホルダです。

WITH オプション

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

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

    ms186865.note(ja-jp,SQL.90).gifメモ :
    BACKUP DATABASE では、既定で完全バックアップが作成されます。

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

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

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

ms186865.note(ja-jp,SQL.90).gifメモ :
復元操作用のバックアップ セットを指定するには、FILE =<backup_set_file_number> オプションを使用します。バックアップ セットを指定する方法の詳細については、「RESTORE の引数 (Transact-SQL)」を参照してください。
  • COPY_ONLY
    通常のバックアップの順序には影響しない、コピーのみのバックアップであることを指定します。コピーのみのバックアップは定期的に行われる従来のバックアップとは別に作成するもので、コピーのみのバックアップを行っても、データベースの全体的なバックアップと復元の手順に影響はありません。

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

    • BACKUP DATABASE で COPY_ONLY オプションを使用した場合、作成される完全バックアップは差分ベースとして使用できません。差分ビットマップは更新されず、後に実行する差分バックアップではコピーのみのバックアップは無視され、従来のバックアップで作成された最新の完全バックアップがベースとして使用されます。
      ms186865.note(ja-jp,SQL.90).gif重要 :
      COPY_ONLY を DIFFERENTIAL と共に使用した場合、COPY_ONLY は無視され、差分バックアップが作成されます。
    • BACKUP LOG と共に使用した場合、COPY_ONLY オプションによってコピーのみのバックアップが作成されます。トランザクション ログは切り捨てられません。コピーのみのログ バックアップはログ チェーンに影響せず、他のログ バックアップはコピーのみのバックアップが存在しない場合と同様に動作します。

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

  • DESCRIPTION = { 'text' | **@**text_variable }
    バックアップ セットを記述したテキストを自由な形式で指定します。文字列の長さは最大 255 文字です。
  • NAME = { backup_set_name| **@**backup_set_var }
    バックアップ セットの名前を指定します。名前の長さは最大 128 バイトです。NAME を指定しないと、名前は空白になります。
  • PASSWORD = { password | **@**password_variable }
    バックアップ セットのパスワードを設定します。PASSWORD は文字列です。バックアップ セットのパスワードが定義されている場合は、パスワードを指定して、バックアップ セットから SQL Server 復元操作を実行する必要があります。ただし、バックアップ セットのパスワードを指定しても、バックアップ ファイルの上書きを防止することはできません。バックアップ ファイルが上書きされないようにするには、代わりにメディア セットのパスワードを使用します (後の MEDIAPASSWORD オプションの説明を参照)。パスワードの使用の詳細については、後の「権限」を参照してください。

    ms186865.security(ja-jp,SQL.90).gifセキュリティ メモ :
    パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server 2005 ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。バックアップ保護に最適な方法は、バックアップ テープを安全な場所に保管するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。
    ms186865.note(ja-jp,SQL.90).gifメモ :
    PASSWORD オプションは、SQL Server の将来のリリースで削除される予定です。
  • [ EXPIREDATE = date | RETAINDAYS = date ]
    このバックアップのバックアップ セットがいつ上書きできるようになるかを指定します。オプションを両方とも使用した場合は、RETAINDAYS が EXPIREDATE よりも優先されます。

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

    ms186865.note(ja-jp,SQL.90).gif重要 :
    これらのオプションは、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 値の指定方法については、「アルファベット日付形式」および「数値日付形式」を参照してください。

      ms186865.note(ja-jp,SQL.90).gifメモ :
      失効日を無視するには、SKIP オプションを使用します。
    • RETAINDAYS = { days| **@days_var }
      このバックアップ メディア セットに上書きできるようになるまでの経過日数を指定します。この日数を変数 (
      @**days_var) として指定する場合は、整数で指定する必要があります。
  • NO_LOG
    BACKUP DATABASE ステートメントのコンテキストで、バックアップにログを含めないことを指定します。これは SQL Server 2005 より前のバージョンでファイル バックアップが作成される方法です。NO_LOG を指定して作成したデータベース バックアップは、ログ レコードを含まないファイル バックアップの完全なセットと同じになります。

    完全復旧モデルにおいて、迅速にデータをバックアップする必要があり、データの一連のログ バックアップがすべて揃っている場合は、NO_LOG を使用すると便利です。

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

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

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

    ms186865.note(ja-jp,SQL.90).gifメモ :
    { NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。
    • NOINIT
      バックアップ セットを指定のメディア セットに追加します。この場合、既存のバックアップ セットは維持されます。メディア セットのメディア パスワードが定義されている場合は、パスワードを指定する必要があります。既定値は NOINIT です。

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

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

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

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

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

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

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

    ms186865.note(ja-jp,SQL.90).gifメモ :
    { NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。
    • NOSKIP
      上書きを許可する前に、メディア上のすべてのバックアップ セットの有効期限を確認することを BACKUP ステートメントに指示します。これは既定の動作です。
    • SKIP
      BACKUP ステートメントによって通常実行されるバックアップ セットの有効期限と名前の確認を無効にして、バックアップ セットの上書きを防止します。{ INIT | NOINIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。

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

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

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

      ms186865.note(ja-jp,SQL.90).gif重要 :
      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 は文字列です。

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

    ms186865.security(ja-jp,SQL.90).gifセキュリティ メモ :
    パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server 2005 ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。バックアップ保護に最適な方法は、バックアップ テープを安全な場所に保管するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。
    ms186865.note(ja-jp,SQL.90).gifメモ :
    MEDIAPASSWORD オプションは、SQL Server の将来のリリースで削除される予定です。
  • BLOCKSIZE = { blocksize | **@**blocksize_variable }
    物理ブロック サイズをバイト単位で指定します。サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。通常は、BACKUP でデバイスに適するブロック サイズが自動的に選択されるので、このオプションは不要です。ブロック サイズは、自動的に選択された値よりも明示的に指定された値が優先されます。

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

    ms186865.note(ja-jp,SQL.90).gifメモ :
    このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。

データ転送オプション

  • 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 ステートメント内で同時に使用することはできません。

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

    ms186865.note(ja-jp,SQL.90).gifメモ :
    UNLOAD または NOUNLOAD はセッションの設定であり、セッションが終了するまで、または代わりとなるオプションの指定によりリセットされるまで有効です。
    • UNLOAD
      バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行います。UNLOAD はセッション開始時の既定の設定です。
    • NOUNLOAD
      BACKUP 操作の後、テープ ドライブにテープを読み込んだままにすることを指定します。
ms186865.note(ja-jp,SQL.90).gifメモ :
テープ バックアップ デバイスへのバックアップの場合、BLOCKSIZE オプションはバックアップ操作のパフォーマンスに影響します。このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。

ログ関係のオプション

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

ms186865.note(ja-jp,SQL.90).gifメモ :
ログ バックアップを作成しない場合は、単純復旧モデルを使用します。詳細については、「単純復旧モデルでのバックアップ」を参照してください。
  • { NORECOVERY | STANDBY **=**undo_file_name }

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

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

    • STANDBY **=**standby_file_name
      ログの末尾をバックアップし、データベースを読み取り専用および STANDBY 状態のままにします。STANBY 句では、スタンバイ データが書き込まれます。スタンバイ データには、ロールバックを実行しても、追加の復元を行うためのオプションが格納されます。STANBY オプションの使用は、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 オプションを実行しない場合、データベースはオンラインにする必要があります。

    データベースが OFFLINE または EMERGENCY 状態の場合、BACKUP では NO_TRUNCATE を使用できません。

  • [ NO_LOG | TRUNCATE_ONLY ]

    ms186865.note(ja-jp,SQL.90).gifメモ :
    このオプションは将来のバージョンの SQL Server では削除される予定です。新しい開発作業では、このオプションの使用は避け、現在このオプションを使用しているアプリケーションは修正するようにしてください。

    BACKUP LOG ステートメントでのみ、チェックポイントを実行して手動でトランザクション ログを切り捨てるときに使用します。NO_LOG および TRUNCATE_ONLY はシノニムです。ログはバックアップされないため、バックアップ デバイスの指定は必要ありません。

    単純復旧モデルでチェックポイントを実行すると、ログ中のアクティブでない部分は削除され、バックアップ コピー作成の対象となりません。つまり、アクティブな部分以外のすべてのログは切り捨てられます。このオプションでは領域が解放されますが、データ損失の可能性があります。NO_LOG または TRUNCATE_ONLY を使用してログを切り捨てた後は、次回のデータベース バックアップまで、切り捨てられた部分に記録されていた変更は復旧できません。復旧を可能にするには、どちらかのオプションを使用した後、すぐに BACKUP DATABASE を実行して、完全なデータベース バックアップまたは差分データベース バックアップを実行する必要があります。

    ms186865.Caution(ja-jp,SQL.90).gif注意 :
    NO_LOG または TRUNCATE_ONLY を使用して手動でトランザクション ログを切り捨てると、ログ チェーンが分断されるので、使用しないことをお勧めします。次の完全バックアップまたは差分バックアップまで、データベースをメディア障害から防ぐことはできません。手動でのログ切り捨ては非常に特殊な環境でのみ行い、データのバックアップはすぐに作成してください。

解説

データベースやログのバックアップは、任意のディスクまたはテープ デバイスに追加できます。これによって、データベースとそのトランザクション ログをすべて 1 つの物理位置に格納できます。

BACKUP ステートメントは、明示的または暗黙的なトランザクションでは使用できません。

オペレーティング システムがデータベースの照合順序をサポートしている場合は、プロセッサの種類が違っていても、1 つのプラットフォームから別のプラットフォームにわたるバックアップ操作を実行できます。

バックアップの用語、バックアップ デバイス、バックアップの管理については、「SQL Server でのバックアップ メディアの操作」を参照してください。

同時実行

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

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

  • ADD FILE または REMOVE FILE のいずれかのオプションが指定された ALTER DATABASE ステートメントなどのファイル管理操作。
  • データベースまたはファイルの圧縮操作。これには自動圧縮操作も含まれます。

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

バックアップ メディアのフォーマット

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

  • FORMAT オプションが指定されている。
  • メディアが空である。
  • 連続するテープに書き込んでいる。

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

バックアップの種類

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

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

    バックアップの範囲 バックアップの種類

    データベース全体

    データベース バックアップでは、データベース全体が対象となります。

    データベースの部分バックアップ

    部分バックアップでは、読み取り/書き込みファイル グループと、必要に応じて 1 つ以上の読み取り専用ファイル グループが対象となります。

    ファイルまたはファイル グループ

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

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

    ms186865.note(ja-jp,SQL.90).gifメモ :
    最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。

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

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

フルテキスト データのバックアップ

SQL Server 2005 での完全データベース バックアップの実行中、フルテキスト データが他のデータベース データと一緒にバックアップされます。バックアップ操作では、フルテキスト カタログはファイルとして扱われます。たとえば、カタログは FILE= 句を使用してカタログを選択することにより個別にバックアップできます。各フルテキスト カタログの論理ファイル名は、sysft_<catalog name> の形式です。

バックアップ中にカタログは読み取り専用モードになるため、バックアップが完了するまで "クロール" 処理 (フルテキスト インデックスの作成と維持の処理) は中断されます。

SKIP、NOSKIP、INIT および NOINIT の相関関係

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

ms186865.note(ja-jp,SQL.90).gifメモ :
テープ メディアが空の場合、またはディスクのバックアップ ファイルが存在しない場合は、これらすべての相関関係に基づいて、メディア ヘッダーが記述され、操作が継続します。ただしメディアが空でなく、有効なメディア ヘッダーが含まれない場合、これらの操作では有効な MTF メディアでないことが返され、バックアップ操作は中断されます。
  NOINIT INIT

NOSKIP

ボリュームに有効なメディア ヘッダーが含まれる場合は、このメディアのパスワードを確認し、MEDIANAME が指定されていれば、その値とメディア名が一致していることを確認します。メディア名が一致した場合は、すべての既存のバックアップ セットはそのままにして、バックアップ セットを追加します。

ボリュームに有効なメディア ヘッダーが含まれない場合、エラーが発生します。

ボリュームに有効なメディア ヘッダーが含まれている場合は、次のチェックを実行します。

  • メディア パスワードを確認します。2
  • MEDIANAME を指定した場合は、指定されているメディア名がメディア ヘッダーのメディア名と一致していることを確認します。
  • メディア上に失効前のバックアップ セットが存在していないかを確認します。
    存在している場合は、バックアップを中断します。

上のチェックにパスした場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。

ボリュームに有効なメディア ヘッダーが含まれない場合は、MEDIANAME、MEDIAPASSWORD、および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。

SKIP

ボリュームに有効なメディア ヘッダーが含まれる場合は、このメディアのパスワードを確認し、すべての既存のバックアップ セットをそのままにして、バックアップ セットを追加します。

ボリュームに有効な 1 メディア ヘッダーが含まれる場合は、このメディアのパスワードを確認し、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。

メディアが空の場合は、MEDIANAME、MEDIAPASSWORD、および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。

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

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

バックアップ履歴テーブル

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

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

互換性サポート

ms186865.Caution(ja-jp,SQL.90).gif注意 :
最新バージョンの SQL Server によって作成されたバックアップは、以前のバージョンの SQL Server では復元できません。

BACKUP には、以前のバージョンの SQL Server との互換性を維持するため、次のキーワードが用意されています。

  • RESTART オプションは、互換性のため残してありますが、SQL Server 2005 では指定しても効果はありません。
  • 旧バージョンとの互換性を維持するため、BACKUP ステートメントでは BACKUP キーワードの代わりに DUMP キーワードを使用することもできます。また、LOG の代わりに TRANSACTION キーワードを使用することもできます。SQL Server データベース エンジンでは、DUMP DATABASE、DUMP TRANSACTION が、それぞれ BACKUP DATABASE、BACKUP LOG と同じものと解釈されます。
    ms186865.note(ja-jp,SQL.90).gif重要 :
    DUMP ステートメントは、旧バージョンとの互換性のために用意されています。この機能は、将来のバージョンの Microsoft SQL Server では削除される予定です。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。代わりに BACKUP を使用してください。

ストライプ メディア セット (ストライプセット) 内のバックアップ デバイス

ストライプセットとは、データがブロックに分割され、一定の順序で展開される、一連のディスク ファイルです。ストライプセットで使用されるバックアップ デバイスの数は、(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
ms186865.note(ja-jp,SQL.90).gif重要 :
この例は、ローカル システム上でテストできるように設計されています。実際には同じドライブ上にある複数のデバイスにバックアップすると、パフォーマンスが低下するおそれがあり、ミラー化されたメディア セットの設計目的でもある冗長性が損なわれる可能性があります。

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

BACKUP ステートメントの TO 句で指定する各バックアップ デバイスは、1 つのメディア ファミリとなります。たとえば、TO 句で 3 つのデバイスのリストを指定する場合、BACKUP では 3 つのメディア ファミリにデータが書き込まれます。ミラー化されたメディア セットでは、各ミラーにすべてのメディア ファミリのコピーが含まれている必要があります。このため、各ミラーでデバイス数が一致する必要があります。

各ミラーに対し複数のデバイスのリストを指定する順番によって、どのメディア ファミリがどのデバイスに書き込まれるかが決まります。たとえば、各デバイスのリストで、2 番目のデバイスは 2 番目のメディア ファミリに対応します。先に示した例のデバイスでは、デバイスとメディア ファミリの対応は次の表のようになります。

ミラー メディア ファミリ 1 メディア ファミリ 2 メディア ファミリ 3

0

C:\AdventureWorks1a.bak

C:\AdventureWorks2a.bak

C:\AdventureWorks3a.bak

1

C:\AdventureWorks1b.bak

C:\AdventureWorks2b.bak

C:\AdventureWorks3b.bak

1 つのメディア ファミリは常に、特定のミラー内の同じデバイス上にバックアップされる必要があります。したがって、既存のメディア セットを使用するときは毎回、メディア セットを作成したときと同じ順序で各ミラーのデバイスを列挙してください。

ミラー化メディア セットの詳細については、「ミラー化バックアップ メディア セットの使用」を参照してください。一般的なメディア セットおよびメディア ファミリの詳細については、「メディア セット、メディア ファミリ、およびバックアップ セット」を参照してください。

権限

BACKUP DATABASE 権限と BACKUP LOG 権限は、既定では、sysadmin 固定サーバー ロール、db_owner 固定データベース ロール、および db_backupoperator 固定データベース ロールのメンバに与えられています。

また、ユーザーがメディア セット パスワード、バックアップ セット パスワード、またはその両方を指定する場合もあります。パスワードがメディア セットで定義されている場合も、ユーザーはメディア パスワードを指定してこれらの操作を実行する必要があります。同様に、復元コマンドで正しいメディア パスワードおよびバックアップ セット パスワードを指定しないと、復元は実行されません。

バックアップ セットとメディア セットのパスワードの定義は、BACKUP ステートメントのオプション機能です。パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server 2005 ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。また、パスワードでは FORMAT オプションによるメディアの上書きは防げません。強力なパスワードを使用することをお勧めします。強力なパスワードについては、「強力なパスワード」を参照してください。

このように、パスワードを使用することで、SQL Server ツールを使って行われる不正アクセスからメディアの内容を保護することはできますが、内容の破棄を防ぐことはできません。なお、バックアップ セット内のデータは暗号化されていないため、不正アクセスを目的に特別に作成されたプログラムを使用すれば、理論上はデータの傍受が可能です。このため、パスワードだけでは不正アクセスから完全にメディアの内容を保護することはできません。セキュリティがきわめて重要な状況においては、不正ユーザーによるメディアへの物理的アクセスを防ぐことが重要になります。

パスワードと関連付けて作成されていないオブジェクトに対しては、パスワードを指定できません。

BACKUP は、PASSWORD オプションで指定されるバックアップ セット パスワードを使用して、バックアップ セットを作成します。また、通常は、メディアに書き込む前に、MEDIAPASSWORD オプションで指定されるメディア パスワードを確認します。メディア ヘッダーを上書きするメディアのフォーマットが行われる場合に限り、BACKUP はメディア パスワードを確認しません。BACKUP によってメディア ヘッダーが作成される場合、メディア セット パスワードは MEDIAPASSWORD オプションで指定される値に割り当てられます。

SKIP、NOSKIP、INIT、および NOINIT におけるパスワードの影響の詳細については、後の「解説」を参照してください。

バックアップ デバイスの物理ファイルに対する所有と許可の問題によって、バックアップ操作が妨げられることがあります。SQL Server では、デバイスに対して読み書きを実行できる必要があります。SQL Server サービスが実行されているアカウントには書き込み権限が必要です。ただし、システム テーブルにデバイスのエントリを追加する sp_addumpdevice では、ファイル アクセスの権限は確認されません。バックアップ デバイスの物理ファイルに関するこのような問題は、バックアップや復元が試行され、物理リソースがアクセスされるまで、表面化しない可能性があります。

ms186865.note(ja-jp,SQL.90).gifメモ :
ここでは、AdventureWorks データベースを例に使用します。AdventureWorks は SQL Server 2005 のサンプル データベースの 1 つです。Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。このデータベースの詳細については、「サンプル データとサンプル データベース」を参照してください。

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

  • A. データベース全体をバックアップする
  • B. データベースおよびログをバックアップする
  • C. セカンダリ ファイル グループの完全ファイル バックアップを作成する
  • D. セカンダリ ファイル グループの差分ファイル バックアップを作成する
  • E. 単一ファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する
  • F. マルチファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する
  • G. 既存のミラー化メディア セットにバックアップを作成する
ms186865.note(ja-jp,SQL.90).gifメモ :
バックアップ方法に関するトピックで、さらに例を記載しています。詳細については、「バックアップと復元を行う方法に関するトピック (Transact-SQL)」を参照してください。

A. データベース全体をバックアップする

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

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

B. データベースおよびログをバックアップする

次の例では、既定により単純復旧モデルを使用する 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', 
'Z:\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
ms186865.note(ja-jp,SQL.90).gifメモ :
運用データベースでは、ログを定期的にバックアップしてください。ログのバックアップは、データ損失を防ぐため、頻繁に行ってください。

C. セカンダリ ファイルグループの完全ファイル バックアップを作成する

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

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

D. セカンダリ ファイルグループの差分ファイル バックアップを作成する

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

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

E. 単一ファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する

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

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

F. マルチファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する

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

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

G. 既存のミラー化メディア セットにバックアップを作成する

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

BACKUP LOG AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorksSet1'
ms186865.note(ja-jp,SQL.90).gifメモ :
NOINIT は既定値ですが、ここではわかりやすくするために記載しています。

[例の先頭に戻る]

参照

関連項目

ALTER DATABASE (Transact-SQL)
DBCC SQLPERF (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE FILELISTONLY (Transact-SQL)
RESTORE HEADERONLY (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)
sp_addumpdevice (Transact-SQL)
sp_configure (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)

その他の技術情報

SQL Server データベースの完全バックアップおよび差分バックアップの作成
SQL Server でのバックアップ メディアの操作
メディア セット、メディア ファミリ、およびバックアップ セット
トランザクション ログのバックアップ

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース 履歴

2006 年 7 月 17 日

変更内容 :
  • 「構文」と「引数」で、関連するオプションがグループになるよう構成を変更。
  • MIRROR TO オプションの説明を拡張。
  • 「バックアップの種類」を追加。
  • 「互換性サポート」を追加。
  • 「ミラー化されたメディア セットの操作」を追加。
  • 完全ファイル バックアップと差分ファイル バックアップの例を追加。

2006 年 4 月 14 日

新しい内容 :
  • 「構文」と「引数」に、BUFFERCOUNT オプションおよび MAXTRANSFERSIZE オプションを追加。
変更内容 :
  • サポートされるブロック サイズを一覧で示し、BLOCKSIZE の説明内のパフォーマンスに関する注記を更新。
  • {REWIND | NOREWIND} および {UNLOAD | NOUNLOAD} オプションの説明を更新。

2005 年 12 月 5 日

変更内容 :
  • NO_LOG オプションと TRUNCATE_ONLY オプションの説明を明記。