![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Hello<\/p>\n
<\/p>\n
j’ai eu r\u00e9cemment \u00e0 effectuer, aupr\u00e8s d’un de mes clients, une op\u00e9ration de backup restore SQL Server d’une instance SQL Server Amazon RDS vers une instance IaaS sur une EC2 Amazon.
\nRappelons qu’en mode RDS, le client n’a pas la main, ni sur les disques utilis\u00e9s par l’instance SQL Server, ni m\u00eame sur les backup automatiques g\u00e9n\u00e9r\u00e9s par AWS.<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/SQL-bak-file.png\")
<\/p>\n
<\/p>\n
Sur Amazon RDS, une base de donn\u00e9es sera accessible gr\u00e2ce aux informations du “endpoint” et du port de communication.
\nDans notre exemple, nous avons cr\u00e9\u00e9 une instance nomm\u00e9e “capdatasqlserver” avec pour \u00e9dition SQL Server 2016 Express Edition.<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/endpoint.jpg\")
<\/p>\n
Afin de pouvoir effectuer ces op\u00e9rations de backup restauration rds <-> IaaS, il faudra respecter les pr\u00e9requis suivants :<\/p>\n
<\/p>\n
Pour la cr\u00e9ation d’un bucket S3, nous nous connecterons avec un utilisateur ayant les strat\u00e9gies ad\u00e9quat pour configurer le service S3. Cette \u00e9tape peut aussi bien \u00eatre faite via la console Amazon ou bien via AWS CLI :<\/p>\n
c:\\ aws s3api create-bucket --bucket capdatabackup2019 --region eu-west-3 --create-bucket-configuration LocationConstraint=eu-west-3<\/em>\r\n\r\n{<\/em>\r\n\"Location\": \"https:\/\/capdatabackup2019.s3.amazonaws.com\/\"<\/em>\r\n}<\/em><\/pre>\nOn v\u00e9rifiera la cr\u00e9ation :<\/p>\n
c:\\ aws s3api list-buckets --query \"Buckets[?contains(Name,'backup')]\"\r\n[\r\n{\r\n\"CreationDate\": \"2019-02-07T09:44:53.000Z\",\r\n\"Name\": \"capdatabackup2019\"\r\n}\r\n]\r\n\r\n<\/pre>\nLe groupe d’options<\/h4>\n
La cr\u00e9ation d’un nouveau groupe d’options sera n\u00e9cessaire pour effectuer ces op\u00e9rations backup restore<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/groupotpion.jpg\")
<\/p>\n
la version 13.00 correspond \u00e0 SQL Server 2016<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/groupeoption2016.jpg\")
<\/p>\n
<\/p>\n
Avec AWS CLI, nous utiliserons la syntaxe suivante :<\/p>\n
aws rds create-option-group --option-group-name capdataoptionssql2016 --engine-name sqlserver-ex --major-engine-version 13.00 \r\n--option-group-description \"groupe d'option pour SQL Server 2016\" --region eu-west-3\r\n\r\n<\/pre>\nOn ajoute ensuite l’option SQLSERVER_BACKUP_RESTORE<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/ajoutoption.jpg\")
<\/p>\n
La page suivante nous permettra d’ajouter l’option, choisir le r\u00f4le (ou en cr\u00e9er un nouveau), puis chosir le bucket (ou en cr\u00e9er un).<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/newopt.jpg\")
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/rolebackup.jpg\")
<\/p>\n
On choisit le bucket que l’on a cr\u00e9\u00e9 au premier paragraphe (\u00e0 noter que l’on aurait pu en cr\u00e9er un nouveau).<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/bucketabackup.jpg\")
<\/p>\n
<\/p>\n
Le r\u00f4le IAM<\/h4>\n
En th\u00e9orie, ce r\u00f4le a \u00e9t\u00e9 cr\u00e9\u00e9 lors de la page d’ajout de l’option. Mais vous pouvez tr\u00e8s bien l’avoir cr\u00e9\u00e9 en avance de phase. Dans tous les cas, ce r\u00f4le devra avoir :<\/p>\n
une strat\u00e9gie d’approbation pour les backup et restore natifs avec le JSON suivant :<\/p>\n
{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Effect\": \"Allow\",\r\n \"Principal\": {\r\n \"Service\": \"rds.amazonaws.com\"\r\n },\r\n \"Action\": \"sts:AssumeRole\"\r\n }\r\n ]\r\n}<\/pre>\nEt une strat\u00e9gie d’autorisation pour les backup \/ restore natifs.<\/p>\n
<\/p>\n
{\r\n \"Version\": \"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Effect\": \"Allow\",\r\n \"Action\": [\r\n \"s3:ListBucket\",\r\n \"s3:GetBucketLocation\"\r\n ],\r\n \"Resource\": [\r\n \"arn:aws:s3:::capdatabackup2019\"\r\n ]\r\n },\r\n {\r\n \"Effect\": \"Allow\",\r\n \"Action\": [\r\n \"s3:GetObjectMetaData\",\r\n \"s3:GetObject\",\r\n \"s3:PutObject\",\r\n \"s3:ListMultipartUploadParts\",\r\n \"s3:AbortMultipartUpload\"\r\n ],\r\n \"Resource\": [\r\n \"arn:aws:s3:::capdatabackup2019\/*\"\r\n ]\r\n }\r\n ]\r\n}<\/pre>\nIl restera ensuite \u00e0 modifier l’instance SQL Server afin de pouvoir lui affecter ce nouveau groupe d’options “capdataoptionssql2016”. Ceci se fera en s\u00e9lectionnant l’instance et cliquer sur “modifier”.<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/chageoption.jpg\")
<\/p>\n
En mode AWS Cli, nous devrons cr\u00e9er le r\u00f4le avant de modifier le groupe d’options. De ce fait, nous n’aurons pas \u00e0 renseigner le bucket car c’est celui qui est dans le r\u00f4le qui sera pris en compte.
\n2 documents JSON seront cr\u00e9\u00e9s pour la relation d’approbation et la strat\u00e9gie d’autorisation.<\/p>\n
c:\\ aws iam create-role --role-name rolebackupSQL2016<\/a>--assume-role-policy-document file:\/\/Roles\\Relation_Approbation.json<\/pre>\nc:\\ aws iam put-role-policy --role-name rolebackupSQL2016<\/a> --policy-name sqlNativeBackup-2019-02-07<\/a>--policy-document file:\/\/Strategies\\strat\u00e9gies.json\r\n\r\n<\/pre>\nOn ira ensuite modifier le groupe d’options<\/p>\n
c:\\ aws rds add-option-to-option-group --option-group-name capdataoptionssql2016 --apply-immediately --options \"OptionName=SQLSERVER_BACKUP_REST\r\nORE,OptionSettings=[{Name=IAM_ROLE_ARN,Value=arn:aws:iam::018033502850:role\/service-role\/rolebackupSQL2016}]\" --region eu-west-3\r\n\r\nc:\\ aws rds modify-db-instance --db-instance-identifier capdatasqlserver --option-group-name capdataoptionssql2016 --apply-immediately --region eu-west-3\r\n\r\n<\/pre>\n <\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/recapmodif.jpg\")
<\/p>\n
<\/p>\n
<\/p>\n
Sauvegarde de la base RDS<\/h3>\n
Les pr\u00e9requis \u00e9tant effectu\u00e9s, on passera \u00e0 la sauvegarde de la base RDS. Nous utiliserons un client sur lequel SSMS est install\u00e9.<\/p>\n
La connexion \u00e0 notre instance RDS se fera gr\u00e2ce au endpoint fourni au d\u00e9but avec le port par d\u00e9faut.<\/p>\n
les commandes list\u00e9es ci dessous seront \u00e0 ex\u00e9cuter sur SSMS.<\/p>\n
A noter que par d\u00e9faut, il existe sur notre instance une base nomm\u00e9 “rdsadmin”. Celle ci est utilis\u00e9e par Amazon afin de stocker des proc\u00e9dures sp\u00e9cifiques \u00e0 Amazon ( un peu comme le package RDSADMIN sur une base Oracle RDS). Amazon y stocke \u00e9galement des tables et objets propri\u00e9taire.
\nIl est donc vivement conseill\u00e9 de ne PAS utiliser cette base pour \u00e9crire des donn\u00e9es m\u00e9tier, et de cr\u00e9er une autre base.<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/rdsadmin.jpg\")
<\/p>\n
<\/p>\n
On cr\u00e9era une nouvelle base, nomm\u00e9e “capdata_db” pour illustrer notre exemple :<\/p>\n
CREATE DATABASE [capdata_db]\r\nCONTAINMENT = NONE\r\nON PRIMARY \r\n( NAME = N'capdata_db', FILENAME = N'D:\\RDSDBDATA\\DATA\\capdata_db.mdf' , SIZE = 20480KB , MAXSIZE = 512000KB , FILEGROWTH = 10%)\r\nLOG ON \r\n( NAME = N'capdata_db_log', FILENAME = N'D:\\RDSDBDATA\\DATA\\capdata_db_log.ldf' , SIZE = 10240KB , MAXSIZE = 204800KB , FILEGROWTH = 10%)\r\nGO<\/pre>\nA noter que l’on ne pourra pas modifier le FILENAME, nous sommes sur RDS.!<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/capdata_db.jpg\")
<\/p>\n
Nous donnerons les droits, \u00e0 notre utilisateur “capdata”, pour effectuer des backup et restauration sur cette base.<\/p>\n
USE [capdata_db]\r\nGO\r\nALTER ROLE [db_backupoperator] ADD MEMBER [capdata]\r\nGO\r\n\r\n\r\n<\/pre>\nBackup<\/h4>\n
A partir de la, nous pourrons lancer la proc\u00e9dure “rds_backup_database” :<\/p>\n
exec msdb.dbo.rds_backup_database \r\n@source_db_name='capdata_db',\r\n@s3_arn_to_backup_to='arn:aws:s3:::capdatabackup2019\/backupCapdataDB.bak',\r\n@overwrite_S3_backup_file=1,\r\n@type='FULL';<\/pre>\nOn pourrait \u00e9galement ajouter le chiffrement avec l’option “@kms_master_key_arn=’arn:aws:kms:region<\/code><\/em>:account-id<\/code><\/em>:key\/key-id<\/code><\/em>‘,”<\/p>\nLe backup de la base “capdata_db” est r\u00e9alis\u00e9 sur le bucket s3 nomm\u00e9 “capdatabackup2019”<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/backup_bucket.jpg\")
<\/p>\n
Dans notre exemple, nous faisons un backup FULL, il sera \u00e9galement possible de faire un backup incremental ou transaction log.<\/p>\n
On pourra suivre l’\u00e9volution du processus avec<\/p>\n
exec msdb.dbo.rds_task_status @db_name=’capdata_db’;<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/success_backup-1024x64.jpg\")
<\/p>\n
<\/p>\n
La partie on-premise \/ IaaS<\/h2>\nTransfert du fichier de backup<\/h4>\n
Nous irons voir sur le bucket la pr\u00e9sence du fichier de backup pour le transf\u00e9rer par la suite :<\/p>\n
c:\\ aws s3 ls \"s3:\/\/capdatabackup2019\/\"\r\n2019-02-07 13:44:23 2904576 backupCapdataDB.bak<\/pre>\nOn passera au transfert du fichier .bak sur un disque local de notre EC2.
\nNous prenons en compte le fait que sur notre EC2, il existe une installation de SQL Server avec une instance pouvant accueuillir la nouvelle base “capdata_db”.<\/p>\n
c:\\ aws s3 cp \"s3:\/\/capdatabackup2019\/backupCapdataDB.bak\" c:\\users\\manu\\backupCapdataDB.bak\r\ndownload: s3:\/\/capdatabackup2019\/backupCapdataDB.bak to ..\\users\\manu\\backupCapdataDB.bak<\/pre>\navec<\/p>\n
C:\\ dir c:\\users\\manu\r\n\r\nDirectory of c:\\users\\manu\r\n\r\n02\/07\/2019 01:55 PM <DIR> .\r\n02\/07\/2019 01:55 PM <DIR> ..\r\n02\/07\/2019 01:44 PM 2,904,576 backupCapdataDB.bak<\/strong>\r\n01\/23\/2019 02:42 PM 32 check_dispo.txt\r\n2 File(s) 2,904,608 bytes\r\n2 Dir(s) 11,426,086,912 bytes free<\/pre>\nOn copiera ce fichier dans le r\u00e9pertoire d\u00e9di\u00e9 aux backup SQL Server de notre instance (ici C:\\Program Files\\Microsoft SQL Server\\MSSQL14.SQLEXPRESS\\MSSQL\\Backup).<\/p>\n
Restauration<\/h4>\n
Nous pourrons restaurer notre base de donn\u00e9es SQL Server sur notre instance locale de mani\u00e8re conventionnelle comme ceci se fait habituellement sur un syst\u00e8me On-premise :<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/instance_on_premise.jpg\")
<\/p>\n
<\/p>\n
On pousse la restauration<\/p>\n
USE [master]\r\nRESTORE DATABASE [capdata_db] \r\nFROM DISK = N'C:\\Program Files\\Microsoft SQL Server\\MSSQL14.SQLEXPRESS\\MSSQL\\Backup\\backupCapdataDB.bak' WITH FILE = 1, \r\nMOVE N'capdata_db' TO N'C:\\Program Files\\Microsoft SQL Server\\MSSQL14.SQLEXPRESS\\MSSQL\\DATA\\capdata_db.mdf', \r\nMOVE N'capdata_db_log' TO N'C:\\Program Files\\Microsoft SQL Server\\MSSQL14.SQLEXPRESS\\MSSQL\\DATA\\capdata_db_log.ldf', \r\nNOUNLOAD, STATS = 5\r\nGO<\/pre>\nLa base a \u00e9t\u00e9 restaur\u00e9e \u00e0 partir des informations suivantes lus dans le fichier de backup<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/info_restore.jpg\")
<\/p>\n
Notre base est maintenant pr\u00e9sente sur notre instance on-premise ou IaaS<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/instance_on_prem_restau-300x179.jpg\")
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/etat_base.jpg\")
<\/p>\n
<\/p>\n
Et inversement ?<\/h2>\n
En effet, il est tout \u00e0 fait possible de faire le chemin inverse, d’ailleurs cela se fait d’avantage chez de nombreux clients, \u00e0 savoir, pousser un backup de base de donn\u00e9es d’une base On-premise vers une nouvelle instance RDS.<\/p>\n
Nous partirons du fait que le sujet des pr\u00e9requis \u00e9voqu\u00e9s ci dessus est trait\u00e9 sur notre syst\u00e8me AWS.<\/p>\n
\/!\\ \/!\\ Attention, dans notre exemple, nous avons une instance On premise version SQL Server 2017, or sur\u00a0 l’instance RDS, dans notre exemple, cest une SQL 2016. Il ne sera donc pas possible d’effectuer une restauration de cette mani\u00e8re. Penser \u00e0 mettre \u00e0 jour votre instance SQL Server RDS avant.<\/p>\n
les \u00e9tapes seront alors, les suivantes :<\/p>\n
\n- Effectuer un backup d’une base “On-premise\/IaaS” que nous appellerons “manuelo”<\/li>\n<\/ul>\n
BACKUP DATABASE [manuelo] \r\nTO DISK = N'C:\\Program Files\\Microsoft SQL Server\\MSSQL14.SQLEXPRESS\\MSSQL\\Backup\\manuelo.bak'\r\nWITH FORMAT, INIT, MEDIANAME = N'backup_test_RDS', \r\nNAME = N'manuelo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10\r\nGO<\/pre>\n <\/p>\n
\n- Transfert du fichier .bak vers notre bucket s3<\/li>\n<\/ul>\n
C:\\ aws s3 cp manuelo.bak \"s3:\/\/capdatabackup2019\"\r\nupload: .\\manuelo.bak to s3:\/\/capdatabackup2019\/manuelo.bak<\/pre>\nOn s’assure que le transfert s’est correctement effectu\u00e9<\/p>\n
C:\\ aws s3 ls \"s3:\/\/capdatabackup2019\/\"\r\n2019-02-07 13:44:23 2904576 backupCapdataDB.bak\r\n2019-02-07 14:33:36 3037696 manuelo.bak<\/pre>\n <\/p>\n
\n- Restauration du backup sur l’instance RDS<\/li>\n<\/ul>\n
On se connectera via SSMS sur notre instance en renseignant le “endpoint”.<\/p>\n
Puis nous utiliserons la proc\u00e9dure de restauration nomm\u00e9e<\/p>\n
“exec msdb.dbo.rds_restore_database”. Dans notre exemple, ce sera :<\/p>\n
<\/p>\n
exec msdb.dbo.rds_restore_database \r\n@restore_db_name='manuelo', \r\n@s3_arn_to_restore_from='arn:aws:s3:::capdatabackup2019\/manuelo.bak';\r\n\r\n<\/pre>\nDans cet exemple, il est \u00e9galement possible d’utiliser le chiffrement\u00a0 avec l’option<\/p>\n
@kms_master_key_arn=’arn:aws:kms:region<\/code><\/em>:account-id<\/code><\/em>:key\/key-id<\/code><\/em>‘;<\/p>\n <\/p>\n
Nous pourrons \u00e9galement suivre le processus avec msdb.dbo.rds_task_status :<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/resto_in_prog.jpg\")
<\/p>\n
Une fois termin\u00e9<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/02\/instance_finale.jpg\")
<\/p>\n
<\/p>\n
N’h\u00e9sitez pas \u00e0 laisser des commentaires si besoin.<\/p>\n
<\/p>\n
Emmanuel RAMI<\/p>\n
<\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"Hello j’ai eu r\u00e9cemment \u00e0 effectuer, aupr\u00e8s d’un de mes clients, une op\u00e9ration de backup restore SQL Server d’une instance SQL Server Amazon RDS vers une instance IaaS sur une EC2 Amazon. Rappelons qu’en mode RDS, le client n’a… Continuer la lecture