BACKUP (Transact-SQL)

SQL Database をバックアップします。

製品を選択する

次の行で、興味のある製品の名前を選択すると、その製品の情報のみが表示されます。

構文表記規則の詳細については、「Transact-SQL 構文表記規則」を参照してください。

* SQL Server *  

SQL Managed Instance

Analytics Platform
System (PDW)

 

SQL Server

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

構文

--Back 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 ] } ]
[;]

--Back 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 ] } ]
[;]

--Create 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 ] } ]
[;]

--Back 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_options> } [ ,...n ] ]
[;]

--Back up all the databases on an instance of SQL Server (a server)

ALTER SERVER CONFIGURATION
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
[;]

BACKUP SERVER
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up a group of databases
ALTER DATABASE <database>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON

ALTER DATABASE <...>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
...

BACKUP GROUP {<database> [,... ]}
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

<backup_device>::=
 {
  { logical_device_name | @logical_device_name_var }
 | {   DISK
     | TAPE
     | URL } =
     { 'physical_device_name' | @physical_device_name_var | 'NUL' }
 }

<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 [ ALGORITHM = { MS_XPRESS | accelerator_algorithm } ] | NO_COMPRESSION ]
 | DESCRIPTION = { 'text' | @text_variable }
 | NAME = { backup_set_name | @backup_set_name_var }
 | CREDENTIAL
 | ENCRYPTION
 | FILE_SNAPSHOT
 | { EXPIREDATE = { 'date' | @date_var }
        | RETAINDAYS = { days | @days_var } }
 | { METADATA_ONLY | SNAPSHOT }

--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 }

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

<log_specific_options> [ ,...n ]::=
--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

引数

DATABASE

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

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

Note

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

LOG

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

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

Note

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

GROUP (<database>,...n)

SQL Server 2022 (16.x) で導入されています。

データベースのグループをバックアップします。 スナップショット バックアップを使用します。 WITH METADATA_ONLY が必要です。 「Transact-SQL スナップショット バックアップを作成する」を参照してください。

SERVER

SQL Server 2022 (16.x) で導入されています。

SQL Server のインスタンス上のすべてのデータベースをバックアップします。 スナップショット バックアップを使用します。 WITH METADATA_ONLY が必要です。 「Transact-SQL スナップショット バックアップを作成する」を参照してください。

METADATA_ONLY

SQL Server 2022 (16.x) で導入されています。

スナップショット バックアップに必須です。 BACKUP SERVER または BACKUP GROUP... 「Transact-SQL スナップショット バックアップを作成する」を参照してください。

METADATA_ONLY は SNAPSHOT と同義です。 仮想デバイス インターフェイス (VDI) では SNAPSHOT が使用されます。 VDI の詳細については、「仮想デバイス インターフェイス (VDI) リファレンス」を参照してください。

{ database_name | @database_name_var }

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

Note

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

<file_or_filegroup> [ ,...n ]

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

FILE = { logical_file_name | @logical_file_name_var }

バックアップに含めるファイルの論理名、またはこの論理名を値として保持する変数を指定します。

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

バックアップに含めるファイルグループの論理名、またはファイルグループの論理名を値として保持する変数です。 単純復旧モデルでは、ファイル グループのバックアップは、読み取り専用のファイル グループに対してのみ使用できます。

Note

データベースのサイズおよびパフォーマンス要件によりデータベース バックアップの実行が難しい場合は、ファイル バックアップの利用を検討してください。 NUL デバイスはバックアップのパフォーマンスをテストするために使用できますが、運用環境では使用できません。

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

詳しくは、「ファイルの完全バックアップ」および「ファイルおよびファイル グループのバックアップ」をご覧ください。

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

部分バックアップについて詳しくは、「部分バックアップ」をご覧ください。

TO <backup_device> [ ,...n ]

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

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

{ logical_device_name | @logical_device_name_var }

適用対象: SQL Server
データベースのバックアップが作成されるバックアップ デバイスの論理名です。 論理名は、識別子のルールに従う必要があります。 変数 (@logical_device_name_var) として指定する場合、バックアップ デバイス名は、文字列定数 (@logical_device_name_var= logical backup device name) として、または ntext や text データ型を除く、文字列データ型の変数として指定できます。

{ DISK |TAPE |URL} = { 'physical_device_name' | @physical_device_name_var |'NUL' }

