We need a replacement for an Acronis integration across a few managed EC2 environments. Some instances run Microsoft SQL Server, so database consistency matters.
Is AWS Backup a good fit, or is a third-party platform easier to manage? We'd prefer not to maintain a lot of custom scripts or CLI automation.
For AWS-only environments, I'd start with AWS Backup. It gives you managed backup policies without building the whole scheduling system yourself. If the client accounts are in an AWS Organization, centralized policies and tags can help apply coverage across accounts.
Check the reporting and billing workflow before rolling it out across clients. Cross-account reporting may need extra work if you want to feed costs and status into an MSP billing or monitoring system. Also test restores, not just whether the jobs show as successful.
The SQL servers deserve their own restore plan. A plain EBS snapshot is crash-consistent, not necessarily application-consistent. For Windows SQL Server instances, look at AWS Backup's VSS option and check the prerequisites for using Systems Manager to coordinate it.
Another option is native SQL Server backups, including backups to S3 where the SQL Server version and configuration support that. Whichever route you choose, test restoring the database and the server, then check that the recovered data meets your recovery point and time requirements.
5b~keybasket_274:
The same crash-consistency concern applies to self-managed databases on Linux. A volume snapshot alone doesn't guarantee the database was in a clean state.
Veeam is worth considering if you also manage on-premises systems or workloads in other clouds. Keeping those backups in one familiar platform may be simpler for the team than managing a separate process for every environment.
For a small AWS-only estate, though, I'd compare that benefit against the cost and operational overhead of another product.
You could also rethink what needs an instance backup. Build an AMI with the required applications, keep persistent data in a separate store, and back up that data independently. That makes replacing an instance less dependent on restoring the whole machine.
It doesn't eliminate the need for granular recovery. Make sure the data store's backups let you recover a deleted file or database to the point in time you need. EFS and S3 aren't interchangeable for every application, so check storage access and performance requirements before moving data.
Start with the recovery point objective before picking a product. If you need less than an hour of potential data loss, check whether the scheduled backup frequency is enough and whether point-in-time recovery is available for the specific workload.
Also check what happens to recovery data when the source resource is deleted. A separate snapshot and deletion protection may be relevant, but verify the behavior for each service rather than assuming all AWS backups work alike.
Answers are reviewed before publication.
5q!ticketpunch_827:
Good point on reporting. We'd need a clear way to see which client resources are actually covered.