[MUSIC]
>> Hi, everyone. My name is Aditi Gupta and I'm
a Product Manager for Azure Database for MySQL.
In this episode, we'll be talking about backup and restore,
which is the cornerstone for
any enterprise's business continuity and disaster recovery plans.
Today, I come with an action-packed agenda.
But first, we'll be shining some light on backup,
take a quick look into the backup overview,
talk about various backup redundancy options
and see how to view available backups.
Next, we'll talking about restore,
the various restore options available to us,
the various factors that affect estimated time for recovery,
and critical force restore task that will set you up for success.
Let's get started with backup and see how it
functions as a doomsday while safeguarding your data.
Azure Database for MySQL Backup takes
automated backups office over instance.
We take full snapshot backups at least once in a day.
In addition, transaction log backups are taken every five minutes.
The service provides three backup redundancy options
to meet your data and disaster recovery needs.
Azure Database for MySQL provides
a retention period between 1-35 days.
The backup is charged at a nominal price,
where free backup storage is available
up to total provision server storage.
Next, let's take a deeper look into
the various backup redundancy options available.
Locally redundant.
Your multiple copies of backup are stored in the same data center.
Next, zone-redundant.
Here, backups are replicated to
another availability zone in the same region.
Backup storage used for a zone redundant server is
twice that of a locally redundant server.
Last but not the least, geo-redundant.
Here backups are replicated to a geo-paired region.
Now, this option provides you with
the highest durability of objects that are 16 9's.
Now that we've taken a look as to what
are the details behind the various backup redundancy options,
let's go to the Azure Portal and see a quick demo as to how
you could configure these options at the time of server creation.
We've landed on the Azure Portal
for the flexible server create page.
We've navigated down to the computer storage section.
In order to configure your backup redundancy options,
click on "Configure" Server.
Scroll down again to the "Storage" section
and the "Backups" subsection.
As you can see, by default,
the backup redundancy option is set to locally redundant.
For you to enable zone redundancy,
click on "Enable High Availability".
As you can see, the backup redundancy option
has changed to zone redundant.
Enabling high availability mode allows you to select
two options be it same zone or zone redundant.
For you to enable the third backup redundancy options,
click on the checkbox for geo-redundancy and it
will set your backup redundancy option to geo-redundant.
Now that you've seen all the three different types
and how to configure them during a server creation,
let's have a quick look as to how to
navigate between the three posters over creation.
As of date, you can move
between locally redundant and geo-redundant,
poster server create by logging in the Azure Portal,
opening the overview page of the server,
heading to the computer storage section,
and enabling or disabling the geo-redundancy options.
Other switches are other movements between locally redundant,
geo-redundancy two-zone redundant is currently not supported.
Next, Azure Database for MySQL has launched a dedicated backup
and restore blade where you can have
a look at all of flexible servers,
full automated backups, literally serving as a memory balance.
So you can see the backups that have been
taken within the retention period of a server,
see the completion timestamp of that particular backup,
see what the retention period
for that particular backup looks like,
and perform quick actions such as restore.
Next, let's have a look at
the restore below for Azure database for MySQL and
see how it serves as a lifejacket protecting
from accidental data deletions and data corruption.
In Azure Database for MySQL,
performing a restore creates
a new server from the original server's backups.
Broadly, there are two categories of restores available.
The first one being point in time restore where you can specify
your particular timestamp and
restore your server to that particular timestamp's backup.
This restore option is available for all sorts of servers.
The second restore that is available is geo-restore.
Now, this option is available only for
servers which have geo-redundancy enabled.
Further, point in time restore has three subcategories;
latest restore point,
custom restore point, and fastest restore point.
Whereas, geo restore only allows you to
restore to the geo-paired region.
Now, let's quickly head over to the Azure Portal to
see what all of these restore options mean.
We've landed on the overview page for a demo flexible server.
Let's head on to the "Restore" pane and
see the various options that we just spoke about.
Clicking on the restore option
lands you on the restore server page.
Scrolling down, you can see that the point in
time restore has three options for you.
The first one being latest restore point which
allows you to restore to the UTC now timestamp.
The second option allows you to select a custom restore point
which is guardrail by
the earliest restore point available for your server.
Last but not the least, the fastest restore point allows you
to restore using a full automated backup,
and it allows you to select any of
the backups available from your memory palace and perform
the quickest restore as it
restores from a full snapshot without
any transaction logs being replayed.
The second restore option that we had available was
geo-redundant restore and it allows you
to restore to the paired region in case.
In this case, since the original server is located in EastUS,
the paired region is WestUS.
Geo-redundant restore is only available for
servers which have geo-redundant backup configured.
Now, let's talk about the estimated time for recovery.
The estimated time for recovery of
the server depends on several factors.
Depends on the type of restore operation,
whether you've triggered a point in time to restore using
a full automated backup or a custom timestamp, or a geo restore.
The number of transaction logs that need to be replayed,
size of the databases,
and whether there's a primary key present in the tables or not.
Last, but not the least, let's talk about the post restore
task that will set up your server.
If the new server is meant to replace the original server,
redirect clients and client applications to the new server.
Ensure appropriate server-level firewall rules,
logins, database-level permissions are configured.
You can also configure any alerts as appropriate.
That's all for backup and restore and I
hope you guys had a great time learning with me today.
What are you guys waiting for?
Give Azure Database for MySQL server
a chance and spin up your very own flexible server today.
[MUSIC]