適用対象: SQL Server (SQL Server 2012 (11.x) SP1 CU2 で始まる URL)

ディスク ファイルまたはテープ デバイスまたは URL を指定します。

URL 形式は、Microsoft Azure Blob Storage または S3 互換のオブジェクト ストレージへのバックアップを作成するために使用されます。 詳細および例については、次をご覧ください。

• Microsoft Azure Blob Storage を使用した SQL Server のバックアップと復元 チュートリアルについては、「チュートリアル: Microsoft Azure Blob Storage への SQL Server のバックアップと復元」を参照してください。
• S3 互換ストレージへのバックアップと復元は、SQL Server 2022 (16.x) で導入されました。「S3 互換オブジェクト ストレージを使用した SQL Server のバックアップと復元」を参照してください。 また、S3 互換オブジェクト ストレージの URL への SQL Server バックアップのオプションも確認してください。

Note

NUL ディスク デバイスは送信される情報をすべて破棄し、テストでのみ使用する必要があります。 これは運用環境向けではありません。

重要

SQL Server 2012 (11.x) SP1 CU2 から SQL Server 2014 (12.x) では、Azure Blob Storage の URL にバックアップする場合、単一デバイスにのみバックアップできます。 URL へのバックアップ時に複数のデバイスにバックアップするには、SQL Server 2016 (13.x) 以降を使用する必要があります。また、Shared Access Signature (SAS) トークンを使用する必要があります。 Shared Access Signature の作成例については、「SQL Server Backup to URL」と「Simplifying creation of SQL Credentials with Shared Access Signature ( SAS ) tokens on Azure Storage with Powershell」 (Powershell を使用する Azure ストレージにおける Shared Access Signature (SAS) トークンでの SQL 資格情報の作成の簡素化) を参照してください。

ディスク デバイスは、BACKUP ステートメント内で指定するときに、まだ存在していなくてもかまいません。 物理デバイスが既に存在し、BACKUP ステートメントに INIT オプションが指定されていない場合、バックアップはデバイスに追加されます。

Note

NUL デバイスはこのファイルに送信されるすべての入力を破棄しますが、バックアップでは引き続きすべてのページがバックアップ済みとしてマークされます。

詳しくは、「バックアップ デバイス」をご覧ください。

Note

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

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

mirror to <backup_device> [ ,...n ]

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

このオプションは、SQL Server の Enterprise Edition でのみ使用できます。

Note

MIRROR TO = DISK の場合、BACKUP では、ディスクのセクター サイズに基づいてディスク デバイスの適切なブロック サイズが自動的に決まります。 プライマリ バックアップ デバイスとして指定されたディスクとは異なるセクター サイズを使用して MIRROR TO ディスクがフォーマットされた場合、Backup コマンドは失敗します。 バックアップを異なるセクター サイズのデバイスにミラーリングするには、BLOCKSIZE パラメーターを指定し、すべてのターゲット デバイスの中で最も高いセクター サイズに設定する必要があります。 ブロック サイズの詳細については、このトピックで後述する "BLOCKSIZE" の説明を参照してください。

<backup_device>
詳細については、前の "" を参照してください。

n
コンマ区切りリストに最大 64 個のバックアップ デバイスが指定される可能性があることを示すプレースホルダーです。 MIRROR TO 句内のデバイス数は、TO 句内のデバイス数と同じにする必要があります。

詳細については、この記事の後述の「解説」の「ミラー化されたメディア セットのメディア ファミリ」を参照してください。

[ next-mirror-to ]
単一の BACKUP ステートメントに、1 つの TO 句と 3 つまでの MIRROR TO 句を含めることができることを示すプレースホルダーです。

WITH オプション

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

CREDENTIAL

適用対象: SQL Server (SQL Server 2012 (11.x) SP1 CU2 以降)。

Azure Blob Storage へのバックアップを作成する場合にのみ使用されます。

FILE_SNAPSHOT

適用対象: SQL Server (SQL Server 2016 (13.x) 以降)。

