次の方法で共有

BACKUP (Transact-SQL)

  • [アーティクル]

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

注意注

SQL Server 2012 SP1 Cumulative Update 2 以降、Windows Azure BLOB ストレージ サービスへの SQL Server バックアップがサポートされるようになりました。 詳細については、「バックアップと復元の機能強化」および「Windows Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元」を参照してください。

トピック リンク アイコン 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 ] ]
[;]

<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 
 | { COMPRESSION | NO_COMPRESSION } 
 | DESCRIPTION = { 'text' | @text_variable } 
 | NAME = { backup_set_name | @backup_set_name_var } 
 | { EXPIREDATE = { 'date' | @date_var } 
        | RETAINDAYS = { days | @days_var } } 

--Media Set Options
   { NOINIT | INIT } 
 | { NOSKIP | SKIP } 
 | { NOFORMAT | FORMAT } 
 | MEDIADESCRIPTION = { 'text' | @text_variable } 
 | MEDIANAME = { media_name | @media_name_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 では、バックアップが復元された場合に一貫性のあるデータベースを生成できるよう、必要十分なトランザクション ログをバックアップします。

    BACKUP DATABASE (データ バックアップ) で作成されたバックアップを復元すると、バックアップ全体が復元されます。 バックアップ内の特定の時点またはトランザクションに復元できるのは、ログ バックアップだけです。

    注意注

    master データベース上では、データベース全体のバックアップのみが可能です。

  • LOG
    トランザクション ログのみのバックアップを指定します。 前回正しく実行されたログ バックアップの位置から、ログの現在の末尾まで、ログのバックアップが行われます。 最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。

    RESTORE LOG ステートメントで WITH STOPAT、WITH STOPATMARK、または WITH STOPBEFOREMARK を指定して、バックアップ内の特定の時間またはトランザクションにログ バックアップを復元できます。

    注意注

    WITH NO_TRUNCATE または COPY_ONLY を指定する以外の標準的な方法でログ バックアップを行うと、一部のトランザクション ログ レコードはアクティブでなくなります。 1 つ以上の仮想ログ ファイル内ですべてのレコードがアクティブでなくなった場合、ログは切り捨てられます。 定期的なログ バックアップの後ログが切り捨てられない場合は、何らかの原因によりログの切り捨てが遅れている可能性があります。 詳細については、次を参照してください。

  • { database_name| **@database_name_var }
    トランザクション ログ、データベースの一部、またはデータベース全体をバックアップする場合の、バックアップ元となるデータベースを指定します。 この名前を変数 (    @database_name_var) として指定する場合は、文字定数 (@**database_name_var = database name)、または ntext と text を除く文字列データ型の変数のいずれかを使用して指定できます。

    注意注

    データベース ミラーリング パートナーシップ内のミラー データベースは、バックアップできません。

  • <file_or_filegroup> [ ,...n ]
    BACKUP DATABASE でのみ使用できます。ファイル バックアップに含めるデータベース ファイルまたはファイル グループを指定するか、部分バックアップに含める読み取り専用ファイルまたはファイル グループを指定します。

    • FILE = { logical_file_name| **@**logical_file_name_var }
      バックアップに含めるファイルの論理名、またはこの論理名を値として保持する変数を指定します。

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

      注意注

      データベースのサイズやパフォーマンス要件によりデータベース バックアップの実行が難しい場合は、ファイル単位のバックアップを検討してください。

    • n
      複数のファイルおよびファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダーです。 数値の制限はありません。

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

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

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

      重要な注意事項重要

      READ_WRITE_FILEGROUPS の代わりに FILEGROUP を使用して、読み取り/書き込みファイル グループのリストを明示的に指定すると、ファイル バックアップが作成されます。

    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      部分バックアップに含める読み取り専用ファイル グループの論理名、またはこの論理名を値として保持する変数を指定します。 詳細については、前の「<file_or_filegroup>」を参照してください。

    • n
      複数の読み取り専用ファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダーです。

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

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

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

      • { logical_device_name | **@**logical_device_name_var }
        データベースのバックアップが作成されるバックアップ デバイスの論理名を指定します。 論理名は、識別子のルールに従う必要があります。 バックアップ デバイス名を変数 (@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 オプションが指定されていない場合、バックアップはデバイスに追加されます。

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

        注意注

        TAPE オプションは将来のバージョンの SQL Server では削除される予定です。 新しい開発作業では、この機能の使用を避け、現在この機能を使用しているアプリケーションは修正するようにしてください。

    • n
      最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダーです。

  • MIRROR TO <backup_device> [ ,...n]
    TO 句で指定したバックアップ デバイスをミラー化する、最大 3 つまでのセカンダリ バックアップ デバイスのセットを指定します。 MIRROR TO 句には、TO 句で指定した同じ種類と数のバックアップ デバイスを指定する必要があります。 MIRROR TO 句の最大数は 3 です。

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

    注意注

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

    注意注

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

    詳細については、「差分バックアップ (SQL Server)」を参照してください。

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

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

注意注

復元操作用のバックアップ セットを指定するには、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 オプションによってコピーのみのログ バックアップが作成されます。トランザクション ログは切り捨てられません。 コピーのみのログ バックアップはログ チェーンに影響せず、他のログ バックアップはコピーのみのバックアップが存在しない場合と同様に動作します。

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

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

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

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

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

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

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

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

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

    重要な注意事項重要

    これらのオプションは、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 です。

      詳細については、「メディア セット、メディア ファミリ、およびバックアップ セット (SQL Server)」を参照してください。

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

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

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

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

      詳細については、「メディア セット、メディア ファミリ、およびバックアップ セット (SQL Server)」を参照してください。

  • { 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 オプションを指定した場合、メディア名の照合チェックは行われません。

  • 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 の計算によって算出されます。

    注意注

    BUFFERCOUNT オプションの使用方法に関する重要な情報については、ブログ「不適切な BufferCount データ転送オプションによって OOM の状態になる」を参照してください。

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

エラー管理オプション

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

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

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

    • CHECKSUM
      有効かつ使用可能であれば、バックアップ操作に対し、各ページのチェックサムおよび破損ページを検証し、バックアップ全体のチェックサムを生成するように指定します。 これは圧縮されたバックアップの既定の動作です。

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

    詳細については、「バックアップ中および復元中に発生する可能性があるメディア エラー (SQL Server)」を参照してください。

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

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

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

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

    詳細については、「バックアップ中および復元中に発生する可能性があるメディア エラー (SQL Server)」を参照してください。

互換性オプション

  • RESTART
    SQL Server 2008 以降では、無効です。 このオプションが利用できるのは、以前のバージョンの 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 オプションが使用されるか、サーバー インスタンスがシャットダウンすると、所有権は解放されます。 テープを開いたままにすると、他のプロセスはそのテープにアクセスできません。 開いているテープの一覧を表示する方法、および開いているテープを閉じる方法については、「バックアップ デバイス (SQL Server)」を参照してください。

  • { UNLOAD | NOUNLOAD }

    注意注

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

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

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

注意注

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

ログ関係のオプション

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

注意注

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

  • { 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 を実行できません。 データベースの状態については、「データベースの状態」を参照してください。

SQL Server バックアップの操作について

このセクションでは、次の基本的なバックアップの概念について説明します。

バックアップの種類

トランザクション ログの切り捨て

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

バックアップ デバイスとメディア セットの操作

SQL Server バックアップの復元

注意注

SQL Server でのバックアップの概要については、「バックアップの概要 (SQL Server)」を参照してください。

バックアップの種類

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

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

    バックアップの範囲

    バックアップの種類

    データベース全体

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

    必要に応じて、各データベース バックアップは、1 つ以上のデータベースの差分バックアップのベースとして使用することもできます。

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

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

    必要に応じて、各部分バックアップは、1 つ以上のデータベースの部分バックアップのベースとして使用することもできます。

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

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

    必要に応じて、各ファイル バックアップは、1 つ以上のファイルの差分バックアップのベースとして使用することもできます。

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

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

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

    注意注

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

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

トランザクション ログの切り捨て

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

注意注

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

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

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

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

  • メディアが空である。

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

バックアップ デバイスとメディア セットの操作

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

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

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

BACKUP DATABASE AdventureWorks2012
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 AdventureWorks2012 database;
GO

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

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

ミラー化されたメディア セットの操作

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

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

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

BACKUP DATABASE AdventureWorks2012
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
重要な注意事項重要

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

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

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

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

ミラー

メディア ファミリ 1

メディア ファミリ 2

メディア ファミリ 3

0

Z:\AdventureWorks1a.bak

Z:\AdventureWorks2a.bak

Z:\AdventureWorks3a.bak

1

Z:\AdventureWorks1b.bak

Z:\AdventureWorks2b.bak

Z:\AdventureWorks3b.bak

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

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

SQL Server バックアップの復元

データベースを復元し、必要に応じて、そのデータベースを復旧してオンラインにする、またはファイルやファイル グループを復元するには、Transact-SQL の RESTORE ステートメントを使用するか、SQL Server Management Studio の復元タスクを使用します。 詳細については、「復元と復旧の概要 (SQL Server)」を参照してください。

BACKUP のオプションに関するその他の注意点

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

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

注意注

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

 

NOINIT

INIT

NOSKIP

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

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

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

  • MEDIANAME を指定した場合は、指定されているメディア名がメディア ヘッダーのメディア名と一致していることを確認します。 2

  • メディア上に失効前のバックアップ セットが存在していないことを確認します。

    存在している場合は、バックアップを中断します。

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

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

SKIP

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

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

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

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

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

互換性

注記注意

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

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

全般的な解説

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

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

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

注意注

既定では、バックアップ操作が成功するたびに、SQL Server エラー ログおよびシステム イベント ログにエントリが 1 つ追加されます。 ログを頻繁にバックアップすると、これらの成功メッセージがすぐに蓄積され、他のメッセージを探すのが困難になるほどエラー ログが大きくなることがあります。 そのような場合、これらのエントリに依存するスクリプトがなければ、トレース フラグ 3226 を使用することによってこれらのログ エントリを除外できます。 詳細については、「トレース フラグ (Transact-SQL)」を参照してください。

相互運用性

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

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

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

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

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

メタデータ

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

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

セキュリティ

SQL Server 2012 以降では、バックアップの作成での PASSWORD と MEDIAPASSWORD オプションが廃止されました。 パスワード付きで作成されたバックアップを復元することは、引き続き可能です。

権限

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

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

使用例

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

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

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

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

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

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

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

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

  • H. 新しいメディア セットに圧縮されたバックアップを作成する

注意注

バックアップ方法に関するトピックで、さらに例を記載しています。 詳細については、「バックアップの概要 (SQL Server)」を参照してください。

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

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

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

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

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

次に 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 AdventureWorks2012
   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 AdventureWorks2012 database.
BACKUP DATABASE AdventureWorks2012 TO AdvWorksData;
GO
-- Back up the AdventureWorks2012 log.
BACKUP LOG AdventureWorks2012
   TO AdvWorksLog;
GO
注意注

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

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 つのミラーを含むミラー化メディア セットを作成し、そこに AdventureWorks2012 データベースのバックアップを作成します。

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

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

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

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

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

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

BACKUP LOG AdventureWorks2012
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorksSet1';
注意注

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

[例の先頭に戻る]

H. 新しいメディア セットに圧縮されたバックアップを作成する

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

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

[例の先頭に戻る]

関連項目

参照

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)

サーバー構成オプション