Last year Sitecore announced it supports AWS RDS. I’ve previously blogged about how to setup Sitecore databases in AWS using SIF. Containers are the preferred deployment model in Sitecore 10 now. A popular option when deploying Sitecore on AWS is to use RDS instead of Containers for the SQL Databases. In this case it can be a little bit challenging to figure out how to get the databases in RDS. This blog will walk through a sample solution.

Step 1: Take a backup of the databases

Take a backup of the databases, for example from a development environment VM which has the databases installed. Sitecore 10 comes with a Graphical setup package which is great to quickly setup a new Sitecore 10 environment including databases.

Step 2: Upload to S3

At this point you should have a backup of all your databases in a .bak format. Upload all these databases to AW S3. Make sure the S3 bucket is in the same region as your RDS database instance.

Step 3: Restore Databases through RDS’ SP

Databases need to be restored through RDS’ Stored Procedures. This page has a detailed overview but restoring a database can be done through the rds_restore_database SP. It is recommended to not change the database name during restore as it can cause some issues, see troubleshooting section for more details. See example below:

exec msdb.dbo.rds_restore_database 
	@restore_db_name='database_name', 
	@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name.extension',
	@with_norecovery=0|1,
	[@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'],
	[@type='DIFFERENTIAL|FULL'];

Troubleshooting

A few common issues can occur during this process:

• Contained database issues: in RDS you cannot enable contained database authentication through sp_configure stored procedure. Instead it needs to be set on the parameter group, see my other blog post for more details.
• Issues with xDB containers not getting healthy: if the databases were renamed during the restore there is a good chance some of the xDB roles will not get healthy. The Xdb.Collection.ShardMapManager database has some tables which contain rows with connection info including names of other databases which contain the shards. If the databases have been renamed while they have been restored then this connection info will be incorrect. This can be fixed manually or through the SQL Sharding Deployment Tool.