すべての SQL Server データベース ファイルが Azure Blob Storage を使用して格納される場合は、データベース ファイルの Azure スナップショットを作成するために使用します。 詳細については、「Microsoft Azure 内の SQL Server データ ファイル」を参照してください。 SQL Server スナップショット バックアップでは、データベース ファイル (データとログ ファイル) の Azure スナップショットを一貫性のある状態で取得します。 一貫した Azure のスナップショットのセットは、バックアップを構成し、バックアップ ファイルに記録されます。 BACKUP DATABASE TO URL WITH FILE_SNAPSHOT と BACKUP LOG TO URL WITH FILE_SNAPSHOT の唯一の違いは、後者ではトランザクション ログの切り捨ても行うのに対して、前者では行わないことです。 SQL Server のスナップショット バックアップでは、バックアップ チェーンを確立するために SQL Server で必要な最初の完全バックアップの後、トランザクション ログ バックアップの時点にデータベースを復元する場合、単一のトランザクション ログ バックアップのみが必要になります。 さらに、次の 2 つのトランザクション ログ バックアップ期間の間の特定の時点にデータベースを復元するためには、2 つのトランザクション ログ バックアップのみが必要になります。

DIFFERENTIAL

BACKUP DATABASE のみで使用され、データベースまたはファイルのバックアップが、前回の完全バックアップ以降に変更されたデータベースまたはファイルの部分のみで構成されるように指定します。 通常、差分バックアップは、完全バックアップよりも使用領域が少なくてすみます。 前回の完全バックアップ以降に実行された各ログ バックアップをすべて適用する必要がない場合に、このオプションを使用します。

Note

既定では、BACKUP DATABASE は完全バックアップを作成します。

詳しくは、「差分バックアップ」をご覧ください。

ENCRYPTION

バックアップの暗号化を指定するために使用します。 バックアップを暗号化するための暗号化アルゴリズムを指定するか、バックアップを暗号化しない場合は NO_ENCRYPTION を指定できます。 暗号化は、バックアップ ファイルをセキュリティで保護するために推奨される方法です。 指定できるアルゴリズムの一覧を次に示します。

• AES_128
• AES_192
• AES_256
• TRIPLE_DES_3KEY
• NO_ENCRYPTION

暗号化することを選択した場合、次の暗号化機能のオプションを使用して、暗号化機能も指定する必要があります。

• SERVER CERTIFICATE = Encryptor_Name
• SERVER ASYMMETRIC KEY = Encryptor_Name

SERVER CERTIFICATE と SERVER ASYMMETRIC KEY は、master データベースで作成された証明書と非対称キーです。 詳細については、それぞれ「CREATE CERTIFICATE」と「CREATE ASYMMETRIC KEY」を参照してください。

警告

暗号化が FILE_SNAPSHOT 引数と組み合わせて使用されている場合、指定した暗号化アルゴリズムを使用して、メタデータ ファイル自体が暗号化され、システムはデータベースの Transparent Data Encryption (TDE) が完了したことを確認します。 データ自体に対しては、追加の暗号化は行われません。 データベースが暗号化されなかったか、バックアップ ステートメントが発行される前に暗号化が完了しなかった場合、バックアップは失敗します。

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

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

Note

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

COPY_ONLY

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

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

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

  重要

  DIFFERENTIAL と COPY_ONLY が一緒に使用されている場合、COPY_ONLY は無視され、差分バックアップが作成されます。

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

詳しくは、「コピーのみのバックアップ」をご覧ください。

[ COMPRESSION [ ALGORITHM = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

このバックアップでバックアップの圧縮を実行するかどうかを指定し、サーバー レベルの既定値をオーバーライドできます。

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

透過的なデータ暗号化 (TDE) が有効になっているデータベースでのバックアップの圧縮の使用については、「解説」セクションを参照してください。

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

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

SQL Server 2022 (16.x) では、操作の圧縮アルゴリズムを識別する ALGORITHM が導入されています。 既定では、 MS_XPRESSです。 統合アクセラレーションとオフロードを構成していれば、ソリューションによって提供されるアクセラレータを使用できます。 たとえば、SQL Server 用に Intel® QuickAssist Technology (QAT) を構成した場合次の例では、圧縮レベル 1 の QZ_DEFLATE を使用して QATzip ライブラリを使用して、アクセラレータ ソリューションを使用してバックアップを完了します。

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE) 

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 = 日付)
• 文字列データ型 (ntext または text データ型を除く) の変数
• smalldatetime
• datetime 変数

次に例を示します。

• 'Dec 31, 2020 11:59 PM'
• '1/1/2021'

datetime 値の指定方法については、「日付と時刻型」を参照してください。

Note

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

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

