Now when you schedule machine backup, and when I say machine, I say
that intentionally because, of course, we can back up Azure virtual
machines, but we can also back up physical and virtual machines in
other clouds that are on‑premises.
You orchestrate that process by means of backup policies.
When you're protecting Azure workloads,
there are four templates that you can choose from.
The traditional VM, or virtual machine, template.
Again, it's fine if it's Windows or Linux. It doesn't matter.
You can protect file shares in Azure Storage. You can protect VMs running SQL
Server. I'm not talking about Azure SQL Database or Managed Instance or
Synapse Analytics. They have their own hosted backups.
I'm talking about an Azure VM running SQL Server Database
Engine. And there's also a backup policy template for SAP
HANA, the in‑memory database.
When you think about it, if you've ever done work with databases,
you know that their backup is more than just backing up data files.
You've got to think about consistency levels.
You need to think about transaction logs. That's why
Microsoft has those special templates,
at least for SQL Server and SAP HANA. Another thing you specify in your
backup policies is your backup schedule and retention range. Of course,
the backup schedule is how often, or what is your frequency of backup,
and what is your time zone that you want that time scheduled to hit. As
far as retention goes, you set daily, the maximum number of daily,
weekly,
monthly, and yearly backup points that you want to keep. That's
going to be in line with your compliance requirements. And a
feature that I like an awful lot with the Recovery Services vault
is called instant restore.
And this is simply a way to dramatically shorten your
restore window by keeping between one and five days' worth
of your Azure VM snapshots local.
The way that Azure VM backup works is that it's a two‑step process.
There's the initial snapshot, and then asynchronously, that
snapshot gets packed into the Recovery Services vault.
Well,
it's that second step from the instant restore area to the
Recovery Services vault that's the long hop.
And if you need to restore an entire disk or an entire virtual
machine in Azure now, you can bypass that long first step, that is,
unpacking the snapshot from the RS vault into the Instant Restore
area by restoring a snapshot that's already in that Instant Restore area. Make sense?