Here are some notes from the field…

  1. For PROD environments, use Multi-AZ deployment (mirroring) and provisioned IOPS. It is much harder to change this after the fact – if you want to ‘upsize’ your RDS instance.
  2. Recreating a prod environment from a dev or staging environment (Create a backup, restore a database from backup – Read this post )
  3. Pushing large amounts of data into an RDS instance – using SQL Bulk Copy (bcp) – read this post.

Backup and Restore in RDS

Restoring from a backup essentially involves dropping your existing RDS instance and creating a new one. This has implications. The endpoint address associated with your original RDS instance is lost in this process – and you will need to remap (anything using that instance) to the new URL.

What can you NOT do with RDS?

  • You can’t copy, paste or create files in the underlying disk system. If your on-site DB server has non-SQL related files on disk, they can’t be ported across.
  • You can’t run batch files, Windows Command Shell files or PowerShell scripts in the host.
  • You can’t directly monitor disk space, CPU usage or memory usage from the host. AWS provides a different way for monitoring.
  • You can’t copy backup files into the local disk from another location and restore databases from there.
  • You can’t decide which drive your database files go to, AWS has a default location for that.

Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

Initial Consultation

Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

 Twitter Linkedin