Inspired by Tara Kizer and Brent Ozar, I decided to dip my toe into Amazon Relational Database Services (RDS) on Amazon Web Services (AWS). It's a no brainer - when I signed up I got 750 hours of RDS per month for free. That's a lot of playground time for a year.
I was afraid of being charged for a production grade RDS SQL Server, so I decided to create a SQL Server Express instance with 20 GB of storage. It was very easy to provision the instance - just make a few selections and it was ready for me to connect to it from my laptop's SQL Server Management Studio (SSMS) within minutes. It looked almost like any database instance. The user account you define for the instance does not have sysadmin rights - it has processadmin rights. But I was curious about whether the RDS instance would allow me to do my day-to-day SQL tasks.
So I tried to restore my local database to the RDS instance, AWS would not let me restore a bak file from my computer, see the lovely error message:
Though I was able to connect to the RDS database with SSMS installed locally on my computer, it did not allow me to browse my local computer directory for the bak to restore. Instead, I created a new database in the RDS instance and used export to copy tables from the local database to the AWS instance.
I did a restore to a point in time, which is an instance restoration. Brent Ozar was right about RDS not having a progress meter. I had no idea where we were in the restore process. How I truly appreciate the progress meter in SSMS. More than 30 minutes later, I still had no idea how much longer the restore would take. In Tara's blog post, her restore took approximately 30 minutes and it was a production grade server in edition and disk size. My instance restore completed after 43 minutes. The instance was small so the amount of time it took was surprising given the ease in which one can fire up an RDS instance. It was my first time playing with an RDS instance and it would be worthwhile to see if subsequent restores take just as long.