BACKUP (Transact-SQL)
データベース全体、または、1 つ以上のファイルまたはファイル グループをバックアップします (BACKUP DATABASE)。完全復旧モデルまたは一括ログ復旧モデルの場合に、トランザクション ログをバックアップします (BACKUP LOG)。
注意 |
---|
SQL Server でのバックアップの概要については、「バックアップの概要 (SQL Server)」を参照してください。 |
構文
Backing Up a Whole Database
BACKUP DATABASE { database_name | @database_name_var }
TO <backup_device> [ ,...n ]
[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]
Backing Up Specific Files or Filegroups
BACKUP DATABASE { database_name | @database_name_var }
<file_or_filegroup> [ ,...n ]
TO <backup_device> [ ,...n ]
[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]
Creating a Partial Backup
BACKUP DATABASE { database_name | @database_name_var }
READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
TO <backup_device> [ ,...n ]
[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]
Backing Up the Transaction Log (full and bulk-logged recovery models)
BACKUP LOG { database_name | @database_name_var }
TO <backup_device> [ ,...n ]
[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { <general_WITH_options> | <log-specific_optionspec> } [ ,...n ] ]
[;]
<backup_device>::=
{
{ logical_device_name | @logical_device_name_var }
| { DISK | TAPE } =
{ 'physical_device_name' | @physical_device_name_var }
}
<MIRROR TO clause>::=
MIRROR TO <backup_device> [ ,...n ]
<file_or_filegroup>::=
{
FILE = { logical_file_name | @logical_file_name_var }
| FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
}
<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
<general_WITH_options> [ ,...n ]::=
--Backup Set Options
COPY_ONLY
| { COMPRESSION | NO_COMPRESSION }
| DESCRIPTION = { 'text' | @text_variable }
| NAME = { backup_set_name | @backup_set_name_var }
| PASSWORD = { password | @password_variable }
| { EXPIREDATE = { 'date' | @date_var }
| RETAINDAYS = { days | @days_var } }
--Media Set Options
{ NOINIT | INIT }
| { NOSKIP | SKIP }
| { NOFORMAT | FORMAT }
| MEDIADESCRIPTION = { 'text' | @text_variable }
| MEDIANAME = { media_name | @media_name_variable }
| MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
| BLOCKSIZE = { blocksize | @blocksize_variable }
--Data Transfer Options
BUFFERCOUNT = { buffercount | @buffercount_variable }
| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
--Error Management Options
{ NO_CHECKSUM | CHECKSUM }
| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
--Compatibility Options
RESTART
--Monitoring Options
STATS [ = percentage ]
--Tape Options
{ REWIND | NOREWIND }
| { UNLOAD | NOUNLOAD }
--Log-specific Options
{ NORECOVERY | STANDBY = undo_file_name }
| NO_TRUNCATE
引数
DATABASE
データベース全体のバックアップを指定します。ファイルとファイル グループのリストを指定した場合、指定したファイルとファイル グループだけがバックアップされます。データベース全体のバックアップまたは差分バックアップ中、SQL Server では、バックアップが復元された場合に一貫性のあるデータベースを生成できるよう、必要十分なトランザクション ログをバックアップします。BACKUP DATABASE (データ バックアップ) で作成されたバックアップを復元すると、バックアップ全体が復元されます。バックアップ内の特定の時点またはトランザクションに復元できるのは、ログ バックアップだけです。
注意 master データベース上では、データベース全体のバックアップのみが可能です。
LOG
トランザクション ログのみのバックアップを指定します。前回正しく実行されたログ バックアップの位置から、ログの現在の末尾まで、ログのバックアップが行われます。最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。RESTORE LOG ステートメントで WITH STOPAT、WITH STOPATMARK、または WITH STOPBEFOREMARK を指定して、バックアップ内の特定の時間またはトランザクションにログ バックアップを復元できます。
注意 WITH NO_TRUNCATE または COPY_ONLY を指定する以外の標準的な方法でログ バックアップを行うと、一部のトランザクション ログ レコードはアクティブでなくなります。1 つ以上の仮想ログ ファイル内ですべてのレコードがアクティブでなくなった場合、ログは切り捨てられます。定期的なログ バックアップの後ログが切り捨てられない場合は、何らかの原因によりログの切り捨てが遅れている可能性があります。詳細については、「トランザクション ログの管理」を参照してください。
{ database_name| **@database_name_var }
トランザクション ログ、データベースの一部、またはデータベース全体をバックアップする場合の、バックアップ元となるデータベースを指定します。この名前を変数 (@database_name_var) として指定する場合は、文字列定数 (@database_name_var=**database name)、または ntext と text を除く文字列データ型の変数のいずれかを使用して指定できます。注意 データベース ミラーリング パートナーシップ内のミラー データベースは、バックアップできません。
<file_or_filegroup> [ ,...n ]
BACKUP DATABASE でのみ使用できます。ファイル バックアップに含めるデータベース ファイルまたはファイル グループを指定するか、部分バックアップに含める読み取り専用ファイルまたはファイル グループを指定します。FILE = { logical_file_name| **@**logical_file_name_var }
バックアップに含めるファイルの論理名、またはこの論理名を値として保持する変数を指定します。FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
バックアップに含めるファイル グループの論理名、またはこの論理名を値として保持する変数を指定します。単純復旧モデルでは、ファイル グループのバックアップは、読み取り専用のファイル グループに対してのみ使用できます。注意 データベースのサイズやパフォーマンス要件によりデータベース バックアップの実行が難しい場合は、ファイル単位のバックアップを検討してください。
n
複数のファイルおよびファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダです。数値の制限はありません。
詳細については、「ファイルの完全バックアップ」および「ファイルおよびファイル グループをバックアップする方法 (Transact-SQL)」を参照してください。
READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var } [ ,...n ] ]
部分バックアップを指定します。部分バックアップには、データベース内のすべての読み取り/書き込みファイル (プライマリ ファイル グループ、存在する場合は読み取り/書き込みセカンダリ ファイル グループ、および指定の読み取り専用ファイルまたはファイル グループ) が含まれます。READ_WRITE_FILEGROUPS
部分バックアップで、すべての読み取り/書き込みファイル グループをバックアップすることを指定します。データベースが読み取り専用の場合、READ_WRITE_FILEGROUPS にはプライマリ ファイル グループのみが含まれます。重要 READ_WRITE_FILEGROUPS の代わりに FILEGROUP を使用して、読み取り/書き込みファイル グループのリストを明示的に指定すると、ファイル バックアップが作成されます。
FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
部分バックアップに含める読み取り専用ファイル グループの論理名、またはこの論理名を値として保持する変数を指定します。詳細については、前の「<file_or_filegroup>」を参照してください。n
複数の読み取り専用ファイル グループを、コンマで区切ったリストで指定できることを示すプレースホルダです。
部分バックアップの詳細については、「部分バックアップ」を参照してください。
TO <backup_device> [ ,...n]
関連するバックアップ デバイスのセットが、ミラー化されてないメディア セット、またはミラー化されたメディア セット内にあるミラーの 1 つ目 (1 つ以上の MIRROR TO 句が宣言されている場合) であることを示します。<backup_device>
バックアップ操作に使用する論理または物理バックアップ デバイスを指定します。{ logical_device_name | @logical_device_name_var }
データベースのバックアップが作成されるバックアップ デバイスの論理名を指定します。論理名は、識別子のルールに従う必要があります。バックアップ デバイス名を変数 (@logical_device_name_var) として指定する場合は、文字定数 (@logical_device_name_var= logical backup device name) として指定するか、ntext データ型と text データ型を除く文字列型の変数として指定できます。{ DISK | TAPE } = { 'physical_device_name' | **@**physical_device_name_var }
ディスク ファイルまたはテープ デバイスを指定します。ディスク デバイスは、BACKUP ステートメントで指定するときにまだ存在していなくてもかまいません。物理デバイスが既に存在し、BACKUP ステートメントに INIT オプションが指定されていない場合、バックアップはデバイスに追加されます。
詳細については、「バックアップ デバイス」を参照してください。
注意 TAPE オプションは将来のバージョンの SQL Server では削除される予定です。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。
n
最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダです。
MIRROR TO <backup_device> [ ,...n]
TO 句で指定したバックアップ デバイスをミラー化する、最大 3 つまでのセカンダリ バックアップ デバイスのセットを指定します。MIRROR TO 句には、TO 句で指定した同じ種類と数のバックアップ デバイスを指定する必要があります。MIRROR TO 句の最大数は 3 です。このオプションは、SQL Server 2005 Enterprise Edition 以降のバージョンでのみ使用できます。
注意 MIRROR TO = DISK の場合、BACKUP によって、ディスク デバイスに応じた適切なブロック サイズが自動的に決まります。ブロック サイズの詳細については、後の「BLOCKSIZE」の説明を参照してください。
<backup_device>
詳細については、前の「<backup_device>」を参照してください。n
最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダです。各 MIRROR TO 句内のデバイス数は、TO 句内のデバイス数と同じである必要があります。
詳細については、後の「解説」の「ミラー化されたメディア セットのメディア ファミリ」を参照してください。
[ next-mirror-to ]
単一の BACKUP ステートメントに、1 つの TO 句と 3 つまでの MIRROR TO 句を含めることができることを示すプレースホルダです。
WITH オプション
バックアップ操作で使用するオプションを指定します。
DIFFERENTIAL
BACKUP DATABASE でのみ使用できます。前回の完全バックアップ以降に変更が加えられたデータベースやファイルだけをバックアップすることを指定します。完全バックアップに比べ、差分バックアップの方が使用領域が少なくてすみます。前回の完全バックアップ以降に実行された各ログ バックアップをすべて適用する必要がない場合に、このオプションを使用します。注意 BACKUP DATABASE では、既定で完全バックアップが作成されます。
詳細については、「差分バックアップの使用」を参照してください。
バックアップ セット オプション
以下のオプションは、このバックアップ操作で作成されるバックアップ セットに対して有効なオプションです。
注意 |
---|
復元操作用のバックアップ セットを指定するには、FILE =<backup_set_file_number> オプションを使用します。バックアップ セットの指定方法の詳細については、「RESTORE の引数 (Transact-SQL)」の「バックアップ セットの指定」を参照してください。 |
COPY_ONLY
通常のバックアップの順序には影響しない、コピーのみのバックアップであることを指定します。コピーのみのバックアップは定期的に行われる従来のバックアップとは別に作成するもので、コピーのみのバックアップを行っても、データベースの全体的なバックアップと復元の手順に影響はありません。コピーのみのバックアップは、オンラインでファイルを復元する前にログをバックアップするなど、特殊な目的でバックアップを作成する場合を想定して SQL Server 2005 に導入されたオプションです。通常、コピーのみのログ バックアップは 1 回だけ使用して、その後削除します。
BACKUP DATABASE で COPY_ONLY オプションを使用した場合、作成される完全バックアップは差分ベースとして使用できません。差分ビットマップは更新されず、後に実行する差分バックアップではコピーのみのバックアップは無視され、従来のバックアップで作成された最新の完全バックアップがベースとして使用されます。
重要 COPY_ONLY を DIFFERENTIAL と共に使用した場合、COPY_ONLY は無視され、差分バックアップが作成されます。
BACKUP LOG と共に使用した場合、COPY_ONLY オプションによってコピーのみのログ バックアップが作成されます。トランザクション ログは切り捨てられません。コピーのみのログ バックアップはログ チェーンに影響せず、他のログ バックアップはコピーのみのバックアップが存在しない場合と同様に動作します。
詳細については、「コピーのみのバックアップ」を参照してください。
{ COMPRESSION | NO_COMPRESSION }
SQL Server 2008 Enterprise 以降のバージョンでのみ、バックアップでバックアップの圧縮を実行するかどうかを指定し、サーバー レベルの既定値を上書きできます。インストール時の既定の動作では、バックアップの圧縮は行われません。ただし、この既定の動作は、backup compression default サーバー構成オプションを設定することで変更できます。このオプションの現在の値を表示する方法については、「サーバーのプロパティを表示する方法 (SQL Server Management Studio)」を参照してください。
COMPRESSION
バックアップの圧縮を明示的に有効にします。注意 既定では、バックアップが圧縮されるとき、チェックサムが実行されてメディアの破損が検出されます。
NO_COMPRESSION
バックアップの圧縮を明示的に無効にします。
DESCRIPTION = { 'text' | **@**text_variable }
バックアップ セットを記述したテキストを自由な形式で指定します。文字列の長さは最大 255 文字です。NAME = { backup_set_name| **@**backup_set_var }
バックアップ セットの名前を指定します。名前の長さは最大 128 バイトです。NAME を指定しないと、名前は空白になります。PASSWORD = { password | **@**password_variable }
バックアップ セットのパスワードを設定します。PASSWORD は文字列です。重要 この機能は、Microsoft SQL Server の次のバージョンで削除されます。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。
バックアップ セットのパスワードが定義されている場合は、パスワードを指定して、バックアップ セットから SQL Server 復元操作を実行する必要があります。ただし、バックアップ セットのパスワードを指定しても、バックアップ ファイルの上書きを防止することはできません。バックアップ ファイルが上書きされないようにするには、代わりにメディア セットのパスワードを使用します (後の MEDIAPASSWORD オプションの説明を参照)。パスワードの使用の詳細については、後の「権限」を参照してください。
セキュリティに関する注意 パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。バックアップ保護に最適な方法は、バックアップ テープを安全な場所に保管するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。
{ EXPIREDATE = 'date'| RETAINDAYS = days }
このバックアップのバックアップ セットがいつ上書きできるようになるかを指定します。オプションを両方とも使用した場合は、RETAINDAYS が EXPIREDATE よりも優先されます。どちらのオプションも指定しない場合、失効日は mediaretention (メディア保持期間) の設定によって決まります。詳細については、「サーバー構成オプションの設定」を参照してください。
重要 これらのオプションは、SQL Server でのファイルの上書きを防ぐことのみを目的としています。テープは別の方法で消去することができ、ディスク ファイルはオペレーティング システムで削除できます。有効期限の確認の詳細については、このトピックの「SKIP」および「FORMAT」を参照してください。
EXPIREDATE = { 'date'| **@**date_var }
バックアップ セットが失効して上書きできるようになる日を指定します。この日付を変数 (@date_var) として指定する場合、構成されたシステムの datetime 形式に従い、次のいずれかを使用して指定する必要があります。文字定数 (@date_var = date)
文字列型 (ntext データ型または text データ型を除く) の変数
smalldatetime 変数
datetime 変数
次に例を示します。
'Dec 31, 2020 11:59 PM'
'1/1/2021'
datetime 値の指定方法の詳細については、「日時データの使用」を参照してください。
注意 失効日を無視するには、SKIP オプションを使用します。
RETAINDAYS = { days| **@days_var }
このバックアップ メディア セットに上書きできるようになるまでの経過日数を指定します。この日数を変数 (@**days_var) として指定する場合は、整数で指定する必要があります。
メディア セットのオプション
以下のオプションはメディア セット全般に適用されます。
{ NOINIT | INIT }
バックアップ操作で、バックアップ メディア上の既存のバックアップ セットに追加するか、上書きするかを制御します。既定では、メディア上の最新のバックアップ セットに追加します (NOINIT)。注意 { NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。
NOINIT
バックアップ セットを指定のメディア セットに追加します。この場合、既存のバックアップ セットは維持されます。メディア セットのメディア パスワードが定義されている場合は、パスワードを指定する必要があります。既定値は NOINIT です。詳細については、「既存のバックアップ セットへの追加」を参照してください。
INIT
すべてのバックアップ セットを上書きします。ただし、メディア ヘッダーは維持されます。INIT を指定した場合は、条件が満たされる限り、そのデバイス上にある既存のすべてのバックアップ セットが上書きされます。既定では、BACKUP によって次の状況が確認され、いずれかの状況に該当する場合はバックアップ メディアは上書きされません。バックアップ セットがまだ期限切れではない。詳細については、EXPIREDATE オプションおよび RETAINDAYS オプションの説明を参照してください。
BACKUP ステートメントにバックアップ セットの名前が指定されていて、その名前がバックアップ メディア上の名前と一致していない。詳細については、前の「NAME」オプションを参照してください。
これらのチェックを無効にするには、SKIP オプションを使用します。
注意 バックアップ メディアがパスワードで保護されている場合、メディア パスワードを指定しない限り、SQL Server がメディアに書き込みを行うことはありません。このチェックは、SKIP オプションでも無効になりません。パスワードで保護されているメディアを上書きするには、メディアを再フォーマットするのが唯一の方法です。再フォーマットすると、メディア上のバックアップ データは削除されます。メディア パスワードの詳細については、前の「MEDIAPASSWORD」を参照してください。メディアの再フォーマットについては、前の「FORMAT」を参照してください。
詳細については、「バックアップ セットの上書き」を参照してください。
{ NOSKIP | SKIP }
バックアップ操作で、上書き前にメディア上のバックアップ セットの失効日と失効時刻を確認するかどうかを制御します。注意 { NOINIT | INIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。
NOSKIP
上書きを許可する前に、メディア上のすべてのバックアップ セットの有効期限を確認することを BACKUP ステートメントに指示します。これは既定の動作です。SKIP
バックアップ セットの有効期限と名前の確認を無効にします。この確認は、通常、バックアップ セットの上書きを防止するために BACKUP ステートメントによって実行されます。{ INIT | NOINIT } と { NOSKIP | SKIP } の相関関係については、後の「解説」を参照してください。バックアップ セットの失効日を確認するには、backupset 履歴テーブルの expiration_date 列をクエリします。
{ NOFORMAT | FORMAT }
このバックアップ操作で使用するボリュームに新しいメディア ヘッダーを書き込み、既存のメディア ヘッダーとバックアップ セットを上書きするかどうかを指定します。NOFORMAT
このバックアップ操作に使用するメディア ボリューム上の、既存のメディア ヘッダーとバックアップ セットを保持するよう指定します。これは既定の動作です。FORMAT
新しいメディア セットを作成します。FORMAT を指定した場合、バックアップ操作に使用するすべてのメディア ボリュームに、新しいメディア ヘッダーを書き込みます。この場合、ボリューム上の既存のメディア ヘッダーとバックアップ セットは上書きされるので、それまであった内容は無効になります。重要 FORMAT の使用には注意が必要です。メディア セットに属するボリュームを 1 つでも初期化すると、メディア セット全体が使用できなくなります。たとえば、既存のストライプ メディア セットに属するテープを 1 つ初期化すると、このメディア セット全体が使用できなくなります。
FORMAT を指定することは SKIP を実行することを意味します。SKIP を明示的に指定する必要はありません。
MEDIADESCRIPTION = { text | **@**text_variable }
メディア セットを記述した自由形式のテキストを最大 255 文字で指定します。MEDIANAME = { media_name | **@**media_name_variable}
バックアップ メディア セット全体に対するメディア名を指定します。メディア名は最長 128 文字まで入力できます。MEDIANAME を指定する場合、バックアップ ボリュームに既に存在する、前回指定したメディア名と一致する必要があります。MEDIANAME を指定しない場合、または SKIP オプションを指定した場合、メディア名の照合チェックは行われません。MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
メディア セットのパスワードを設定します。MEDIAPASSWORD は文字列です。重要 この機能は、Microsoft SQL Server の次のバージョンで削除されます。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。
メディア セットのパスワードが定義されている場合は、そのメディア セットにバックアップ セットを作成する前にパスワードを指定する必要があります。また、そのメディア セットから復元操作を実行する際にも、そのメディア パスワードを指定する必要があります。パスワードで保護されているメディアを上書きするには、再フォーマットするしかありません。詳細については、FORMAT オプションの説明を参照してください。パスワードの使用の詳細については、後の「権限」を参照してください。
セキュリティに関する注意 パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。バックアップ保護に最適な方法は、バックアップ テープを安全な場所に保管するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。
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 の計算によって算出されます。
MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
SQL Server とバックアップ メディア間で使用される最大転送単位をバイト単位で指定します。有効値は 65536 バイト (64 KB) の倍数で、最大有効値は 4194304 バイト (4 MB) です。
エラー管理オプション
以下のオプションは、バックアップ操作に際してバックアップのチェックサムを有効にするかどうかと、エラー発生時に操作を停止するかどうかを指定するオプションです。
{ NO_CHECKSUM | CHECKSUM }
バックアップのチェックサムを有効にするかどうかを制御します。NO_CHECKSUM
バックアップ チェックサムの生成 (およびページ チェックサムの検証) を明示的に無効にします。これは圧縮されたバックアップ以外の既定の動作です。CHECKSUM
バックアップのチェックサムを有効にします。この場合 BACKUP で次の処理を行えるようになります。バックアップ メディアにページを書き込む前に、BACKUP によってページ (ページ チェックサムまたは破損したページ) を確認し、この情報がページ上に存在するかどうかを検証します。
ページ チェックサムが存在するかどうかに関係なく、BACKUP によってバックアップ ストリームに個別のバックアップ チェックサムが生成されます。復元操作でバックアップ チェックサムを使用し、バックアップが破損していないかどうかを検証することもできます。バックアップ チェックサムは、データベース ページにではなくバックアップ メディアに格納されます。バックアップ チェックサムは、復元時に使用することもできます。
バックアップ チェックサムを使用すると、ワークロードとバックアップのスループットに影響する場合があります。
これは圧縮されたバックアップの既定の動作です。
{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
ページ チェックサム エラーの発生時、バックアップ操作を停止するか続行するかを制御します。STOP_ON_ERROR
ページ チェックサムが正しくない場合、BACKUP を失敗させます。これは既定の動作です。CONTINUE_AFTER_ERROR
無効なチェックサム、ページの破損などのエラーが検出されても、BACKUP を継続します。データベースが破損したとき、NO_TRUNCATE オプションを使用してもログの末尾をバックアップできない場合は、NO_TRUNCATE の代わりに CONTINUE_AFTER_ERROR を指定してログ末尾のバックアップを試してください。
互換性オプション
- RESTART
機能しません。このオプションが利用できるのは、以前のバージョンの SQL Server と互換性を維持するためです。
監視オプション
STATS [ **=**percentage ]
指定した percentage の完了ごとにメッセージを表示します。進行状況を判断する場合に使用できます。percentage を省略した場合、SQL Server では 10% 完了するごとにメッセージが表示されます。STATS オプションでは、次のパーセンテージをレポートするためのしきい値に達した時点で、完了したパーセンテージがレポートされます。このしきい値は、指定したパーセンテージを正確に反映するものではありません。たとえば STATS=10 の場合、40% が完了しても、43% の時点でメッセージが表示されることがあります。大きいバックアップ セットの場合、これは重要な問題にはなりません。これは、完了した I/O 呼び出し間で、完了パーセンテージの変化が非常に遅くなるためです。
テープ オプション
このオプションはテープ デバイスにのみ適用されます。テープ以外のデバイスが使用される場合、このオプションは無視されます。
{ REWIND | NOREWIND }
REWIND
SQL Server でテープを解放して巻き戻します。既定値は REWIND です。NOREWIND
SQL Server でバックアップ操作の後テープを開いたままにしておくことを指定します。このオプションを使用すると、1 つのテープに複数のバックアップ操作を実行する場合のパフォーマンスを向上できます。NOREWIND は暗黙的に NOUNLOAD も意味しています。この 2 つのオプションを同一 BACKUP ステートメント内で同時に使用することはできません。
注意 NOREWIND を使用する場合、テープ ドライブの所有権は SQL Server インスタンスによって保持されます。同じプロセス内で実行される BACKUP ステートメントや RESTORE ステートメントで REWIND オプションまたは UNLOAD オプションが使用されるか、サーバー インスタンスがシャットダウンすると、所有権は解放されます。テープを開いたままにすると、他のプロセスはそのテープにアクセスできません。開いているテープの一覧を表示する方法、および開いているテープを閉じる方法については、「バックアップ デバイス」を参照してください。
{ UNLOAD | NOUNLOAD }
注意 UNLOAD または NOUNLOAD はセッションの設定であり、セッションが終了するまで、または代わりとなるオプションの指定によりリセットされるまで有効です。
UNLOAD
バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行います。UNLOAD はセッション開始時の既定の設定です。NOUNLOAD
BACKUP 操作の後、テープ ドライブにテープを読み込んだままにすることを指定します。
注意 |
---|
テープ バックアップ デバイスへのバックアップの場合、BLOCKSIZE オプションはバックアップ操作のパフォーマンスに影響します。このオプションがパフォーマンスに影響するのは、通常、テープ デバイスに書き込むときだけです。 |
ログ関係のオプション
以下のオプションは、BACKUP LOG でのみ使用するオプションです。
注意 |
---|
ログ バックアップを作成しない場合は、単純復旧モデルを使用します。詳細については、「単純復旧モデルでのバックアップ」を参照してください。 |
{ NORECOVERY | STANDBY **=**undo_file_name }
NORECOVERY
ログの末尾をバックアップし、データベースを RESTORING の状態のままにします。NORECOVERY は、セカンダリ データベースにフェールオーバーする場合、または RESTORE 操作の前にログの末尾を保存する場合に便利です。ログの切り捨てをスキップするベストエフォートのログ バックアップを実行して、データベースを自動的に RESTORING 状態にするには、NO_TRUNCATE および NORECOVERY オプションを同時に使用します。
STANDBY **=**standby_file_name
ログの末尾をバックアップし、データベースを読み取り専用および STANDBY 状態のままにします。STANDBY 句では、スタンバイ データが書き込まれます。ロールバックが実行されますが、追加の復元を行うこともできます。STANDBY オプションの使用は、BACKUP LOG WITH NORECOVERY の後に RESTORE WITH STANDBY を使用する場合と同じ効果があります。スタンバイ モードの使用にはスタンバイ ファイルが必要で、これは standby_file_name で指定します。その位置はデータベースのログに格納されます。指定したファイルが既に存在する場合、データベース エンジンによってファイルが上書きされます。ファイルが存在しない場合、データベース エンジンによってファイルが作成されます。スタンバイ ファイルはデータベースの一部となります。
このファイルには、ロールバックされた変更内容が含まれています。RESTORE LOG 操作を後で適用する場合、これらの変更内容の順序を逆にする必要があります。スタンバイ ファイルでは、ファイル サイズが増加するので、ディスクに十分な空き容量が必要です。これは、コミットされていないトランザクションのロールバックによって変更が加えられた、データベース内にあるすべてのページを保存できるようにするためです。
NO_TRUNCATE
ログが切り捨てられないように指定し、データベースの状態に関係なく、データベース エンジンによってバックアップが行われるようにします。その結果、NO_TRUNCATE で実行されるバックアップに不完全なメタデータが含まれる場合があります。このオプションを使用すると、データベースが破損している場合でもログをバックアップできます。BACKUP LOG の NO_TRUNCATE オプションを指定すると、COPY_ONLY と CONTINUE_AFTER_ERROR の両方を指定する場合と同じ結果が得られます。
NO_TRUNCATE オプションを使用しない場合は、データベースが ONLINE 状態である必要があります。データベースが SUSPENDED 状態の場合は、NO_TRUNCATE を指定することによってバックアップを作成できる可能性がありますが、データベースが OFFLINE または EMERGENCY 状態の場合、NO_TRUNCATE を使用しても BACKUP を実行できません。データベースの状態については、「データベースの状態」を参照してください。
説明
データベースやログのバックアップは、任意のディスクまたはテープ デバイスに追加できます。これによって、データベースとそのトランザクション ログをすべて 1 つの物理位置に格納できます。
BACKUP ステートメントは、明示的または暗黙的なトランザクションでは使用できません。
オペレーティング システムがデータベースの照合順序をサポートしている場合は、プロセッサの種類が違っていても、1 つのプラットフォームから別のプラットフォームにわたるバックアップ操作を実行できます。
バックアップの用語、バックアップ デバイス、バックアップの管理については、「SQL Server でのバックアップ メディアの操作」を参照してください。
注意 |
---|
既定では、バックアップ操作が成功するたびに、SQL Server エラー ログおよびシステム イベント ログにエントリが 1 つ追加されます。ログを頻繁にバックアップすると、これらの成功メッセージがすぐに蓄積され、他のメッセージを探すのが困難になるほどエラー ログが大きくなることがあります。そのような場合、これらのエントリに依存するスクリプトがなければ、トレース フラグ 3226 を使用することによってこれらのログ エントリを除外できます。詳細については、「トレース フラグ (Transact-SQL)」を参照してください。 |
トランザクション ログの切り捨て
データベースのトランザクション ログがいっぱいにならないように、トランザクション ログを定期的にバックアップする必要があります。ログの切り捨ては、単純復旧モデルではデータベースのバックアップ後に、完全復旧モデルではトランザクション ログのバックアップ後に自動的に行われます。ただし、切り捨ての処理が遅れる場合もあります。この遅延の要因の特定および対処の方法については、「ログの切り捨てが遅れる原因となる要因」を参照してください。
注意 |
---|
BACKUP LOG WITH NO_LOG オプションと WITH TRUNCATE_ONLY オプションは廃止されました。完全復旧モデルまたは一括ログ復旧モデルの復旧を使用している場合に、ログ バックアップ チェーンをデータベースから削除するには、単純復旧モデルに切り替える必要があります。詳細については、「完全復旧モデルまたは一括ログ復旧モデルからの切り替え」を参照してください。 |
ログの切り捨て全般の詳細については、「トランザクション ログの切り捨て」を参照してください。
同時実行
SQL Server では、オンライン バックアップを使って、使用中のデータベースをバックアップできます。バックアップ中はほとんどの操作が可能です。たとえば、INSERT、UPDATE、または DELETE ステートメントはバックアップ操作中でも使用できます。
データベース バックアップやトランザクション ログ バックアップ中に実行できない操作には次のものがあります。
ADD FILE または REMOVE FILE のいずれかのオプションが指定された ALTER DATABASE ステートメントなどのファイル管理操作。
データベースまたはファイルの圧縮操作。これには自動圧縮操作も含まれます。
バックアップ操作がファイル管理または圧縮操作と重複すると、競合が発生します。どの競合操作が最初に始まったかに関係なく、最初の操作によって設定されたロックがタイムアウトになるまで、2 番目の操作は待機します (タイムアウト時間はセッション タイムアウト設定で制御されます)。ロックがタイムアウト期間内に解放されると、2 番目の操作が開始されます。ロックがタイムアウトになると、2 番目の操作は実行されません。
バックアップ メディアのフォーマット
次の条件のいずれか 1 つでも該当する場合は、BACKUP ステートメントでバックアップ メディアがフォーマットされます。
FORMAT オプションが指定されている。
メディアが空である。
連続するテープに書き込んでいる。
詳細については、「新しいメディア セットの作成」を参照してください。
バックアップの種類
実行できるバックアップの種類は、次のようにデータベースの復旧モデルに依存します。
データの完全バックアップと差分バックアップはすべての復旧モデルで実行できます。
バックアップの範囲
バックアップの種類
データベース全体
データベース バックアップでは、データベース全体が対象となります。
データベースの部分バックアップ
部分バックアップでは、読み取り/書き込みファイル グループと、必要に応じて 1 つ以上の読み取り専用ファイルまたはファイル グループが対象となります。
ファイルまたはファイル グループ
ファイル バックアップでは、1 つ以上のファイルまたはファイル グループが対象となります。複数のファイル グループを含むデータベースにのみ関連します。単純復旧モデルでは、ファイル バックアップは原則として読み取り専用セカンダリ ファイル グループに限定されます。
完全復旧モデルまたは一括ログ復旧モデルでは、従来のバックアップの必須作業として、シーケンシャル トランザクション ログ バックアップ (またはログ バックアップ) も含まれます。各ログ バックアップでは、トランザクション ログのうち、バックアップが作成された時点でアクティブだった部分と、前回のログ バックアップでバックアップされなかったすべてのログ レコードが対象となります。
作業損失の可能性を最小に抑えるには、管理のオーバーヘッドが発生するという犠牲を払っても、ログ バックアップを頻繁に行うようスケジュールする必要があります。完全バックアップの合間に差分バックアップを行うようにスケジュールすると、データを復元した後で復元する必要のあるログ バックアップの数が減るので、復元時間を短縮することができます。
ログ バックアップは、データベースのバックアップとは別のボリュームに配置することをお勧めします。
注意 最初のログ バックアップを作成するには、その前に完全バックアップを作成する必要があります。
詳細については、「トランザクション ログのバックアップ」を参照してください。
コピーのみのバックアップは、従来のバックアップで行われる一連の作業とは別に、特別な目的で行われる完全バックアップまたはログ バックアップです。コピーのみのバックアップを作成するには、BACKUP ステートメントで COPY_ONLY オプションを指定します。詳細については、「コピーのみのバックアップ」を参照してください。
SKIP、NOSKIP、INIT および NOINIT の相関関係
次の表に、{ NOINIT | INIT } と { NOSKIP | SKIP } オプションの相関関係を示します。
注意 |
---|
テープ メディアが空の場合、またはディスクのバックアップ ファイルが存在しない場合は、これらすべての相関関係に基づいて、メディア ヘッダーが記述され、操作が継続します。ただしメディアが空でなく、有効なメディア ヘッダーが含まれない場合、これらの操作では有効な MTF メディアでないことが返され、バックアップ操作は中断されます。 |
|
NOINIT |
INIT |
---|---|---|
NOSKIP |
ボリュームに有効なメディア ヘッダーが含まれる場合は、このメディアのパスワードを確認し、MEDIANAME が指定されていれば、その値とメディア名が一致していることを確認します。メディア名が一致した場合は、すべての既存のバックアップ セットはそのままにして、バックアップ セットを追加します。 ボリュームに有効なメディア ヘッダーが含まれない場合、エラーが発生します。 |
ボリュームに有効なメディア ヘッダーが含まれている場合は、次のチェックを実行します。
上のチェックにパスした場合は、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。 ボリュームに有効なメディア ヘッダーが含まれない場合は、MEDIANAME、MEDIAPASSWORD、および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。 |
SKIP |
ボリュームに有効なメディア ヘッダーが含まれる場合は、このメディアのパスワードを確認し、すべての既存のバックアップ セットをそのままにして、バックアップ セットを追加します。 |
ボリュームに有効な 1 メディア ヘッダーが含まれる場合は、このメディアのパスワードを確認し、メディア ヘッダーだけをそのままにして、メディア上のすべてのバックアップ セットを上書きします。 メディアが空の場合は、MEDIANAME、MEDIAPASSWORD、および MEDIADESCRIPTION が指定されていれば、これらのオプションを使用してメディア ヘッダーを生成します。 |
1 妥当性チェックには、MTF のバージョン番号およびその他のヘッダー情報が含まれます。指定されたバージョンがサポートされていないか、予期しない値の場合、エラーが発生します。
2 ユーザーがバックアップ操作を実行するためには、適切な固定データベース ロールまたはサーバー ロールに属し、正しいメディア パスワードを指定する必要があります。
バックアップ履歴テーブル
SQL Server には次のようなバックアップ履歴テーブルがあり、これによってバックアップ処理が追跡されます。
復元を実行する場合、バックアップ セットが msdb データベースにまだ記録されていないと、バックアップ履歴テーブルが変更される可能性があります。
互換性サポート
注意 |
---|
SQL Server によって作成されたバックアップは、それより前のバージョンの SQL Server では復元できません。 |
BACKUP には、以前のバージョンの SQL Server との互換性を維持するため、RESTART オプションが用意されています。ただし、RESTART は SQL Server 2005 以降のバージョンでは無効です。
ストライプ メディア セット (ストライプ セット) 内のバックアップ デバイス
ストライプ セットとは、データがブロックに分割され、一定の順序で分散される、一連のディスク ファイルです。ストライプ セットで使用されるバックアップ デバイスの数は、(FORMAT でメディアを再初期化する場合を除いて) 常に同じである必要があります。
次の例では、AdventureWorks データベースのバックアップを、3 つのディスク ファイルを使用する新しいストライプ メディア セットに書き込みます。
BACKUP DATABASE AdventureWorks
TO DISK='X:\SQLServerBackups\AdventureWorks1.bak',
DISK='Y:\SQLServerBackups\AdventureWorks2.bak',
DISK='Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
MEDIANAME = 'AdventureWorksStripedSet0',
MEDIADESCRIPTION = 'Striped media set for AdventureWorks database;
GO
バックアップ デバイスをいったんストライプ セットの一部として定義すると、FORMAT を指定しない限り、ファイル単位のバックアップに使用することはできません。同様に、非ストライプ バックアップを含むバックアップ デバイスは、FORMAT を指定しない限り、ストライプ セットでは使用できません。ストライプ バックアップ セットを分割するには、FORMAT を使用します。
メディア ヘッダーを書き込むときに MEDIANAME と MEDIADESCRIPTION のいずれも指定しない場合、空白項目に該当するメディアのヘッダー フィールドは空になります。
ミラー化されたメディア セットの操作
通常、バックアップはミラー化せず、BACKUP ステートメントには TO 句のみを指定しますが、メディア セットあたり 4 つまでミラーを指定できます。ミラー化されたメディア セットの場合、バックアップ操作では、バックアップ デバイスの複数のグループに書き込みが行われます。このバックアップ デバイスの各グループが、ミラー化されたメディア セット内の 1 つのミラーとなります。それぞれのミラーでは同じ容量および種類の物理バックアップ デバイスを使用する必要があり、プロパティがすべて同じである必要があります。
ミラー化されたメディア セットにバックアップを作成するには、ミラーがすべて存在している必要があります。ミラー化されたメディア セットにバックアップするには、TO 句に 1 つ目のミラーを指定し、MIRROR TO 句にその他のミラーをそれぞれ指定します。
ミラー化されたメディア セットの場合、各 MIRROR TO 句では、TO 句と同じ数および種類のデバイスのリストを指定する必要があります。次の例では、ミラー化されたメディア セットに書き込みます。このメディア セットには 2 つのミラーが含まれ、それぞれで 3 つのデバイスが使用されています。
BACKUP DATABASE AdventureWorks
TO DISK='X:\SQLServerBackups\AdventureWorks1a.bak',
DISK='Y:\SQLServerBackups\AdventureWorks2a.bak',
DISK='Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak',
DISK='Y:\SQLServerBackups\AdventureWorks2b.bak',
DISK='Z:\SQLServerBackups\AdventureWorks3b.bak';
GO
重要 |
---|
この例は、ローカル システム上でテストできるように設計されています。実際には同じドライブ上にある複数のデバイスにバックアップすると、パフォーマンスが低下するおそれがあり、ミラー化されたメディア セットの設計目的でもある冗長性が損なわれる可能性があります。 |
ミラー化されたメディア セットのメディア ファミリ
BACKUP ステートメントの TO 句で指定する各バックアップ デバイスは、1 つのメディア ファミリとなります。たとえば、TO 句で 3 つのデバイスのリストを指定する場合、BACKUP では 3 つのメディア ファミリにデータが書き込まれます。ミラー化されたメディア セットでは、各ミラーにすべてのメディア ファミリのコピーが含まれている必要があります。このため、各ミラーでデバイス数が一致する必要があります。
各ミラーに対し複数のデバイスのリストを指定する順番によって、どのメディア ファミリがどのデバイスに書き込まれるかが決まります。たとえば、各デバイスのリストで、2 番目のデバイスは 2 番目のメディア ファミリに対応します。先に示した例のデバイスでは、デバイスとメディア ファミリの対応は次の表のようになります。
ミラー |
メディア ファミリ 1 |
メディア ファミリ 2 |
メディア ファミリ 3 |
---|---|---|---|
0 |
Z:\AdventureWorks1a.bak |
Z:\AdventureWorks2a.bak |
Z:\AdventureWorks3a.bak |
1 |
Z:\AdventureWorks1b.bak |
Z:\AdventureWorks2b.bak |
Z:\AdventureWorks3b.bak |
1 つのメディア ファミリは常に、特定のミラー内の同じデバイス上にバックアップされる必要があります。したがって、既存のメディア セットを使用するときは毎回、メディア セットを作成したときと同じ順序で各ミラーのデバイスを列挙してください。
ミラー化メディア セットの詳細については、「ミラー化バックアップ メディア セットの使用」を参照してください。一般的なメディア セットおよびメディア ファミリの詳細については、「メディア セット、メディア ファミリ、およびバックアップ セット」を参照してください。
権限
BACKUP DATABASE 権限と BACKUP LOG 権限は、既定では、sysadmin 固定サーバー ロール、db_owner 固定データベース ロール、および db_backupoperator 固定データベース ロールのメンバに与えられています。
また、ユーザーがメディア セット パスワード、バックアップ セット パスワード、またはその両方を指定する場合もあります。パスワードがメディア セットで定義されている場合、これらの操作を実行するにはメディア パスワードを指定する必要もあります。同様に、復元コマンドで正しいメディア パスワードおよびバックアップ セット パスワードを指定しないと、復元は実行されません。
バックアップ セットとメディア セットのパスワードの定義は、BACKUP ステートメントのオプション機能です。パスワードによる保護は強力なものではありません。パスワードによる保護は、権限の有無にかかわらず、ユーザーが SQL Server ツールを使用して不適切な復元を行わないようにすることを目的としています。その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。また、パスワードでは FORMAT オプションによるメディアの上書きは防げません。強力なパスワードを使用することをお勧めします。強力なパスワードについては、「強力なパスワード」を参照してください。
このように、パスワードを使用することで、SQL Server ツールを使って行われる不正アクセスからメディアの内容を保護することはできますが、内容の破棄を防ぐことはできません。なお、バックアップ セット内のデータは暗号化されていないため、不正アクセスを目的に特別に作成されたプログラムを使用すれば、理論上はデータの傍受が可能です。このため、パスワードだけでは不正アクセスから完全にメディアの内容を保護することはできません。セキュリティがきわめて重要な状況においては、不正ユーザーによるメディアへの物理的アクセスを防ぐことが重要になります。
パスワードと関連付けて作成されていないオブジェクトに対しては、パスワードを指定できません。
BACKUP は、PASSWORD オプションで指定されるバックアップ セット パスワードを使用して、バックアップ セットを作成します。また、通常は、メディアに書き込む前に、MEDIAPASSWORD オプションで指定されるメディア パスワードを確認します。メディア ヘッダーを上書きするメディアのフォーマットが行われる場合に限り、BACKUP はメディア パスワードを確認しません。BACKUP によってメディア ヘッダーが作成される場合、メディア セット パスワードは MEDIAPASSWORD オプションで指定される値に割り当てられます。
SKIP、NOSKIP、INIT、および NOINIT におけるパスワードの影響の詳細については、後の「解説」を参照してください。
バックアップ デバイスの物理ファイルに対する所有と許可の問題によって、バックアップ操作が妨げられることがあります。SQL Server では、デバイスに対して読み書きを実行できる必要があります。SQL Server サービスが実行されているアカウントには書き込み権限が必要です。ただし、システム テーブルにバックアップ デバイスのエントリを追加する sp_addumpdevice では、ファイル アクセスの権限は確認されません。バックアップ デバイスの物理ファイルに関するこのような問題は、バックアップや復元が試行され、物理リソースがアクセスされるまで、表面化しない可能性があります。
例
注意 |
---|
ここでは、AdventureWorks データベースを例に使用します。AdventureWorks は SQL Server 2005 のサンプル データベースの 1 つです。Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。このデータベースの詳細については、「AdventureWorks サンプル データベース」を参照してください。 |
ここでは、次の例について説明します。
A. データベース全体をバックアップする
B. データベースおよびログをバックアップする
C. セカンダリ ファイル グループの完全ファイル バックアップを作成する
D. セカンダリ ファイル グループの差分ファイル バックアップを作成する
E. 単一ファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する
F. マルチファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する
G. 既存のミラー化メディア セットにバックアップを作成する
H. 新しいメディア セットに圧縮されたバックアップを作成する
注意 |
---|
バックアップ方法に関するトピックで、さらに例を記載しています。詳細については、「バックアップと復元を行う方法に関するトピック (Transact-SQL)」を参照してください。 |
A. データベース全体をバックアップする
次の例では、AdventureWorks データベースをディスク ファイルにバックアップします。
BACKUP DATABASE AdventureWorks
TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
WITH FORMAT;
GO
B. データベースおよびログをバックアップする
次の例では、既定により単純復旧モデルを使用する AdventureWorks サンプル データベースをバックアップします。ここではまず、ログをバックアップするため、AdventureWorks データベースを修正して完全復旧モデルを使用するようにします。
次に sp_addumpdevice を使用して、データのバックアップ用に論理バックアップ デバイスAdvWorksData を作成し、ログのバックアップ用に別の論理バックアップ デバイス AdvWorksLog を作成します。
その後、AdvWorksData に完全データベース バックアップを作成し、更新操作の期間をおいた後、ログを AdvWorksLog にバックアップします。
-- To permit log backups, before the full database backup, modify the database
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks
SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices.
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData',
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog',
'X:\SQLServerBackups\AdvWorksLog.bak';
GO
-- Back up the full AdventureWorks database.
BACKUP DATABASE AdventureWorks TO AdvWorksData;
GO
-- Back up the AdventureWorks log.
BACKUP LOG AdventureWorks
TO AdvWorksLog;
GO
注意 |
---|
運用データベースでは、ログを定期的にバックアップしてください。ログのバックアップは、データ損失を防ぐため、頻繁に行ってください。 |
C. セカンダリ ファイル グループの完全ファイル バックアップを作成する
次の例では、両方のセカンダリ ファイル グループ内のすべてのファイルについて、完全ファイル バックアップを作成します。
--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
FILEGROUP = 'SalesGroup1',
FILEGROUP = 'SalesGroup2'
TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
GO
D. セカンダリ ファイル グループの差分ファイル バックアップを作成する
次の例では、両方のセカンダリ ファイル グループ内のすべてのファイルについて、差分ファイル バックアップを作成します。
--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
FILEGROUP = 'SalesGroup1',
FILEGROUP = 'SalesGroup2'
TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
WITH
DIFFERENTIAL
GO
E. 単一ファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する
次の例では、単一メディア ファミリと 4 つのミラーを含むミラー化メディア セットを作成し、そこに AdventureWorks データベースのバックアップを作成します。
BACKUP DATABASE AdventureWorks
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorksSet0'
F. マルチファミリ ミラー化メディア セットを作成し、そこにバックアップを作成する
次の例では、各ミラーが 2 つのメディア ファミリで構成されているミラー化メディア セットを作成します。ここでは、両方のミラーに AdventureWorks データベースのバックアップが作成されます。
BACKUP DATABASE AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorksSet1'
G. 既存のミラー化メディア セットにバックアップを作成する
次の例では、前の例で作成されたメディア セットにバックアップ セットを追加します。
BACKUP LOG AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
NOINIT,
MEDIANAME = 'AdventureWorksSet1'
注意 |
---|
NOINIT は既定値ですが、ここではわかりやすくするために記載しています。 |
[例の先頭に戻る]
H. 圧縮されたバックアップを新しいメディア セットに作成する
次の例では、メディアをフォーマットして新しいメディア セットを作成し、AdventureWorks データベースの圧縮された完全バックアップを実行します。
BACKUP DATABASE AdventureWorks TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
FORMAT,
COMPRESSION
[例の先頭に戻る]
変更履歴
変更内容 |
---|
NO_TRUNCATE オプションの説明を明確にしました。 |
関連項目