So many corporate applications still require very traditional architectures- servers with specified roles, running all the time. These applications, as written, can’t leverage a cloud-native architecture (serverless, etc).
For these traditional applications, Azure Virtual Machines and AWS EC2 can be a reasonable fit.
Server backups are one part of the discussion for bringing traditional applications to the cloud. Here’s how AWS and Azure have to offer for backups out of the box.
AWS provides snapshotting of EC2 volumes. Now, these snapshots are not application aware, meaning that if you have a database mid-transaction when the snapshot is taken, this snapshotted database could be in an inconsistent state.
It’s generally advised to stop IO to the volume or have it dismounted before snapshotting. That’s not great, right?
Also, EC2 currently doesn’t have a method for regularly scheduling snapshots within the console. Boto3, A Python SDK, is offered for this. A scheduled task with the AWS Tools for Powershell is another common method for kicking off. But no regular scheduling in the console.
For the two reasons above, you’ll find that third party solutions have cropped up to address the application aware shortfall. Also, it’s not unheard of for traditional backup strategies to be used in AWS along with snapshotting.
Azure actually has an adequate answer for this. Windows virtual machine backups are natively application aware.
Also, it’s actually possible to specify a backup policy for the virtual machine, with a scheduled events and a retention policy.
There is also an option to leverage Powershell trigger backups of VMs programmatically as with AWS.
All in all, while both cloud providers have a way of getting backups done, it seems Azure comes out stronger when comparing backup capabilities of traditional Windows infrastructure.
JUSTIN | BLOG 