November 15, 2018 at 12:10 am
I am designing a backup strategy for one of the new applications. We have a Azure SQL server VM (IaaS) which hosts one critical ready only database and we are using SQL server 2017 version.
As a general traditional practice, we configure full, differential and log backups on our SQL server. But I am trying to challenge this idea to ourselves and answer "why do we need SQL backups when we can take VM snapshots which will serve the purpose considering its a ready only database and it is under simple recovery model"
Could anyone help me to understand why we may/have to opt for SQL server backups over VM snapshots in Azure?
November 15, 2018 at 12:40 am
Keistad - Thursday, November 15, 2018 12:10 AMI am designing a backup strategy for one of the new applications. We have a Azure SQL server VM (IaaS) which hosts one critical ready only database and we are using SQL server 2017 version.As a general traditional practice, we configure full, differential and log backups on our SQL server. But I am trying to challenge this idea to ourselves and answer "why do we need SQL backups when we can take VM snapshots which will serve the purpose considering its a ready only database and it is under simple recovery model"
Could anyone help me to understand why we may/have to opt for SQL server backups over VM snapshots in Azure?
1. In simple recovery Log backup is not possible. Differential doesn't have much changes from the last full taken. So full backup is enough.
2. For Read only Database onetime backup is enough until it is in safe place. VM snapshot takes settings level changes as well ( include SQL and windows). So in this case VM snapshot is enough.
But for Writable DB's we need Log backup for point in time recovery and recover DB with minimal data loss.
Regards
Durai Nagarajan
November 15, 2018 at 2:07 am
You are dead right! I'm just trying to see if I'll get any reason to choose SQL backups over VM snapshots.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply