SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

RDS for SQL Server でネイティブバックアップ/リストアがサポートされたので軽くメモを

leave a comment

Amazon RDS for SQL Server – Support for Native Backup/Restore to Amazon S3 でアナウンスされていますが、AWS の RDS for SQL Server で、S3 上へのネイティブアックアップ/リストアがサポートされたようです。

msdb に 4 個のストアドプロシージャが追加され、これらを使用することで S3 上にバックアップを取得/バックアップからリストアできるようになったようですね。

.rds_backup_database – Back up a single database to an S3 bucket.
•rds_restore_database – Restore a single database from S3.
•rds_task_status – Track running backup and restore tasks.
•rds_cancel_task – Cancel a running backup or restore task.

バックアップ / リストアの基本的な構文は以下のようになります。

exec msdb.dbo.rds_backup_database 
@source_db_name='<DB 名>', 
@s3_arn_to_backup_to='arn:aws:s3:::<バケット名>/<バックアップファイル名>',
@overwrite_S3_backup_file=1;


exec msdb.dbo.rds_restore_database 
@restore_db_name='<DB 名>', 
@s3_arn_to_restore_from='arn:aws:s3:::<バケット名>/<バックアップファイル名>',;

これで、SQL Server 標準のバックアップファイル (.bak) を S3 上に格納, S3 上にアップロードしたバックアップファイルをリストアというようなことを行うことができます。

注意しておいた方がいい点としては、以下のような制約があることでしょうか。

The following are some limitations to using native backup and restore:

  • Native backup and restore for SQL Server is not supported on the db.t1.micro DB instance class. For more information about instance classes, see Specifications for All Available DB Instance Classes.
  • You can’t restore a backup file to the same DB instance that was used to create the backup file. Instead, restore the backup file to a new DB instance. Renaming the database is not a workaround for this limitation.
  • You can’t restore the same backup file to the same DB instance multiple times. Renaming the database is not a workaround for this limitation.
  • You can’t back up databases larger than 1 TB.
  • You can’t restore databases larger than 4 TB.
  • You can’t back up a database during the maintenance window, or any time Amazon RDS is in the process of taking a snapshot of the database.

同一のインスタンスにリストアができない / DB 名を変更することは、この制限の回避策ではないというような記載がされていますのでこの点は注意しておいた方がよいかと。

軽く触ってみた感じでは、既存 DB への上書きリストア / 元になった DB が存在している状態での、他の DB 名としてのリストアは実施できないようでしたので、バックアップを取得したインスタンスでリストアを行う際には、この辺の動作は注意しておいた方がよいかと。

# バックアップを取得した DB を削除してリストア / バックアップを取得した DB を削除して別名としてリストアは実施できるようですが。

バックアップとリストアでは、実際には以下のようなクエリが実行されています。

データベースのファイルについては、元のファイル名と同じ名称で「D:\rdsdata\data」に移動する形で、リストアを行っています。これにより、ユーザーが自分の環境で取得したデータベースのバックアップについても、必ず D ドライブにリストアが行われるようになっています。

仮想デバイスに対してバックアップを取得しているようですので、VDI の仕組みを利用して S3 と連携しているのかもしれないですね。

BACKUP DATABASE [test] TO VIRTUAL_DEVICE='F4168F7D-908C-45D4-A75F-7FC900971CB1' WITH STATS = 5;

RESTORE DATABASE [test] FROM VIRTUAL_DEVICE='F4168F7D-908C-45D4-A75F-7FC900971CB1' 
WITH STATS = 5, MAXTRANSFERSIZE = 4194304, BUFFERCOUNT = 10, 
MOVE 'test' TO 'D:\rdsdbdata\DATA\test.mdf',
MOVE 'test_log' TO 'D:\rdsdbdata\DATA\test_log.ldf';

「exec msdb.dbo.rds_task_status」で、バックアップ時に出力されているメッセージを確認できるのですが、以下のようなメッセージが出力されているようです。

