BACKUP (Transact-SQL)
SQL Database をバックアップします。
次の行で、興味のある製品の名前を選択すると、その製品の情報のみが表示されます。
構文表記規則の詳細については、「Transact-SQL 構文表記規則」を参照してください。
* 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
データベース全体のバックアップを指定します。 ファイルとファイル グループのリストを指定した場合、指定したファイルとファイル グループだけがバックアップされます。 データベース全体のバックアップまたは差分バックアップ中、SQL Server では、バックアップが復元された場合に一貫性のあるデータベースを生成するのに十分なトランザクション ログをバックアップします。
BACKUP DATABASE (データ バックアップ) で作成されたバックアップを復元すると、バックアップ全体が復元されます。 バックアップ内の特定の時点またはトランザクションに復元できるのは、ログ バックアップだけです。
注意
master
データベース上では、データベース全体のバックアップのみが可能です。
トランザクション ログのみのバックアップを指定します。 前回正しく実行されたログ バックアップの位置から、ログの現在の末尾まで、ログのバックアップが行われます。 最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。
RESTORE LOG ステートメントで WITH STOPAT
、STOPATMARK
、または STOPBEFOREMARK
を指定して、バックアップ内の特定の時間またはトランザクションにログ バックアップを復元できます。
注意
WITH NO_TRUNCATE
または COPY_ONLY
を指定した場合を除き、一般的なログ バックアップの後、一部のトランザクション ログ レコードが非アクティブになります。 1 つ以上の仮想ログ ファイル内ですべてのレコードがアクティブでなくなった場合、ログは切り捨てられます。 定期的なログ バックアップの後にログが切り捨てられていない場合は、何らかの原因によりログの切り捨てが遅れている可能性があります。 詳細については、「ログの切り捨てが遅れる原因となる要因」を参照してください。
SQL Server 2022 (16.x) で導入されています。
データベースのグループをバックアップします。 スナップショット バックアップを使用します。 WITH METADATA_ONLY が必要です。 「Transact-SQL スナップショット バックアップを作成する」を参照してください。
SQL Server 2022 (16.x) で導入されています。
SQL Server のインスタンス上のすべてのデータベースをバックアップします。 スナップショット バックアップを使用します。 WITH METADATA_ONLY が必要です。 「Transact-SQL スナップショット バックアップを作成する」を参照してください。
SQL Server 2022 (16.x) で導入されています。
スナップショット バックアップに必須です。 BACKUP SERVER
または BACKUP GROUP...
「Transact-SQL スナップショット バックアップを作成する」を参照してください。
METADATA_ONLY は SNAPSHOT と同義です。 仮想デバイス インターフェイス (VDI) では SNAPSHOT が使用されます。 VDI の詳細については、「仮想デバイス インターフェイス (VDI) リファレンス」を参照してください。
トランザクション ログ、データベースの一部、またはデータベース全体をバックアップする場合の、バックアップ元となるデータベースを指定します。 変数 (@database_name_var) として指定する場合、この名前は、文字列定数 (@database_name_var=database name) として、または ntext や text データ型を除く、文字の文字列データ型の変数として指定できます。
注意
データベース ミラーリング パートナーシップ内のミラー データベースは、バックアップできません。
BACKUP DATABASE でのみ使用できます。ファイル バックアップに含めるデータベース ファイルまたはファイル グループを指定するか、部分バックアップに含める読み取り専用ファイルまたはファイル グループを指定します。
バックアップに含めるファイルの論理名、またはこの論理名を値として保持する変数を指定します。
バックアップに含めるファイルグループの論理名、またはファイルグループの論理名を値として保持する変数です。 単純復旧モデルでは、ファイル グループのバックアップは、読み取り専用のファイル グループに対してのみ使用できます。
注意
データベースのサイズおよびパフォーマンス要件によりデータベース バックアップの実行が難しい場合は、ファイル バックアップの利用を検討してください。 NUL デバイスはバックアップのパフォーマンスをテストするために使用できますが、運用環境では使用できません。
n
複数のファイルおよびファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダーです。 数の制限はありません。
詳しくは、「ファイルの完全バックアップ」および「ファイルおよびファイル グループのバックアップ」をご覧ください。
READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]
部分バックアップを指定します。 部分バックアップには、データベース内のすべての読み取り/書き込みファイル (プライマリ ファイル グループ、存在する場合は読み取り/書き込みセカンダリ ファイル グループ、および指定の読み取り専用ファイルまたはファイル グループ) が含まれます。
部分バックアップで、すべての読み取り/書き込みファイル グループをバックアップすることを指定します。 データベースが読み取り専用の場合、READ_WRITE_FILEGROUPS にはプライマリ ファイル グループのみが含まれます。
重要
READ_WRITE_FILEGROUPS の代わりに FILEGROUP を使用して、読み取り/書き込みファイル グループのリストを明示的に指定すると、ファイル バックアップが作成されます。
部分バックアップに含める読み取り専用ファイルグループの論理名、または読み取り専用ファイルグループの論理名を値として保持する変数です。 詳細については、このトピックの前述の "<file_or_filegroup>" を参照してください。
n
複数の読み取り専用ファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダーです。
部分バックアップについて詳しくは、「部分バックアップ」をご覧ください。
関連するバックアップ デバイスのセットが、ミラー化されていないメディア セット、またはミラー化メディア セット内にあるミラーの 1 つ目 (1 つ以上の MIRROR TO 句が宣言されている場合) であることを示します。
<backup_device>
バックアップ操作に使用する論理または物理バックアップ デバイスを指定します。
適用対象: SQL Server
データベースのバックアップが作成されるバックアップ デバイスの論理名です。 論理名は、識別子のルールに従う必要があります。 変数 (@logical_device_name_var) として指定する場合、バックアップ デバイス名は、文字列定数 (@logical_device_name_var= logical backup device name) として、または ntext や text データ型を除く、文字列データ型の変数として指定できます。
適用対象: 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 バックアップのオプションも確認してください。
注意
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 オプションが指定されていない場合、バックアップはデバイスに追加されます。
注意
NUL デバイスはこのファイルに送信されるすべての入力を破棄しますが、バックアップでは引き続きすべてのページがバックアップ済みとしてマークされます。
詳しくは、「バックアップ デバイス」をご覧ください。
注意
TAPE オプションは将来のバージョンの SQL Server では削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。
n
コンマ区切りリストに最大 64 個のバックアップ デバイスが指定される可能性があることを示すプレースホルダーです。
TO 句で指定したバックアップ デバイスをミラー化する、最大 3 つまでのセカンダリ バックアップ デバイスのセットを指定します。 MIRROR TO 句には、TO 句で指定した同じ種類と数のバックアップ デバイスを指定する必要があります。 MIRROR TO 句の最大数は 3 です。
このオプションは、SQL Server の Enterprise Edition でのみ使用できます。
注意
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 句を含めることができることを示すプレースホルダーです。
バックアップ操作で使用するオプションを指定します。
適用対象: SQL Server (SQL Server 2012 (11.x) SP1 CU2 以降)。
Azure Blob Storage へのバックアップを作成する場合にのみ使用されます。
適用対象: 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 つのトランザクション ログ バックアップのみが必要になります。
BACKUP DATABASE のみで使用され、データベースまたはファイルのバックアップが、前回の完全バックアップ以降に変更されたデータベースまたはファイルの部分のみで構成されるように指定します。 通常、差分バックアップは、完全バックアップよりも使用領域が少なくてすみます。 前回の完全バックアップ以降に実行された各ログ バックアップをすべて適用する必要がない場合に、このオプションを使用します。
注意
既定では、BACKUP DATABASE
は完全バックアップを作成します。
詳しくは、「差分バックアップ」をご覧ください。
バックアップの暗号化を指定するために使用します。 バックアップを暗号化するための暗号化アルゴリズムを指定するか、バックアップを暗号化しない場合は NO_ENCRYPTION
を指定できます。 暗号化は、バックアップ ファイルをセキュリティで保護するために推奨される方法です。 指定できるアルゴリズムの一覧を次に示します。
AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION
暗号化することを選択した場合、次の暗号化機能のオプションを使用して、暗号化機能も指定する必要があります。
SERVER CERTIFICATE
= Encryptor_NameSERVER ASYMMETRIC KEY
= Encryptor_Name
SERVER CERTIFICATE
と SERVER ASYMMETRIC KEY
は、master
データベースで作成された証明書と非対称キーです。 詳細については、それぞれ「CREATE CERTIFICATE
」と「CREATE ASYMMETRIC KEY
」を参照してください。
警告
暗号化が FILE_SNAPSHOT
引数と組み合わせて使用されている場合、指定した暗号化アルゴリズムを使用して、メタデータ ファイル自体が暗号化され、システムはデータベースの Transparent Data Encryption (TDE) が完了したことを確認します。 データ自体に対しては、追加の暗号化は行われません。 データベースが暗号化されなかったか、バックアップ ステートメントが発行される前に暗号化が完了しなかった場合、バックアップは失敗します。
以下のオプションは、このバックアップ操作で作成されるバックアップ セットに対して有効なオプションです。
注意
復元操作用のバックアップ セットを指定するには、FILE = <backup_set_file_number>
オプションを使用します。 バックアップ セットを指定する方法について詳しくは、「RESTORE の引数」の「バックアップ セットの指定」をご覧ください。
バックアップが、通常のバックアップの順序には影響しない、コピーのみのバックアップであることを指定します。 コピーのみのバックアップは、定期的に行われる従来のバックアップとは別に作成されます。 コピーのみのバックアップは、データベースの全体的なバックアップと復元の手順に影響しません。
コピーのみのバックアップは、オンラインでファイルを復元する前にログをバックアップするなど、特殊な目的でバックアップを作成する場合にのみ使用してください。 通常、コピーのみのログ バックアップは 1 回だけ使用され、その後は削除されます。
BACKUP DATABASE
で使用した場合、COPY_ONLY
オプションでは、差分ベースとして使用できない完全バックアップが作成されます。 差分ビットマップは更新されず、後に実行する差分バックアップではコピーのみのバックアップは無視され、 従来のバックアップで作成された最新の完全バックアップがベースとして使用されます。重要
DIFFERENTIAL
とCOPY_ONLY
が一緒に使用されている場合、COPY_ONLY
は無視され、差分バックアップが作成されます。BACKUP LOG
で使用した場合、COPY_ONLY
オプションではコピーのみのログ バックアップが作成され、トランザクション ログは切り捨てられません。 コピーのみのログ バックアップは、ログ チェーンに影響を及ぼさず、他のログ バックアップはコピーのみのバックアップが存在しない場合と同様に動作します。
詳しくは、「コピーのみのバックアップ」をご覧ください。
このバックアップでバックアップの圧縮を実行するかどうかを指定し、サーバー レベルの既定値をオーバーライドできます。
インストール時の既定の動作では、バックアップの圧縮は行われません。 ただし、この既定の動作は、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)
バックアップ セットを記述したテキストを自由な形式で指定します。 文字列の長さは最大 255 文字です。
バックアップ セットの名前を指定します。 名前の長さは最大 128 文字です。 NAME を指定しないと、名前は空白になります。
このバックアップのバックアップ セットがいつ上書きできるようになるかを指定します。 これらのオプションを両方とも使用した場合は、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 値の指定方法については、「日付と時刻型」を参照してください。
注意
失効日を無視するには、SKIP
オプションを使用します。
RETAINDAYS = { days | @days_var }
このバックアップ メディア セットに上書きできるようになるまでの経過日数を指定します。 変数 (@days_var) として指定する場合は、整数で指定する必要があります。
適用対象: SQL Server 2022 (16.x)
METADATA_ONLY と SNAPSHOT は同意語です。
以下のオプションは、メディア セット全般に適用されます。
バックアップ操作で、バックアップ メディア上の既存のバックアップ セットに追加するか、上書きするかを制御します。 既定では、メディア上の最新のバックアップ セットに追加します (NOINIT)。
注意
{ NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、このトピックの後述の「解説」を参照してください。
NOINIT
既存のバックアップ セットを維持したまま、バックアップ セットが指定のメディア セットに追加されることを示します。 メディア セットのメディア パスワードが定義されている場合は、パスワードを指定する必要があります。 NOINIT が既定値です。
詳しくは、「メディア セット、メディア ファミリ、およびバックアップ セット」をご覧ください。
INIT
すべてのバックアップ セットが上書きされるように指定します。ただし、メディア ヘッダーは維持されます。 INIT が指定された場合、条件が満たされていれば、そのデバイス上にある既存のすべてのバックアップ セットが上書きされます。 既定では、BACKUP によって次の状況が確認され、いずれかの状況に該当する場合はバックアップ メディアは上書きされません。
- バックアップ セットがまだ期限切れではない。 詳細については、
EXPIREDATE
とRETAINDAYS
のオプションを参照してください。 - BACKUP ステートメント内に示されたバックアップ セット名 (指定された場合) が、バックアップ メディア上の名前と一致していない。 詳細については、前の NAME オプションを参照してください。
これらのチェックをオーバーライドするには、SKIP
オプションを使用します。
詳しくは、「メディア セット、メディア ファミリ、およびバックアップ セット」をご覧ください。
バックアップ操作において、上書き前にメディア上のバックアップ セットの失効日時を確認するかどうかを制御します。
注意
{ NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、このトピックの後述の「解説」を参照してください。
NOSKIP
上書きを許可する前に、メディア上のすべてのバックアップ セットの失効日を確認することを BACKUP ステートメントに指示します。 これは既定の動作です。
SKIP
バックアップ セットの有効期限と名前の確認を無効にします。この確認は、通常、バックアップ セットの上書きを防止するために BACKUP ステートメントによって実行されます。 { INIT | NOINIT } と { NOSKIP | SKIP } の相関関係については、この記事で後述する「解説」を参照してください。
バックアップ セットの失効日を表示するには、backupset 履歴テーブルの expiration_date 列をクエリします。
このバックアップ操作に使用するボリューム上にメディア ヘッダーを書き込み、既存のメディア ヘッダーとバックアップ セットを上書きするかどうかを指定します。
NOFORMAT
バックアップ操作において、このバックアップ操作に使用するメディア ボリューム上の既存のメディア ヘッダーとバックアップ セットを保持するように指定します。 これは既定の動作です。
FORMAT
新しいメディア セットを作成するよう指定します。 FORMAT が指定されると、バックアップ操作において、バックアップ操作に使用されるすべてのメディア ボリューム上に、新しいメディア ヘッダーを書き込みます。 既存のメディア ヘッダーとバックアップ セットが上書きされるので、そのボリュームの既存のコンテンツは無効になります。
重要
FORMAT
は注意して使用してください。 メディア セットに属するボリュームを 1 つでも初期化すると、メディア セット全体が使用できなくなります。 たとえば、既存のストライプ メディア セットに属するテープを 1 つ初期化すると、メディア セット全体が使用できなくなります。
FORMAT を指定することは SKIP
を実行することを意味します。SKIP
を明示的に指定する必要はありません。
メディア セットを説明した自由形式のテキストを最大 255 文字で指定します。
バックアップ メディア セット全体のメディア名を指定します。 メディア名は 128 文字以内にする必要があります。 MEDIANAME
を指定する場合、バックアップ ボリュームに既に存在する、前回指定したメディア名と一致する必要があります。 指定しなかった場合場合、または SKIP オプションを指定した場合、メディア名の照合チェックは行われません。
物理ブロック サイズをバイト単位で指定します。 サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。 テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。 通常は、BACKUP によってデバイスに適したブロック サイズが自動的に選択されるので、このオプションは必要ありません。 ブロック サイズを明示的に指定すると、自動選択されたブロック サイズがオーバーライドされます。
バックアップを作成して CD-ROM に格納したり、CD-ROM からバックアップを復元する場合は、BLOCKSIZE=2048 と指定します。
注意
このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。
バックアップ操作に使用される I/O バッファーの総数を指定します。 任意の正の整数を指定できますが、バッファー数が多いと Sqlservr.exe プロセス内で仮想アドレス空間が不足し、"メモリ不足" エラーが発生する場合があります。
バッファーで使用される領域の合計は、BUFFERCOUNT * MAXTRANSFERSIZE
で決定されます。
注意
BUFFERCOUNT
オプションの使用に関する重要な情報については、ブログ「Incorrect BufferCount data transfer option can lead to OOM condition」 (不適切な BufferCount データ転送オプションによって OOM の状態になる可能性がある) を参照してください。
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
有効かつ使用可能であれば、バックアップ操作で各ページのチェックサムおよび破損ページを検証し、バックアップ全体のチェックサムを生成するように指定します。
バックアップ チェックサムを使用すると、ワークロードとバックアップのスループットに影響する可能性があります。
詳しくは、「バックアップ中および復元中に発生する可能性があるメディア エラー」をご覧ください。
ページ チェックサム エラーの発生時、バックアップ操作を停止するか続行するかを制御します。
STOP_ON_ERROR
ページ チェックサムが正しくない場合、BACKUP を失敗させます。 これは既定の動作です。
CONTINUE_AFTER_ERROR
無効なチェックサム、ページの破損などのエラーが検出されても、BACKUP を継続します。
データベースが破損したときに、NO_TRUNCATE オプションを使用してもログの末尾をバックアップできない場合は、NO_TRUNCATE の代わりに CONTINUE_AFTER_ERROR を指定してログ末尾のバックアップを試すことができます。
詳しくは、「バックアップ中および復元中に発生する可能性があるメディア エラー」をご覧ください。
SQL Server 2008 (10.0.x) 以降では、無効です。 このオプションは、以前のバージョンの SQL Server との互換性を維持するために使用できます。
指定した percentage が完了するたびにメッセージを表示します。進行状況を判断する場合に使用できます。 percentage を省略した場合、SQL Server では 10% 完了するごとにメッセージが表示されます。
STATS オプションでは、次のパーセンテージ間隔を報告するしきい値に達した時点までに、完了したパーセンテージを報告します。 これは、ほぼ指定したパーセンテージになります。たとえば、STATS=10 とすると、40% が完了した場合に、オプションでは 43% と表示されることがあります。 大規模なバックアップ セットの場合は、完了した I/O 呼び出し間での完了パーセンテージの変化が非常に遅くなるため、これは重要な問題にはなりません。
このオプションはテープ デバイスにのみ適用されます。 テープ以外のデバイスが使用される場合、このオプションは無視されます。
REWIND
SQL Server でテープを解放して巻き戻すように指定します。 既定値は REWIND です。
NOREWIND
SQL Server でバックアップ操作後にテープを開いたままにしておくことを指定します。 このオプションを使用すると、1 つのテープに対して複数のバックアップ操作を実行する場合のパフォーマンスを向上させることが可能です。
NOREWIND は暗黙的に NOUNLOAD も意味しており、これらのオプションを 1 つの BACKUP ステートメント内で同時に使用することはできません。
注意
NOREWIND
を使用する場合、テープ ドライブの所有権は SQL Server インスタンスによって保持されます。同じプロセス内で実行される BACKUP または RESTORE ステートメントで REWIND
または UNLOAD
オプションが使用されるか、サーバー インスタンスがシャットダウンすると、所有権は解放されます。 テープを開いたままにすると、他のプロセスではそのテープにアクセスできません。 開いているテープの一覧を表示する方法、および開いているテープを閉じる方法については、「バックアップ デバイス」をご覧ください。
注意
UNLOAD
および NOUNLOAD
はセッションの設定であり、セッションが終了するまで、または代わりとなるオプションの指定によりリセットされるまで有効です。
UNLOAD
バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行います。 UNLOAD は、セッション開始時の既定値です。
NOUNLOAD
BACKUP 操作の後、テープ ドライブにテープを読み込んだままにすることを指定します。
注意
テープ バックアップ デバイスへのバックアップの場合、BLOCKSIZE
オプションはバックアップ操作のパフォーマンスに影響します。 このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。
以下のオプションは、BACKUP LOG
でのみ使用します。
注意
ログ バックアップを取得しない場合は、単純復旧モデルを使用します。 詳しくは、「復旧モデル」をご覧ください。
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
で実行されるバックアップに不完全なメタデータが含まれる場合があります。 このオプションを使用すると、データベースが破損している場合でもトランザクション ログをバックアップできます。
BACKUP LOG の NO_TRUNCATE オプションを指定すると、COPY_ONLY と CONTINUE_AFTER_ERROR の両方を指定する場合と同じ結果が得られます。
NO_TRUNCATE
オプションを使用しない場合は、データベースが ONLINE 状態である必要があります。 データベースが SUSPENDED 状態の場合は、NO_TRUNCATE
を指定することによってバックアップを作成できる可能性があります。 ただし、データベースが OFFLINE または EMERGENCY 状態の場合、NO_TRUNCATE
を使用しても BACKUP は使用できません。 データベースの状態については、「データベースの状態」を参照してください。
このセクションでは、次の基本的なバックアップの概念について説明します。
バックアップの種類トランザクション ログの切り捨てバックアップ メディアのフォーマットバックアップ デバイスとメディア セットの操作SQL Server バックアップの復元
注意
SQL Server でのバックアップの概要については、「バックアップの概要」をご覧ください。
サポートされるバックアップの種類は、次のようにデータベースの復旧モデルに依存します。
データの完全バックアップと差分バックアップはすべての復旧モデルで実行できます。
バックアップの範囲 バックアップの種類 データベース全体 データベース バックアップでは、データベース全体が対象となります。
必要に応じて、各データベース バックアップは、1 つ以上のデータベースの差分バックアップのベースとして使用することもできます。データベースの部分バックアップ 部分バックアップでは、読み取り/書き込みファイル グループ、および必要な場合は 1 つ以上の読み取り専用ファイルまたはファイル グループが対象となります。
必要に応じて、各部分バックアップは、1 つ以上の部分的な差分バックアップのベースとして使用することもできます。ファイルまたはファイル グループ ファイル バックアップでは、1 つ以上のファイルまたはファイル グループが対象となります。このバックアップは、複数のファイル グループを含むデータベースにのみ関連します。 単純復旧モデルでは、ファイル バックアップは基本的に、読み取り専用のセカンダリ ファイル グループに限定されます。
必要に応じて、各ファイル バックアップは、1 つ以上のファイルの差分バックアップのベースとして使用することもできます。完全復旧モデルまたは一括ログ復旧モデルでは、従来のバックアップの必須作業として、シーケンシャル トランザクション ログ バックアップ (またはログ バックアップ) も含まれます。 各ログ バックアップでは、トランザクション ログのうち、バックアップが作成された時点でアクティブだった部分と、前回のログ バックアップにおいてバックアップされなかったすべてのログ レコードが対象となります。
作業損失の可能性を最小に抑えるには、管理のオーバーヘッドが発生しても、ログ バックアップを頻繁に行うようにスケジュールする必要があります。 完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。
ログ バックアップは、データベースのバックアップとは別のボリュームに配置することをお勧めします。
注意
最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。
コピーのみのバックアップは、従来のバックアップで行われる一連の作業とは別に、特別な目的で行われる完全バックアップまたはログ バックアップです。 コピーのみのバックアップを作成するには、BACKUP ステートメント内で COPY_ONLY オプションを指定します。 詳しくは、「コピーのみのバックアップ」をご覧ください。
データベースのトランザクション ログがいっぱいにならないように、トランザクション ログを定期的にバックアップする必要があります。 ログの切り捨ては、単純復旧モデルではデータベースのバックアップ後に、完全復旧モデルではトランザクション ログのバックアップ後に、自動的に行われます。 ただし、切り捨ての処理が遅れる場合もあります。 ログの切り捨てが遅れる要因については、「トランザクション ログ」をご覧ください。
注意
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 バックアップ メディア セットを参照してください。 メディア セットとメディア ファミリ全般の詳細については、「 メディア セット、メディア ファミリ、およびバックアップ セットを参照してください。
データベースを復元し、必要に応じて、そのデータベースを復旧してオンラインにする、またはファイルやファイル グループを復元するには、Transact-SQL の RESTORE ステートメントを使用するか、SQL Server Management Studio の復元タスクを使用します。 詳しくは、「復元と復旧の概要」をご覧ください。
次の表に、{ NOINIT | INIT } と { NOSKIP | SKIP } オプションの相関関係を示します。
注意
テープ メディアが空の場合、またはディスクのバックアップ ファイルが存在しない場合は、これらすべての相関関係によってメディア ヘッダーが記述され、続行されます。 ただし、メディアが空でなく、有効なメディア ヘッダーがない場合、これらの操作によって、有効な MTF メディアでないことを示すフィードバックが返され、バックアップ操作が中断されます。
スキップ オプション | NOINIT | INIT |
---|---|---|
NOSKIP | ボリュームに有効なメディア ヘッダーが含まれる場合は、MEDIANAME が指定されていれば、その値とメディア名が一致していることを確認します。 メディア名が一致した場合は、すべての既存のバックアップ セットはそのままにして、バックアップ セットを追加します。ボリュームに有効なメディア ヘッダーが含まれない場合は、エラーが発生します。 |
ボリュームに有効なメディア ヘッダーが含まれている場合は、次のチェックを実行します。
上のチェックにパスした場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。 ボリュームに有効なメディア ヘッダーが含まれない場合は、 MEDIANAME および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。 |
SKIP | ボリュームに有効なメディア ヘッダーが含まれる場合は、すべての既存のバックアップ セットをそのまま保持して、バックアップ セットを追加します。 | ボリュームに有効な2 メディア ヘッダーが含まれる場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。 メディアが空の場合は、 MEDIANAME および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。 |
1 ユーザーは、バックアップ操作を実行する適切な固定データベースまたはサーバー ロールに属している必要があります。
2 有効性には、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 に設定されていることを確認する必要があります。
注意
次のように、既定の 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 番目の操作は実行されません。
SQL Server には次のようなバックアップ履歴テーブルがあり、これによってバックアップ処理が追跡されます。
復元を実行するときに、バックアップ セットが 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. バックアップ ステートメントの進行状況を追跡する
注意
バックアップ方法に関するトピックには、他にも例が記載されています。 詳しくは、「バックアップの概要」をご覧ください。
次の例では、AdventureWorks2022
データベースをディスク ファイルにバックアップします。
BACKUP DATABASE AdventureWorks2022
TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
WITH FORMAT;
GO
次の例では、既定により単純復旧モデルを使用する 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
注意
運用データベースでは、ログを定期的にバックアップしてください。 ログのバックアップは、データ損失から万全に保護できるように頻繁に行ってください。
次の例では、両方のセカンダリ ファイル グループ内のすべてのファイルについて、完全ファイル バックアップを作成します。
--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
FILEGROUP = 'SalesGroup1',
FILEGROUP = 'SalesGroup2'
TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck';
GO
次の例では、両方のセカンダリ ファイル グループ内のすべてのファイルについて、差分ファイル バックアップを作成します。
--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
FILEGROUP = 'SalesGroup1',
FILEGROUP = 'SalesGroup2'
TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
WITH
DIFFERENTIAL;
GO
次の例では、単一メディア ファミリと 4 つのミラーを含むミラー化メディア セットを作成し、そこに AdventureWorks2022
データベースのバックアップを作成します。
BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorksSet0';
次の例では、各ミラーが 2 つのメディア ファミリで構成されているミラー化メディア セットを作成します。 その後、両方のミラーに AdventureWorks2022
データベースのバックアップが作成されます。
BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorksSet1';
次の例では、前の例で作成されたメディア セットにバックアップ セットを追加します。
BACKUP LOG AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
NOINIT,
MEDIANAME = 'AdventureWorksSet1';
注意
NOINIT は既定値ですが、ここではわかりやすくするために記載しています。
次の例では、メディアをフォーマットして新しいメディア セットを作成し、AdventureWorks2022
データベースの圧縮された完全バックアップを実行します。
BACKUP DATABASE AdventureWorks2022 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
FORMAT,
COMPRESSION;
この例では、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および
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;
適用対象: 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;
次のクエリでは、現在実行中のバックアップ ステートメントに関する情報が返されます。
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%';
* SQL Managed Instance *
Azure SQL Managed Instance 内の SQL データベースのバックアップ Azure SQL Managed Instance には自動バックアップがあります。 データベース COPY_ONLY
の完全バックアップを作成できます。 差分、ログ、およびファイル スナップショットのバックアップはサポートされていません。
また、Azure Arc で有効になっている SQL Managed Instance にも適用されます。
BACKUP DATABASE { database_name | @database_name_var }
TO URL = { 'physical_device_name' | @physical_device_name_var }[ ,...n ]
WITH COPY_ONLY [, { <general_WITH_options> } ]
[;]
<general_WITH_options> [ ,...n ]::=
--Media Set Options
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 ]
--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
データベース全体のバックアップを指定します。 データベースのバックアップ時、Azure SQL Managed Instance では、バックアップが復元された場合に一貫性のあるデータベースを生成するのに十分なトランザクション ログをバックアップします。
重要
マネージド インスタンスで作成されたデータベース バックアップは、別の Azure SQL Managed Instance か SQL Server 2022 インスタンスにのみ復元できます。 これは、SQL Server の他のバージョンと比べて、SQL Managed Instance の内部データベース バージョンが高いためです。 詳細については、SQL Managed Instance データベース バックアップの SQL Server 2022 への復元に関するページを参照してください。
BACKUP DATABASE (データ バックアップ) で作成されたバックアップを復元すると、バックアップ全体が復元されます。 SQL Managed Instance の自動バックアップから復元するには、Azure SQL Managed Instance へのデータベースの復元に関するページを参照してください。
データベース全体のバックアップ元となるデータベースです。 変数 (@database_name_var) として指定する場合、この名前は、文字列定数 (@database_name_var=database name) として、または ntext や text データ型を除く、文字の文字列データ型の変数として指定できます。
詳しくは、「ファイルの完全バックアップ」および「ファイルおよびファイル グループのバックアップ」をご覧ください。
バックアップ操作に使用する URL を指定します。 URL の形式は、Microsoft Azure ストレージ サービスへのバックアップを作成するために使用されます。
重要
URL へのバックアップ時に複数のデバイスにバックアップするには、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 資格情報の作成の簡素化) を参照してください。
n
コンマ区切りリストに最大 64 個のバックアップ デバイスが指定される可能性があることを示すプレースホルダーです。
バックアップ操作で使用するオプションを指定します。
バックアップの暗号化を指定するために使用します。 バックアップを暗号化するための暗号化アルゴリズムを指定するか、バックアップを暗号化しない場合は NO_ENCRYPTION
を指定できます。 暗号化は、バックアップ ファイルをセキュリティで保護するために推奨される方法です。 指定できるアルゴリズムの一覧を次に示します。
AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION
暗号化することを選択した場合、次の暗号化機能のオプションを使用して、暗号化機能も指定する必要があります。
SERVER CERTIFICATE = <Encryptor_Name>
SERVER ASYMMETRIC KEY = <Encryptor_Name>
バックアップが、通常のバックアップの順序には影響しない、コピーのみのバックアップであることを指定します。 コピーのみのバックアップは、Azure SQL Database の自動バックアップとは関係なく作成されます。 詳しくは、「コピーのみのバックアップ」をご覧ください。
このバックアップでバックアップの圧縮を実行するかどうかを指定し、サーバー レベルの既定値をオーバーライドできます。
既定の動作では、バックアップの圧縮は行われません。 ただし、この既定の動作は、backup compression default サーバー構成オプションを設定することで変更できます。 このオプションの現在の値の表示については、「サーバー プロパティの表示または変更」をご覧ください。
COMPRESSION
バックアップの圧縮を明示的に有効にします。
NO_COMPRESSION
バックアップの圧縮を明示的に無効にします。
バックアップ セットを記述したテキストを自由な形式で指定します。 文字列の長さは最大 255 文字です。
バックアップ セットの名前を指定します。 名前の長さは最大 128 文字です。 NAME を指定しないと、名前は空白になります。
メディア セットを説明した自由形式のテキストを最大 255 文字で指定します。
バックアップ メディア セット全体のメディア名を指定します。 メディア名は最長 128 文字まで入力できます。MEDIANAME
を指定する場合、バックアップ ボリュームに既に存在する、前回指定したメディア名と一致する必要があります。 指定しなかった場合場合、または SKIP オプションを指定した場合、メディア名の照合チェックは行われません。
物理ブロック サイズをバイト単位で指定します。 サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。 テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。 通常は、BACKUP によってデバイスに適したブロック サイズが自動的に選択されるので、このオプションは必要ありません。 ブロック サイズを明示的に指定すると、自動選択されたブロック サイズがオーバーライドされます。
バックアップ操作に使用される I/O バッファーの総数を指定します。 任意の正の整数を指定できますが、バッファー数が多いと Sqlservr.exe プロセス内で仮想アドレス空間が不足し、"メモリ不足" エラーが発生する場合があります。
バッファーで使用される領域の合計は、BUFFERCOUNT * MAXTRANSFERSIZE
で決定されます。
注意
BUFFERCOUNT
オプションの使用に関する重要な情報については、ブログ記事Incorrect BufferCount データ転送オプションが OOM 条件につながる可能性がありますを参照してください。
SQL Server とバックアップ メディアの間で使用される最大転送単位をバイト単位で指定します。 有効値は 65536 バイト (64 KB) の倍数で、最大有効値は 4194304 バイト (4 MB) です。
単一のデータ ファイルを含む、透過的なデータ暗号化 (TDE) が有効になっているデータベースの場合、既定の MAXTRANSFERSIZE
は 65536 (64 KB) です。 TDE で暗号化されていないデータベースでは、ディスクへのバックアップを使用する場合は既定の MAXTRANSFERSIZE
が 1048576 (1 MB) となり、VDI または TAPE を使用する場合は 65536 (64 KB) となります。
注意
MAXTRANSFERSIZE では転送の最大単位を指定します。すべての書き込み操作で指定した最大サイズが転送されるとは限りません。 ストライピングされたトランザクション ログ バックアップの書き込み操作の MAXTRANSFERSIZE は、64 KB に設定されています。
以下のオプションでは、バックアップ操作に対してバックアップのチェックサムを有効にするかどうかと、エラー発生時に操作を停止するかどうかを判別できます。
バックアップのチェックサムを有効にするかどうかを制御します。
NO_CHECKSUM
バックアップ チェックサムの生成 (およびページ チェックサムの検証) を明示的に無効にします。 これは既定の動作です。
CHECKSUM
有効かつ使用可能であれば、バックアップ操作で各ページのチェックサムおよび破損ページを検証し、バックアップ全体のチェックサムを生成するように指定します。
バックアップ チェックサムを使用すると、ワークロードとバックアップのスループットに影響する可能性があります。
詳しくは、「バックアップ中および復元中に発生する可能性があるメディア エラー」をご覧ください。
ページ チェックサム エラーの発生時、バックアップ操作を停止するか続行するかを制御します。
STOP_ON_ERROR
ページ チェックサムが正しくない場合、BACKUP を失敗させます。 これは既定の動作です。
CONTINUE_AFTER_ERROR
無効なチェックサム、ページの破損などのエラーが検出されても、BACKUP を継続します。
データベースが破損したときに、NO_TRUNCATE オプションを使用してもログの末尾をバックアップできない場合は、NO_TRUNCATE の代わりに CONTINUE_AFTER_ERROR を指定してログ末尾のバックアップを試すことができます。
詳しくは、「バックアップ中および復元中に発生する可能性があるメディア エラー」をご覧ください。
機能しません。 このオプションは、以前のバージョンの SQL Server との互換性を維持するために使用できます。
指定した percentage が完了するたびにメッセージを表示します。進行状況を判断する場合に使用できます。 percentage を省略した場合、SQL Server では 10% 完了するごとにメッセージが表示されます。
STATS オプションでは、次のパーセンテージ間隔を報告するしきい値に達した時点までに、完了したパーセンテージを報告します。 これは、ほぼ指定したパーセンテージになります。たとえば、STATS=10 とすると、40% が完了した場合に、オプションでは 43% と表示されることがあります。 大規模なバックアップ セットの場合は、完了した I/O 呼び出し間での完了パーセンテージの変化が非常に遅くなるため、これは重要な問題にはなりません。
バックアップの最大ストライプ サイズは 195 GB (最大 BLOB サイズ) です。 バックアップ コマンドでストライプ サイズを増やして、個々のストライプ サイズを減らし、この制限内に収まるようにします。
BACKUP DATABASE
アクセス許可は、既定では、sysadmin 固定サーバー ロールと、db_owner および db_backupoperator の固定データベース ロールのメンバーに与えられます。
URL に対する所有とアクセス許可の問題によって、バックアップ操作が妨げられることがあります。 SQL Server では、デバイスに対して読み書きを実行できる必要があります。 SQL Server サービスが実行されているアカウントには書き込み権限が必要です。
この例では、Microsoft Azure Blob Storage への Sales
のCOPY_ONLY バックアップを実行します。 ストレージ アカウント名は 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 Microsoft Azure Blob Storage(Microsoft Azure Blob Storage を使用した SQL Server のバックアップと復元 SQL Server Backup to URL」を参照してください。
BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5, COPY_ONLY;
データベースを複数のストライプにバックアップすることもできます。これは次のようになります。
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;
* Analytics
Platform System (PDW) *
Analytics Platform System (PDW) データベースのバックアップを作成し、アプライアンスから離れた、ユーザーが指定したネットワーク上の場所に保存します。 ディザスター リカバリーのため、または1 つのアプライアンスから別のアプライアンスへデータベースをコピーするために、RESTORE DATABASE - Analytics Platform System と共にこのステートメントを使用します。
開始する前に、Analytics Platform System 製品ドキュメントの「バックアップ サーバーを入手し、構成する」をご覧ください。
Analytics Platform System (PDW) には、2 種類のバックアップがあります。 データベースの完全バックアップでは、Analytics Platform System (PDW) データベース全体をバックアップします。 差分バックアップでは、最後の完全バックアップ以降の変更のみをバックアップします。 ユーザー データベースのバックアップには、データベース ユーザーとデータベース ロールが含まれます。 master
データベースのバックアップにはログインが含まれます。
Analytics Platform System (PDW) データベース バックアップの詳細については、Analytics Platform System (PDW) 製品ドキュメント の「バックアップと復元」に関するセクションをご覧ください。
--Create a full backup of a user database or the master database.
BACKUP DATABASE database_name
TO DISK = '\\UNC_path\backup_directory'
[ WITH [ ( ]<with_options> [ ,...n ][ ) ] ]
[;]
--Create a differential backup of a user database.
BACKUP DATABASE database_name
TO DISK = '\\UNC_path\backup_directory'
WITH [ ( ] DIFFERENTIAL
[ , <with_options> [ ,...n ] [ ) ]
[;]
<with_options> ::=
DESCRIPTION = 'text'
| NAME = 'backup_name'
バックアップを作成するデータベースの名前。 データベースには、master
データベースかユーザー データベースを指定できます。
ネットワーク パスとディレクトリ。ここに Analytics Platform System (PDW) によってバックアップ ファイルが書き込まれます。 たとえば、「 \\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup
」のように入力します。
- バックアップ ディレクトリ名のパスが既に存在し、完全修飾 UNC (汎用名前付け規則) パスとして指定されている必要があります。
- バックアップ ディレクトリ backup_directory は、バックアップ コマンドの実行前に存在することはできません。 Analytics Platform System (PDW) によってバックアップ ディレクトリが作成されます。
- バックアップ ディレクトリのパスにはローカル パスを指定できません。Analytics Platform System (PDW) アプライアンス ノード上の場所とすることもできません。
- UNC パスとバックアップ ディレクトリ名の最大長は 200 文字です。
- サーバーまたはホストは IP アドレスとして指定する必要があります。 これはホストまたはサーバー名として指定できません。
バックアップの説明テキストを指定します。 テキストの最大長は 255 文字です。
説明はメタデータに格納されます。バックアップ ヘッダーが RESTORE HEADERONLY で復元されるときに表示されます。
バックアップの名前を指定します。 バックアップ名には、データベース名とは異なる名前を指定できます。
- 名前の長さは最大 128 文字です。
- パスを含めることはできません。
- 先頭の文字はアルファベット、数字、アンダースコア (
_
) のいずれかにする必要があります。 特殊文字としてはアンダースコア (_
)、ハイフン (-)、スペース ( ) が許可されます。 バックアップ名の最後の文字をスペースにすることはできません。 - 指定の場所に backup_name が既に存在する場合、ステートメントは失敗します。
この名前はメタデータに格納されます。バックアップ ヘッダーが RESTORE HEADERONLY で復元されるときに表示されます。
ユーザー データベースの差分バックアップを実行します。 省略した場合、データベースの完全バックアップが選択されます。 差分バックアップの名前は、完全バックアップの名前に一致する必要がありません。 差分バックアップとそれに対応する完全バックアップを追跡記録するために、同じ名前に 'full' または 'diff' を付けることを検討してください。
次に例を示します。
BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerFull';
BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerDiff' WITH DIFFERENTIAL;
BACKUP DATABASE
許可または db_backupoperator 固定データベース ロールのメンバーシップが必要です。 master
データベースは、db_backupoperator 固定データベース ロールに追加された標準ユーザーではバックアップできません。 master
データベースをバックアップできるのは、sa、ファブリック管理者、または sysadmin 固定サーバー ロールのメンバーに限られます。
バックアップ ディレクトリにアクセスし、作成や書き込みを行うことが許可された Windows アカウントが必要です。 Analytics Platform System (PDW) に Windows アカウント名とパスワードを保存する必要もあります。 これらのネットワーク資格情報を Analytics Platform System (PDW) に追加するには、sp_pdw_add_network_credentials - Azure Synapse Analytics ストアド プロシージャを使用します。
Analytics Platform System (PDW) の資格情報を管理する方法については、「セキュリティ」セクションをご覧ください。
次の条件下での BACKUP DATABASE エラー:
- バックアップの実行に必要なアクセス許可がユーザーにありません。
- Analytics Platform System (PDW) には、バックアップが保存されるネットワーク上の場所にアクセスする権限がありません。
- データベースが存在しません。
- ターゲット ディレクトリがネットワーク共有に既に存在します。
- ターゲット ネットワーク共有が利用できません。
- ターゲット ネットワーク共有には、バックアップのための領域が十分にありません。 BACKUP DATABASE コマンドは、バックアップの開始前に十分なディスク領域があることを確認しません。BACKUP DATABASE の実行中、ディスク容量不足エラーが生成されます。 ディスク容量不足が発生すると、Analytics Platform System (PDW) は BACKUP DATABASE コマンドをロールバックします。 データベースのサイズを小さくするには、 DBCC SHRINKLOG (Analytics Platform System (PDW)) を実行します。
- トランザクション内でバックアップを開始しようとします。
データベース バックアップを実行する前に、 DBCC SHRINKLOG (Analytics Platform System (PDW)) を使用して、データベースのサイズを小さくします。
Analytics Platform System (PDW) バックアップは、同じディレクトリ内で複数のファイルのセットとして保存されます。
通常、差分バックアップは完全バックアップよりも短時間で完了します。完全バックアップよりも頻繁に実行できます。 複数の差分バックアップが同じ完全バックアップに基づくとき、各差分バックアップには、前の差分バックアップのすべての変更が含まれます。
BACKUP コマンドをキャンセルした場合、Analytics Platform System (PDW) はターゲット ディレクトリとバックアップのために作成されたあらゆるファイルを削除します。 Analytics Platform System (PDW) で共有へのネットワーク接続が失われると、ロールバックを完了できません。
完全バックアップと差分バックアップは別々のディレクトリに保存されます。 完全バックアップと差分バックアップが同じバックアップに属することを指定するために名前付け規則が強制されることはありません。 独自の名前付け規則で追跡できます。 あるいは、WITH DESCRIPTION オプションで説明を追加し、RESTORE HEADERONLY ステートメントで説明を取得するという方法でも追跡できます。
master
データベースは差分バックアップできません。 master
データベースでは、完全バックアップのみ可能です。
master
システム データベースのトランザクション ログ バックアップはサポートされていません。
バックアップ ファイルは、RESTORE DATABASE - Analytics Platform System ステートメントを利用して、Analytics Platform System (PDW) アプライアンスにバックアップを復元するのに適した形式でのみ保存されます。
データやユーザー情報を SMP SQL Server データベースに移動するために、バックアップと BACKUP DATABASE ステートメントを使用することはできません。 この機能については、リモート テーブル コピー機能を使用できます。 詳細については、Analytics Platform System (PDW) 製品ドキュメントの「リモート テーブルのコピー」を参照してください。
Analytics Platform System (PDW) では、SQL Server バックアップ テクノロジを使用してデータベースをバックアップおよび復元します。 バックアップ圧縮を使用するために、SQL Server バックアップ オプションが事前構成されています。 圧縮、チェックサム、ブロック サイズ、バッファー カウントなど、バックアップ オプションを設定することはできません。
アプライアンスで一度に実行できるデータベース バックアップまたは復元は 1 つに限られます。 Analytics Platform System (PDW) は、現在のバックアップまたは復元コマンドが完了するまで、バックアップまたは復元コマンドを待ち行列に入れます。
バックアップを復元するためのターゲット アプライアンスには、ソース アプライアンスと同じ数の計算ノードが含まれている必要があります。 ターゲット アプライアンスにはソース アプライアンスより多くの計算ノードが含まれていても構いませんが、少ないことは許可されません。
バックアップはアプライアンスから離れた場所に保存されるため、Analytics Platform System (PDW) はバックアップの場所や名前を追跡しません。
Analytics Platform System (PDW) はデータベース バックアップの成功または失敗を追跡します。
差分バックアップは、前回の完全バックアップが正常に完了した場合にのみ許可されます。 たとえば、月曜日に Sales
データベースの完全バックアップを作成し、バックアップが正常に完了したとします。 その後、火曜日に Sales
データベースの完全バックアップを作成すると失敗します。 この失敗の後、月曜日の完全バックアップに基づいて差分バックアップを作成することはできません。 差分バックアップを作成するには、最初に完全バックアップを正常に作成する必要があります。
これらの動的管理ビューには、すべてのバックアップ操作、復元操作、読み込み操作に関する情報が含まれています。 情報は、システムの再起動の間で永続化します。
Analytics Platform System (PDW) では、バックアップを実行するために、最初にメタデータをバックアップし、それから計算ノードに保存されているデータベース データの並列バックアップを実行します。 データは各計算ノードから直接、バックアップ ディレクトリにコピーされます。 計算ノードからバックアップ ディレクトリにデータを最も効率的に移動するために、Analytics Platform System (PDW) では、同時にデータをコピーする計算ノードの数が制御されます。
DATABASE オブジェクトに ExclusiveUpdate ロックを実行します。
Analytics Platform System (PDW) バックアップはアプライアンスに格納されません。 そのため、IT チームは、バックアップ セキュリティのあらゆる面の管理を担当します。 これには、バックアップ データのセキュリティ、バックアップの保存に使用されるサーバーのセキュリティ、バックアップ サーバーを Analytics Platform System (PDW) アプライアンスに接続するネットワーク インフラストラクチャのセキュリティなどの管理が含まれます。
ネットワーク資格情報の管理
バックアップ ディレクトリへのネットワーク アクセスは、オペレーティング システムの標準ファイル共有セキュリティに基づきます。 バックアップを実行する前に、バックアップ ディレクトリに Analytics Platform System (PDW) の信頼性を証明するための Windows アカウントを作成または指定する必要があります。 この Windows アカウントには、バックアップ ディレクトリにアクセスし、作成や書き込みを行うためのアクセス許可を与える必要があります。
重要
データのセキュリティ リスクを緩和するために、バックアップ操作と復元操作を実行する目的のためだけに Windows アカウントを 1 つ用意することをお勧めします。 そのアカウントのアクセス許可をバックアップの場所に限定します。
sp_pdw_add_network_credentials - Azure Synapse Analytics ストアド プロシージャを実行し、Analytics Platform System (PDW) にユーザー名とパスワードを保存する必要があります。 Analytics Platform System (PDW) では Windows Credential Manager を利用し、計算ノードにユーザー名とパスワードを保存し、復号します。 資格情報は BACKUP DATABASE コマンドでバックアップされません。
Analytics Platform System (PDW) からネットワーク資格情報を削除する方法については、「sp_pdw_remove_network_credentials - Azure Synapse Analytics」をご覧ください。
Analytics Platform System (PDW) に保存されているネットワーク資格情報を一覧表示するには、sys.dm_pdw_network_credentials 動的管理ビューを使用してください。
バックアップを作成するには、Analytics Platform System (PDW) にバックアップ ディレクトリの読み取り/書き込み許可を与える必要があります。 次の例は、ユーザーの資格情報を追加する方法です。 Analytics Platform System (PDW) では、これらの資格情報を格納し、バックアップ操作と復元操作に利用します。
重要
セキュリティ上の理由から、バックアップ専用のドメイン アカウントを 1 つ作成することをお勧めします。
EXEC sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';
次の例は、Analytics Platform System (PDW) からドメイン ユーザーの資格情報を削除する方法です。
EXEC sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';
次の例では、Invoices ユーザー データベースの完全バックアップを作成します。 Analytics Platform System (PDW) により、Invoices2013
ディレクトリが作成され、バックアップ ファイルが \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full
ディレクトリに保存されます。
BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';
次の例では、差分バックアップを作成します。Invoices
データベースの前回の完全バックアップ以降に行われたすべての変更が含まれます。 Analytics Platform System (PDW) は、ファイルを格納する \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff
ディレクトリを作成します。 'Invoices 2013 differential backup' というバックアップの説明がヘッダー情報と共に格納されます。
差分バックアップは、Invoices の前回の完全バックアップが正常に完了した場合にのみ正常に実行されます。
BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
WITH DIFFERENTIAL,
DESCRIPTION = 'Invoices 2013 differential backup';
次の例では、master
データベースの完全バックアップを作成し、ディレクトリ \\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master
に格納します。IP はネットワーク IP アドレスです。
BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master';
master
データベースにはアプライアンス ログイン情報が保存されます。 アプライアンス ログイン情報をバックアップするには、 master
データベースをバックアップする必要があります。
次の例では、master
データベースの完全バックアップを作成します。
BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master'
WITH (
DESCRIPTION = 'Master Backup 20130722',
NAME = 'login-backup'
)
;