{ METADATA_ONLY | SNAPSHOT }

適用対象: SQL Server 2022 (16.x)

METADATA_ONLY と SNAPSHOT は同意語です。

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

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

{ NOINIT | INIT }

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

Note

{ NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、このトピックの後述の「解説」を参照してください。

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

詳しくは、「メディア セット、メディア ファミリ、およびバックアップ セット」をご覧ください。

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

• バックアップ セットがまだ期限切れではない。 詳細については、EXPIREDATE と RETAINDAYS のオプションを参照してください。
• BACKUP ステートメント内に示されたバックアップ セット名 (指定された場合) が、バックアップ メディア上の名前と一致していない。 詳細については、前の NAME オプションを参照してください。

これらのチェックをオーバーライドするには、SKIP オプションを使用します。

詳しくは、「メディア セット、メディア ファミリ、およびバックアップ セット」をご覧ください。

{ NOSKIP | SKIP }

バックアップ操作において、上書き前にメディア上のバックアップ セットの失効日時を確認するかどうかを制御します。

Note

{ 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 を指定する場合、バックアップ ボリュームに既に存在する、前回指定したメディア名と一致する必要があります。 指定しなかった場合場合、または SKIP オプションを指定した場合、メディア名の照合チェックは行われません。

BLOCKSIZE = { blocksize | @blocksize_variable }

物理ブロック サイズをバイト単位で指定します。 サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。 テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。 通常は、BACKUP によってデバイスに適したブロック サイズが自動的に選択されるので、このオプションは必要ありません。 ブロック サイズを明示的に指定すると、自動選択されたブロック サイズがオーバーライドされます。

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

Note

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

データ転送オプション

BUFFERCOUNT = { buffercount | @buffercount_variable }

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

バッファーで使用される領域の合計は、BUFFERCOUNT * MAXTRANSFERSIZE で決定されます。

Note

BUFFERCOUNT オプションの使用に関する重要な情報については、ブログ「Incorrect BufferCount data transfer option can lead to OOM condition」 (不適切な BufferCount データ転送オプションによって OOM の状態になる可能性がある) を参照してください。

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

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

SQL ライター サービスを使用してバックアップを作成する際に、データベースに FILESTREAM が構成されているか、メモリ最適化ファイル グループが含まれている場合、復元時の MAXTRANSFERSIZE はバックアップの作成時に使用された MAXTRANSFERSIZE 以上である必要があります。

単一のデータ ファイルを含む、透過的なデータ暗号化 (TDE) が有効になっているデータベースの場合、既定の MAXTRANSFERSIZE は 65536 (64 KB) です。 TDE で暗号化されていないデータベースでは、ディスクへのバックアップを使用する場合は既定の MAXTRANSFERSIZE が 1048576 (1 MB) となり、VDI または TAPE を使用する場合は 65536 (64 KB) となります。 TDE で暗号化されたデータベースでのバックアップの圧縮の使用の詳細については、「解説」セクションを参照してください。

エラー管理オプション

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

{ NO_CHECKSUM | CHECKSUM }

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

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

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

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

詳しくは、「バックアップ中および復元中に発生する可能性があるメディア エラー」をご覧ください。

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

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

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

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

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

詳しくは、「バックアップ中および復元中に発生する可能性があるメディア エラー」をご覧ください。

互換性オプション

RESTART

SQL Server 2008 (10.0.x) 以降では、無効です。 このオプションは、以前のバージョンの SQL Server との互換性を維持するために使用できます。

監視オプション

STATS [ = 時間 ]

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

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

テープ オプション

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

{ REWIND | NOREWIND }

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

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

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

Note

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

{ UNLOAD | NOUNLOAD }

Note

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

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

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

Note

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

ログ関係のオプション

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

Note

ログ バックアップを取得しない場合は、単純復旧モデルを使用します。 詳しくは、「復旧モデル」をご覧ください。

{ 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 バックアップの復元

Note

SQL Server でのバックアップの概要については、「バックアップの概要」をご覧ください。

バックアップの種類

サポートされるバックアップの種類は、次のようにデータベースの復旧モデルに依存します。

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

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

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

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

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

  Note

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

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

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

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

Note

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

バックアップ メディアの書式設定

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

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

バックアップ デバイスとメディア セットを操作する

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

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

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

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

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

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

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

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

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

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

BACKUP DATABASE AdventureWorks2022
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 句で指定する各バックアップ デバイスは、メディア ファミリに対応します。 たとえば、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 つのメディア ファミリは常に、特定のミラー内の同じデバイス上にバックアップされる必要があります。 したがって、既存のメディア セットを使用するときは毎回、メディア セットを作成したときに指定した同じ順序で各ミラーのデバイスを列挙してください。

ミラー化されたメディア セットの詳細については、「 Mirrored バックアップ メディア セットを参照してください。 メディア セットとメディア ファミリ全般の詳細については、「 メディア セット、メディア ファミリ、およびバックアップ セットを参照してください。

SQL Server バックアップを復元する

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

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

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

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

Note

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

スキップ オプション	NOINIT	INIT
NOSKIP	ボリュームに有効なメディア ヘッダーが含まれる場合は、MEDIANAME が指定されていれば、その値とメディア名が一致していることを確認します。 メディア名が一致した場合は、すべての既存のバックアップ セットはそのままにして、バックアップ セットを追加します。 ボリュームに有効なメディア ヘッダーが含まれない場合は、エラーが発生します。	ボリュームに有効なメディア ヘッダーが含まれている場合は、次のチェックを実行します。 MEDIANAME を指定した場合は、指定されているメディア名がメディア ヘッダーのメディア名と一致していることを確認します。1 メディア上に失効前のバックアップ セットが既に存在していないことを確認します。 存在している場合は、バックアップを中断します。 上のチェックにパスした場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。 ボリュームに有効なメディア ヘッダーが含まれない場合は、MEDIANAME および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。
SKIP	ボリュームに有効なメディア ヘッダーが含まれる場合は、すべての既存のバックアップ セットをそのまま保持して、バックアップ セットを追加します。	ボリュームに有効な2 メディア ヘッダーが含まれる場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。 メディアが空の場合は、MEDIANAME および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。

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

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

互換性

注意事項

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

BACKUP では、以前のバージョンの SQL Server との下位互換性を提供する RESTART オプションがサポートされています。 ただし、RESTART は無効です。

解説

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

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

次の状態でデータベースをバックアップできません。

• Restoring
• Standby
• 読み取り専用

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

SQL Server 2016 (13.x) 以降では、MAXTRANSFERSIZE を 65536 (64 KB) より大きい値に設定することにより、最初にページを復号化し、圧縮してから再度暗号化する、Transparent Data Encryption (TDE) で暗号化されたデータベースの最適化された圧縮アルゴリズムが有効になります。 MAXTRANSFERSIZE が指定されていない場合、または MAXTRANSFERSIZE = 65536 (64 KB) が使用される場合、TDE で暗号化されたデータベースでのバックアップの圧縮では暗号化されたページが直接圧縮され、適切な圧縮比率が得られない可能性があります。 詳細については、「Backup Compression for TDE-enabled Databases」 (TDE が有効になっているデータベースのバックアップの圧縮) を参照してください。

SQL Server 2019 (15.x) CU5 以降では、この最適化された圧縮アルゴリズムを TDE で有効にするために MAXTRANSFERSIZE を設定する必要がなくなりました。 バックアップ コマンドに WITH COMPRESSION が指定されている場合、または backup compression default サーバー構成が 1 に設定されている場合、最適化されたアルゴリズムを有効にするために、MAXTRANSFERSIZE は自動的に 128 K に増加されます。 バックアップ コマンドで値が 64 K >指定MAXTRANSFERSIZE場合は、指定された値が受け入れられます。 言い換えると、SQL Server では値が自動的に減少することはなく、値が増えるだけです。 MAXTRANSFERSIZE = 65536 で TDE で暗号化されたデータベースをバックアップする必要がある場合は、WITH NO_COMPRESSION を指定するか、backup compression default サーバー構成が 0 に設定されていることを確認する必要があります。

Note

次のように、既定の MAXTRANSFERSIZE が 64 K より大きくなる場合もあります。

• データベースに複数のデータ ファイルが作成されている場合、MAXTRANSFERSIZE> 64K が使用されます。
• Azure Blob Storage への URL へのバックアップを実行する場合、既定値 MAXTRANSFERSIZE = 1048576 (1 MB)。
• S3 互換オブジェクト ストレージへの URL へのバックアップを実行する場合、既定の MAXTRANSFERSIZE = 10485760 (10 MB)。

これらの条件のいずれかが当てはまる場合であっても、バックアップ コマンドで MAXTRANSFERSIZE に 64 K より大きい値を明示的に設定して、最適化されたバックアップ圧縮アルゴリズムを取得する必要があります (SQL Server 2019 (15.x) CU5 以降を使用している場合を除く)。

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

相互運用性

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

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

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

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

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

Metadata

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

• backupfile
• backupfilegroup
• backupmediafamily
• backupmediaset
• backupset

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

セキュリティ

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

アクセス許可

BACKUP DATABASE および BACKUP LOG アクセス許可は、既定では、sysadmin 固定サーバー ロール、db_owner 固定データベース ロール、および db_backupoperator 固定データベース ロールのメンバーに与えられます。

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

例

このセクションには、次の例が含まれています。

• A. データベース全体をバックアップする
• B. データベースとログをバックアップする
• C: セカンダリ ファイル グループの完全なファイル バックアップを作成する
• D. セカンダリ ファイル グループの差分ファイル バックアップを作成する
• E. 単一ファミリ のミラー化されたメディア セットを作成してバックアップする
• F. 複数のミラー化されたメディア セットを作成してバックアップする
• G. 既存のミラー化メディア セットにバックアップする
• H. 新しいメディア セットに圧縮バックアップを作成する
• I. Azure Blob Storage へのバックアップ
• J. [S3 互換オブジェクト ストレージへのバックアップ]((#j-backing-up-to-s3-compatible-object-storage)
• K. バックアップ ステートメントの進行状況を追跡する

Note

バックアップ方法に関するトピックには、他にも例が記載されています。 詳しくは、「バックアップの概要」をご覧ください。

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

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

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

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

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

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

Note

運用データベースでは、ログを定期的にバックアップしてください。 ログのバックアップは、データ損失から万全に保護できるように頻繁に行ってください。

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

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

F. 複数のミラー化されたメディア セットを作成してバックアップする

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

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

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

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

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

Note

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

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

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

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

I. Microsoft Azure Blob Storage へのバックアップ

この例では、azure Blob Storage への Sales のデータベースの完全バックアップを実行します。 ストレージ アカウント名は mystorageaccountです。 コンテナーは myfirstcontainerと呼ばれます。 保存されているアクセス ポリシーは、既に読み取り、書き込み、削除、およびリスト権限で作成されています。 SQL Server 資格情報 https://mystorageaccount.blob.core.windows.net/myfirstcontainer は、保存されたアクセス ポリシーに関連付けられている Shared Access Signature を使用して作成されています。 Azure Blob Storage への SQL Server バックアップの詳細については、「SQL Server Backup and Restore with Azure Blob Storageおよび SQL Server Backup to URLを参照してください。

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales.bak'
WITH STATS = 5;

データベースを複数のストライプにバックアップすることもできます。これは次のようになります。

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

J. S3 互換オブジェクト ストレージへのバックアップ

適用対象: SQL Server 2022 (16.x)

この例では、S3 互換オブジェクト ストレージ プラットフォームへの Sales データベースの完全バックアップ データベースを実行します。 資格情報の名前は、ステートメントでは必要ありません。または正確な URL パスと一致する必要はありませんが、指定された URL で適切な資格情報の検索が実行されます。 詳細については、「S3 互換オブジェクト ストレージを使用した SQL Server のバックアップと復元」を参照してください。

BACKUP DATABASE Sales
TO      URL = 's3://10.10.10.10:8787/sqls3backups/sales_01.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_02.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_03.bak'
WITH    FORMAT
,       STATS               = 10
,       COMPRESSION;

K. バックアップ ステートメントの進行状況を追跡する

次のクエリでは、現在実行中のバックアップ ステートメントに関する情報が返されます。

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command LIKE 'BACKUP%';

関連するコンテンツ

• バックアップ デバイス
• メディア セット、メディア ファミリ、およびバックアップ セット
• ログ末尾のバックアップ
• ALTER DATABASE
• DBCC SQLPERF
• RESTORE
• RESTORE FILELISTONLY
• RESTORE HEADERONLY
• RESTORE LABELONLY
• RESTORE VERIFYONLY
• sp_addumpdevice
• sp_configure
• sp_helpfile
• sp_helpfilegroup
• サーバー構成オプション
• メモリ最適化テーブルを持つデータベースの段階的な部分復元