(uplifting music)
- Hello, everyone.
Welcome to the video series
on Azure Backup for SAP HANA databases on Azure VM.
My name is Pradeep Saran.
I'm one of the product managers for business continuity
and disaster recovery for databases.
So the agenda that we have today
is we want to cover insights into Azure Backup service,
and we are going to talk about some of the capabilities
that we have around workload protection.
And I'm going to give you a quick demo
of SAP HANA database's snapshot capability,
and we'll touch base on cost optimization
and ransomware protection.
So let's see how we protect the diverse set
of workloads in Azure.
So bottom up, if you can see
the native workload integration that we have,
Azure today supports wide variety of workloads,
and we are constantly adding new workload support regularly.
When we take a backup and then move the backup
to the data plane through secure channels,
we use private endpoints, we use NSG,
which is network security groups and Azure firewalls.
And once the data gets moved to the data plane,
it gets stored in multiple tiers.
So we have the snapshot tier,
which is basically used
for when we snapshot the databases,
and we have the standard tier
where we store the regular backups.
This standard tier is completely isolated
from the customer tenants,
and then we provide additional security elements to that.
And we also introduce archival tier,
which is basically used for long-term retention.
And coming to the availability levels,
we have LRS, ZRS and (RA-)GRS,
and we also provide built-in security.
We provide additional capabilities around RBAC
where you can grant owner permissions to your admins.
And we also provide encryption
where you can bring your own customer-managed keys
and other capabilities around Soft-Delete MUA,
which is multi-user authorization and immutability
and so on and so forth.
Now, moving on to the management plane
where you can basically configure access,
and manage all your backups in one single place,
and we also provide that built-in management at scale view.
So where you can see or manage your workloads
across different walls and different subscriptions as well.
So let's see what we are doing for workload protection.
So there are two options
in terms of when you're trying to backup
SAP HANA databases running in Azure VM.
One is stream-based backup
and the other one is snapshot-based backup.
So let's get started with stream-based backup.
So, when backups are streamed out of the database engine,
and it's basically returned to Azure managed storage,
which is recovery services vault, we call it.
And let's see, what other supported database versions
and operating system versions that we have today.
So we constantly certify with SUSE
and RHEL versions as mentioned here.
And in terms of supported deployment models,
we support standalone Azure VMs
which is scale UP and we don't support ScaleOut.
And in terms of HSR, which is your HANA system replication,
which is a solution that predominantly one uses
so that that solution is currently in public preview today.
In terms of performance,
we support 420 MBps transfer rates.
And some of the key call outs are we support SSFS,
which is secure storage file system,
encrypted databases,
and we also support SSLEnforce on top of that.
And coming to native client integration
we have support for HANA Studio and HANA Cockpit
predominantly most widely used tools
by the SAP HANA admins.
And we also have inbuilt mechanism to do some checks
on the checks and which basically
increases the reliability of the backups.
As you can see in the image
we take the intent from the customer
in form of backup policy
and then we initiate the backup
and you can see there is a extension
backup extension which gets installed on the Azure VM.
We don't install anything on the database itself.
And once we take the backup,
we stream that backup to the recovery services vault here.
So it's pretty straightforward and simple.
And one other call out which is unique differentiator
for us is we have a capability to understand
and identify if there are any log chain breaks.
So if there is a log chain break that's happening
during backup and if that goes missing
if you don't identify that and during restore
your restore might not go through fine.
And we all know the importance of downtime
it's going to be pretty expensive.
And we are, we have the unique capability to
identify the log chain breaks.
So what we also do after that is
once we identify as part of the remedial action
we take a auto backup or a backup
full backup so that this can be awarded completely.
And coming to the other call out,
which is basically customers keep asking us how
do we manage support for newer operating systems
or newer DB versions.
So basically what we do is we do extensive sanity testing
to understand if there are any performance issues
with the newer operating systems.
And once we have clear with that
we automatically update the backup extension
and there not be any impact
to the databases that we are backing up.
And moving on to the second option
which is snapshot-based backup.
And as I said today,
this solution is currently in public preview.
And if you can see the image,
so what we do with snapshot-based backup
is once we initiate the backup,
we freeze the database for a few seconds
and then we take the snapshot and then we thaw the database
and then we are back to business.
So what really happens is when the database is frozen,
just for seconds,
so it's instead of the entire backup duration.
So predominantly this snapshot-based backup is recommended
for large databases, anything beyond six to eight terabytes.
And obviously these snapshot-based backups are
highly cost efficient as well.
And I'm going to give you a demo of this end-to-end workflow
of snapshot-based backup as well.
And coming to another capability that we have is HSR support
which is HANA System Replication support.
This is specifically for stream-based backups
and also this solution is also
in public preview as we speak.
And with HSR, basically,
if customers are using H based solution as HSR
one can leverage this integration.
So with reference to HSR
there is no mandatory full backups that are required
after takeover or fail back
and unless always there is a log chain break.
And backups are automatically streamed
to the current active database
to the Azure-managed backup storage, as well.
And in terms of restore,
a single chain backup
basically will make the restore ability simple
and cost effective as well.
So let's see a demo of snapshot-based capability
for SAP HANA databases on Azure VM.
So we get into the recovery services vault
we can create the recovery services vault
and then do the discovery first.
So we select SAP HANA as the workload
then click on discover
and we need to select the VM
on which the databases are installed.
Then we can get started.
So while it's discovering, basically discover that
and then we can go ahead and initiate the backup.
So there is a prerequisite today.
Today before taking a snapshot
we need to basically protect your backups.
So that's why we are getting
we are going to protect the databases using backend first
and then we'll come to snapshot capability.
So the deployment is through.
So let's get into configuring.
So we've done the discovery now.
We'll go ahead and do the backup configuration.
So as I said, we'll start with the backend-based protection
and then this is the backup policy.
You can use the default or create a new one.
Now we need to select the databases
which you want to protect.
So this is the VM that we discovered
and the databases that we discovered.
We select three databases.
One is the system DB, the other two are tenant databases,
and then we can enable the backup.
So once we are done with this
we will go ahead and enable the snapshot-based backup.
So we'll get there, select SAP HANA,
so we don't have to discover
because we've done the discovery already.
And we will do the snapshot-based backup.
Again, I said this is a public preview feature
and you can see the backup policies here.
So we have the backup policies, let's see what we have
inside the backup policy for the different options.
So we have the back policy name
and we can select the frequency,
when you want to run this snapshot-based backup,
and the retention period.
And we also have the resource group
and we also have a concept called managed identity.
So when it comes to managed identity, basically
we need permissions to take snapshots of the managed discs
and then when we place them in the research group
so that's where we are taking managed identity,
is a layer of security again.
So you can select what managed identity you need,
just wait for it to load, then select the managed identity.
And the best part is once you add the databases,
we can check if the managed identity which you had,
which you added, has the privileges,
required privileges so you don't have to come out
or wait for the backup to fail or something.
So we automatically do some sort of pre-validation
so that way you know if the managed identity
has the required rules.
So in this case we don't have,
so what we do is we automatically assign
those missing rules directly from this page.
So you don't have to go out and then come back again.
So that is a value add in terms of
doing the validation of your managed identity.
And then we can enable the backup.
So as you can see, we backed up three databases
and we also did a snapshot.
So we also have a snapshot here
and we can see how we can do ad hoc backup as well.
So you can click on backup now,
so that way you also have an option to do
kind of ad hoc backups if required.
Now let's see what are the capabilities that we have
in terms of restoring the backups.
So we can first go ahead and restore the snapshot
SAP HANA
then we should see the backup items.
We can restore the snapshot.
So if you can see a snapshot,
we need to basically select the VM
and also select the restore point.
So there'll be multiple restore points
based on your backup policy.
We can select one of the restore points
where you want to restore.
And again, we have the concept
of managed identity here as well.
We validate this to make sure the
managed identity user has enough roles and privileges.
If not, we can automatically push them from here.
And then finally what we do is we attach
and mount the snapshot.
So on the target VM,
once the validation is done
we attach and mount the snapshot on the target VM.
So next step what we can do is,
if you're looking at point-in-time restore,
we can restore the system database first.
So this is basically, you've done the snapshot,
we are basically doing logs on top of the snapshot.
So here if you can see,
we need to select the point-in-time restore for logs.
So this is for the system database.
And once we restore that,
we need to basically run a pre-registration script
on the target VM and then restore the tenant databases.
This is kind of a guidance from SAP.
So basically that's why we do the system database first
and then do the script.
And then we go and restore the tenant databases.
So now that we are done with the demo
let's see what we have for cost optimization.
In terms of cost optimization,
one can leverage pricing calculators which provide granular
item-level view to understand what are your costs going to be.
And we also provide support for reserved capacity.
If you're getting into pre-committed usage
you get up to 24% savings on your backup costs.
In terms of optimizing your cost,
we also have capability around intelligent tiering,
where during backup you can see after a few months,
move the backups to the archival tier
for long-term retention
and then we automatically
move those backups to the archival tier.
And one can also leverage the backup reports
so that these backup reports provide you great insights
and it'll also kind of show you patterns,
which can help right-size your backup storage, as well.
One can also clean up the backups
to remove inactive or deleted data sources.
So moving onto the reserved capacity I spoke about earlier.
So in terms of reserved capacity,
if you are getting into pre-commitment of 100TB per month
for a year, we give you 12% discount.
And for three years we are giving you 20% discount.
And if you're getting into 1PB a month pre-commitment
you get 16% and 24% respectively.
And in terms of the pre-commitment
or the reserved capacity for Azure Backup,
you can pay upfront or you can pay on a monthly basis
at no additional cost.
And you can use this for a single subscription
or across multiple subscriptions as well.
So let's see what we have for ransomware protection.
So there's a capability called enhanced soft delete.
So we had soft delete,
and what this soft delete will do is basically
protect your backups from accidental or malicious deletes.
So if you delete your backups by mistake,
we don't immediately delete them completely.
So we move them to soft delete state where
we retain those backups for seven days.
So this was a capability we had for soft delete.
So what we did is we came up
with enhanced soft delete, where we stored that
or retained those backups
for 14 days before permanently deleting them.
And then you can basically configure the retention period.
And during the retention period
which is, by default, 14 days,
we don't charge the customer.
And then anything goes beyond the 14-day period,
you may incur additional charges.
So the options that we have
in terms of enhanced soft delete
we have disable, enable, and always-on enable.
And this is a vault-level setting that you can use today.
And again, this is a public preview feature that we have.
We already have the soft delete capability
and enhanced soft delete is currently in public preview.
And coming to immutability.
So immutability is basically a vault-level setting again.
So once you create a recovery point,
so it cannot be deleted
or it's retention period cannot be reduced, right,
so it could be some malicious actor
in your own organization who's trying to delete
or reduce the backup retention period.
So that's the use case of having this immutability feature.
And this is again, a vault-level setting
for recovery services vault and backup vault.
So what is permitted here is you can go ahead
and still stop the protection and retain data.
And what we don't allow is you cannot stop
and delete that data.
So we stop that delete operation completely
once you enable the immutable vault.
And what is also permitted is you can edit
and change the backup policy
to increase the retention period
but you cannot decrease the retention period.
So these are some of the restrictions that comes
along with the feature itself.
And we also have modern air gap.
So basically this talks about
the recovery services vault capability that we have.
So traditionally if you take air gap solutions
where there not be no network connectivity
or data will be completely isolated and offline.
So when it comes to recovery services vault
we leverage modern air gap capabilities
where it's secure network, we connect to secure network,
and we also have the data which is isolated
and online as well.
So if you can see, we use various mechanisms to do this.
One is we enforce MFA, which is multi-factor authentication,
and we also provide granular RBAC capabilities.
And we also have MUA, which is multi-user authorization.
And we also bring in capability of private endpoints
where if you're transferring your backups
from your source data source to the target VM
or your recovery services vault,
one can leverage private endpoints as well.
And on top of that, we also provide security alerts
to monitor all this.
These are overview of what are the new capabilities
that's available in BCDR today.
And this pretty much covers about Azure VM,
SQL VM, SAP HANA, and what we are doing
in terms of security and backup center as well.
And here are some of our resources, which you can go in
and understand more about Azure BCDR capability.
And that's all we had in this video series.
Looking forward to meeting all on the next one.
Thank you.
(uplifting music)