SPEAKER: Google Cloud Backup and DR
supports a wide variety of self-managed database types,
which you can see here by going to the Backup and Recover
Backup menu.
Now regardless of which database vendor
you are adding to the backup service,
during the Manage phase, you'll need
to select which backup plan template and profile
you wish to apply to that database or instance.
Now, a backup plan template is a way
to define the schedule for your backups
using things called policies, which
in turn define all the typical things you
expect from a backup plan, such as when will my backup run?
How long will my backups be retained for?
As part of our initial setup phase,
we should create templates to ensure our backup schedule
and retention comply with our business backup requirements.
So you may need to create multiple templates or templates
that have multiple policies.
Now the template name will become very important,
especially if you plan to create many templates
and you want to make it easy to always apply the right template
to each database or instance.
I'm going to use a naming structure like this.
First, I'm going to start with DB to indicate
these are database templates.
Then T1 to indicate these are for my tier one.
7-30 means keep seven days in the Snapshot pool
and 30 days in the OnVault pool.
And finally logs to tell me that I'm going to be backing up
logs.
So the first thing we need to do is create a Snapshot policy.
Because this is an agent-based backup,
the backups always have to go to the Snapshot pool first.
I'm going to call my policy daily
snap I'm going to leave the scheduling set to Windowed.
And I'm going to choose the traditional graveyard
shift for database backups.
So my database backups will run between 1:00 AM
and 7:00 AM every day.
Note that if the database backup begins at 6:59,
it will continue to run at 7:00 AM.
It will not be automatically canceled.
I will leave this set to run once per window.
But clearly, if you wanted to, you
could run multiple backups either in that window
or across the course of the day.
However, most database backups tend
to be run usually in the midnight shift.
I'm going to change the retention for seven days.
Remember, that was the name of my template.
So this is going to keep seven days of backups in the Snapshot
pool.
I am then going to go to the Advanced Policy settings,
because for database backups, there's
quite a few things that need to be done.
Application Consistent is irrelevant,
because database backups are always application consistent.
And Snapshot Location only applies to Google Compute
Engine instance backups.
What I'm really interested in is the Truncate/Purge Log
After Backup.
Do I want the backup and DR service
to be responsible for managing the truncation
and purging of logs?
Particularly, say, for Oracle databases,
this is probably an important setting to turn on.
Then I want to consider, do I want
to enable Database Log backup?
In my example, absolutely.
I want my database log to be backed up.
In which case, how often?
Let's go for the smallest RPR we can, which is 15 minutes.
How long do I want to retain these database logs for?
In this case, I'm going to keep them for as long as I keep
snapshots.
Do I wish to replicate these to a different backup and recovery
appliance using the Streamstep technology?
No I don't.
Do I want to put them in the OnVault pool?
Yes, I absolutely do.
The rest of the settings basically
will be determined by different application types.
But one here that you might be interested in
is Enforced Retention.
This prevents early expiration of snapshots.
So if I set this for seven days I cannot,
even if I want to, expire those backups any earlier.
This is good to stop a bad actor who
may have gotten in and tried to get rid of your backups early.
So I hit Save Changes, and I hit Update Policy.
And I've built my first snapshot policy.
Now normally for an agent-based backup,
we would only have one snapshot policy, because that snapshot
policy has captured both the backup during the day,
and the log backup that's going to run in
between those backups.
But what we would normally do is then an add an OnVault policy.
So the OnVault policy is effectively a way for us
to create an offsite backup, a backup that's
away from the backup and recovery appliance.
So I'm going to call my first OnVault policy Daily 30.
I'm going to leave this window set to 19:00 to 18:50,
which is basically all day.
And I'm going to change the retention to 30 days.
Now if I'm using nearline class within my Google Cloud Storage,
30 days makes perfect sense.
My target pool I'm going to leave to OnVault Pool 1.
I've got a choice of four pools.
But you might think, what pool is that?
That will be determined by a thing called our profile, which
we'll do next.
Advanced Policy Settings, the only one
that matters is Enforced retention.
And again, I'm going to set this for seven days so that an image
cannot be expired if it has been made in at least the last seven
days.
And I'm going to hit Update Policy.
Now what I could do is add an additional OnVault policy.
And I'm going to do this, because what I want to do
is, I've defined 30 days of retention.
But in fact, my business manager just came down to me and said,
you need to keep backups, at least monthly backups,
for 12 months.
So I'm going to create a policy called Monthly 12.
The window settings I'm going to leave the same, except that I'm
going to change this from running every day for first
of the month--
so for backups created on the first of the month,
I'm going to retain these, instead of for 30 days
as we talked about, but for 12 months.
I'm going to leave everything else the same,
except I'll change that policy.
And I'll set these so that they can't be
deleted for at least 180 days.
So now what I've got is two OnVault policies.
The first defines daily backups, retained for 30 days.
And the second defines monthly backups, created on the first,
retain for 12 months.
Note that the daily backup that would have run on the first
will be replaced by the monthly backup.
Now that I've built my policy template or my backup plan
template, I now have a backup plan template
that will work for databases.
And I could use this with any database type,
not just Microsoft SQL Server, but Oracle or SAP HANA,
whatever I want.
However, I also need to create a thing called a profile.
Now a profile defines where we put the backup.
Now in this case, you can see I've got two profiles.
One is to do with Google Compute Engine backups.
The other is created whenever I add a new backup and recovery
appliance.
It is misleadingly called Local Profile.
And what I recommend is you edit that and change its name.
So I'm going to change the profile name
to reflect the name of the backup and recovery
appliance, which is 48147.
However, I'm also going to define the OnVault pool.
Remember in the template, we had pools 1, 2, 3, and 4?
Here, we define the actual pool.
So this is the OnVault pool that I have added to my backup
and recovery appliance.
So what I'm going to do is add that name to the profile name
so that I can clearly see that's the appliance
and that's the backup bucket that's being used.
Note of course, I could have multiple backup buckets,
which, in which case, this name would get a little bit hectic.
I could then switch to putting the bucket
names in the description field.
One other thing you'll need to select
when configuring your profile is the Snapshot pool.
When you go to the Snapshot Pool dropdown,
you'll be shown two types of pools--
Snapshot pools, which are used for VMware, VM,
and agent-based backups, and Cloud-type pools
that are only used for Compute Engine instance backups.
If you're not sure which one you're selecting,
make sure you always select a Snapshot-type pool.
And to validate which is which, if you go to Manage, Storage
Pools, you can see which are Snapshot-type pools, which
again, are for your VMware, VM, and your agent-based backups,
or Cloud-type pools, which are only for Compute Engine
instance backups.
I hit Save Profile.
And now you can see, I have a nicely
named profile, which will be easy to spot when
I apply this profile and template to my databases
as I onboard them.