Task execution has started. 5 percent processed. 
testdb.bak: Completed processing 5% of S3 chunks. 10 percent processed. 
testdb.bak: Completed processing 10% of S3 chunks. 15 percent processed. 
testdb.bak: Completed processing 15% of S3 chunks. 20 percent processed. 
testdb.bak: Completed processing 20% of S3 chunks. 25 percent processed. 
testdb.bak: Completed processing 25% of S3 chunks. 30 percent processed. 
testdb.bak: Completed processing 30% of S3 chunks. 35 percent processed. 
testdb.bak: Completed processing 35% of S3 chunks. 40 percent processed. 
testdb.bak: Completed processing 40% of S3 chunks. 45 percent processed. 
testdb.bak: Completed processing 45% of S3 chunks. 50 percent processed. 
testdb.bak: Completed processing 50% of S3 chunks. 55 percent processed. 
testdb.bak: Completed processing 55% of S3 chunks. 60 percent processed. 
testdb.bak: Completed processing 60% of S3 chunks. 65 percent processed. 
testdb.bak: Completed processing 65% of S3 chunks. 70 percent processed. 
testdb.bak: Completed processing 70% of S3 chunks. 75 percent processed. 
testdb.bak: Completed processing 75% of S3 chunks. 80 percent processed. 
testdb.bak: Completed processing 80% of S3 chunks. 85 percent processed. 
testdb.bak: Completed processing 85% of S3 chunks. 90 percent processed. 
testdb.bak: Completed processing 90% of S3 chunks. Processed 1248512 pages for database 'testdb', file 'testdb' on file 1. 95 percent processed. 
testdb.bak: Completed processing 95% of S3 chunks. 100 percent processed. Processed 118958 pages for database 'testdb', file 'testdb_log' on file 1. BACKUP DATABASE successfully processed 1367470 pages in 1099.549 seconds (9.716 MB/sec). 
testdb.bak: Completing S3 upload, waiting for S3 workers to clean up and exit 
testdb.bak: Final chunk written to S3 successfully. 
testdb.bak: S3 processing completed successfully Command execution completed successfully.

 

この機能では、ユーザーが任意の環境で取得したバックアップについてもリストアをすることができるようになっています。

その場合は、以下のようなクエリが実行されています。

ユーザーが、自分が使用しているインスタンスのバックアップを RDS にリストアしたような場合は、DB の所有者が RDS に存在しているログインになっていません。

その補正をするためのクエリが、リストアが完了した後に実行されています。

USE [ADK_Restore];

ALTER AUTHORIZATION ON DATABASE::[ADK_Restore]  TO [rdsa];

IF EXISTS (select * from sys.database_principals where name = N'<管理者ログイン>')
BEGIN
 ALTER USER [<管理者ログイン>] WITH Login = [<管理者ログイン>];
END
ELSE
BEGIN
 CREATE USER [<管理者ログイン>] FOR Login [<管理者ログイン>];
END

EXEC sp_addrolemember 'db_owner', N'<管理者ログイン>';

GRANT CONNECT TO [<管理者ログイン>];

 

現状、RDS の通常のバックアップは以下のような、実ファイルへのバックアップと、スナップショットのバックアップを組み合わせていたはずなのですが、ユーザーが任意に取得できる  DB 単位のバックアップも含めると、いろいろな機能を組み合わせて実装しているようですね。

BACKUP DATABASE [model] TO VIRTUAL_DEVICE='{EAAAD339-EF61-4861-95AA-BDD35D00BEB7}1' WITH SNAPSHOT,BUFFERCOUNT=1,BLOCKSIZE=1024
RESTORE VERIFYONLY FROM VIRTUAL_DEVICE='{CE16A5E8-70A9-4BC1-8E96-DE1ABBA4638A}' WITH SNAPSHOT,COMMIT_DIFFERENTIAL_BASE,BUFFERCOUNT=1,BLOCKSIZE=1024
BACKUP LOG [test2] TO DISK = 'D:\RDSDBDATA\BACKUP\d8df4a62-dff7-4365-933f-f974d4f76e4c.2.1469715541.extracted_txn_log' WITH INIT, RETAINDAYS = 36, NOSKIP, NOFORMAT
BACKUP DATABASE [test3] TO DISK = 'D:\RDSDBDATA\BACKUP\282ad614-3cf2-4dda-9a5f-07d7b28a601a.1469722797.database_backup' WITH FORMAT

Written by masayuki.ozawa

7月 29th, 2016 at 1:34 am

Posted in AWS,SQL Server

Tagged with ,

Leave a Reply

*