Snapshots and Replication and Backups, Oh my!
At times we undervalue our many experiences in the data center (aka on-premises) world and how they translate directly into the Cloud. One such experience is understanding what’s behind the curtain when it comes to protecting your AWS data sources. Or, you think you understand your current strategy but are unaware of other options available to you. When we dive in we often learn customers are confused by the differences among snapshots, replication and backups. I have learned this through countless sales calls in which I have an opportunity to coach companies through their application’s data storage, protection and recovery options.
Snapshots for in account operational recovery
Snapshots are the jumping-off point for most data protection and recovery discussions. A snapshot can be created manually via the AWS console or fully automated. Automation can be scheduled via scripts or as part of an AWS Backup plan’s scheduler. Snapshots are great for operational recovery, however, they do require a series of steps to promote them into a usable volume or database. One other gap is that snapshots are not easily portable across accounts or regions for out-of-account/region recoveries. Recovering a single file, directory or database record out of a snapshot can also be cumbersome, taking several steps and plenty of time to make such a granular recovery.
From a security standpoint, make sure you are protecting your snapshots, because they can be one of many targets hackers look for in your accounts. Snapshots can be accessed, copied, turned into volumes or databases and have sensitive data stolen from them. Snapshots can also be deleted, which would negate your ability to recover or meet long-term compliance retention requirements. To secure your snapshots, copy them to a highly secure secondary account, preferably outside your production AWS account(s).
Replication for production outage failovers to alternate accounts/regions
Another strategy being used for protection and recovery is real-time or near real-time replication of production data. As updates are made to production data, updates are pushed to replica copies in other accounts or regions as quickly as possible. Having replicated data is a great strategy for quick failovers to a secondary location when a disaster hits your primary production environment. However, it requires lots of work and planning to be able to quickly promote a secondary site to production. Applications need to be distributed across multiple accounts/regions, networking needs to be available for client access, and you need to ensure you are operating in a highly secure environment.
While replication is great, there are some scenarios that may make your replicated data unusable. If data is corrupted, ransomed or deleted at the source location, you should expect your data to be in the same state in your secondary location. When this happens you need a point-in-time copy of your data in a secure location that can be restored back into your production environments. This is why even if you are using a replication solution, you also need a good backup solution as part of your Business Continuity Disaster Recovery plans.
Backups for restoring data from a known good point in time
Backup is a third strategy for data protection. Scheduled backups of your important data sets allow you to restore your data to a previously known good state. A backup solution should ensure your backups are secure from intentional or accidental deletions, hackers and other bad motives. In the cloud, this would mean sending your backups to a “bunker” or “vault” which is segregated from all of your other accounts. This bunker account should also be highly secure, with minimal access and locked-down networking. Encryption should be enabled for backups landing in this bunker account. When it comes time to recover, ensure you have a process that allows you to easily find the backups you need and quickly restore them. It is also important to be able to quickly and efficiently restore to the account/region where you will be recovering your applications.
Clumio is a SaaS platform that falls into the backup solutions category. We provide scheduled backups of cloud data sources like Amazon S3, DynamoDB, RDS, EC2, EBS, SQL Server on Amazon EC2, and Microsoft 365. Configure the backup schedules to meet your recovery point objectives; one backup a day or multiple per day, the choice is yours. An added benefit of Clumio SecureVault backups is that they are air-gapped out of your accounts. Don’t worry about securing and locking down your accounts; we take care of that as part of our service. When you need to perform a recovery, your data is safe with us and can be recovered to any account or region that you have connected to the Clumio SecureVault service. Restore at any granularity you want – a file, database record, a single object or complete instances; the choice is yours.
Every protection strategy has its place but they are not all equal. While there are circumstances and exceptions to everything, you can generally follow these simplified guidelines:
Use snapshots for quick operational recovery within your production accounts.
Replication is for real-time updates to a secondary site to be used for failovers when regional service disasters strike.
Scheduled backups are for when your data is in catastrophe mode and you need to recover from a known good point in time – hours ago or days ago.
When deciding on your protection strategy, make sure you are digging into the expectations of the business teams you are supporting. They are the folks feeling the pain of revenue loss when they don’t have the data they need.