SPEAKER: In this video, we're going
to talk about how we back up and recover Microsoft SQL Server
databases using Google Cloud backup
and DR. So there are a few things
we need to do to set the scene.
We need to install the backup and DR service, which
will give us our Management Console, running as a service,
and deploy a backup and recovery appliance into one
of our projects, which is running as a Compute Engine
instance.
And this is going to do the work of performing the backups.
The backup and recovery appliance
will have a snapshot pull based on Persistent Disk.
And we should add an OnVault Pool
to it, which is running in Google Cloud Storage.
What we then do is we deploy the backup and DR agent into any
of our Windows servers.
This could be Compute Engine instances, Compute Engine VMs,
or it could be VMware VMs.
And obviously, we're doing this because these Windows servers
are running a SQL Server database, or maybe even just
a Windows file system that we want to back up.
So there is a two-step process here.
We need to discover the applications, which we
do using our onboarding wizard.
And we then apply a backup plan to them.
And we can apply that to a SQL instance or a SQL database.
Or what we could do is create a consistency group.
And that consists of databases or instance on the same host
that we want to back up as a consistent group.
And we can also just apply a backup plans
to Windows file systems like our C drive and our D drive.
The backup process is a six-step process.
We first connect with the application,
which means the backup and recovery appliance
talks to the backup and DR agent on the Windows Server.
That's done on port 5106.
It then confirms that everything is ready to go,
and then brings across over iSCSI
in step two, a backup disk.
So this is a virtual disk presented out
of the snapshot pool that the Windows Server
views is a real disk.
And what it then does is again, in coordination with the backup
and DR agent is, we get Microsoft SQL Server
to use its VSS provider to create VSS voice
snapshot of the source drives.
And then we make a copy of that VSS snapshot
onto our back up disk.
The first time I do that is a full copy.
The second time is incremental.
We merge just the changed blocks,
which we track using our change block tracking driver.
After every backup, we create an internal snapshot
of this backup disk, which is effectively our internal backup
stored in the snapshot pool.
And then optionally, we can copy the changed blocks, which
and again, in the first case, would be all the blocks,
and then in subsequent backups, change blocks into the OnVault
pool for effectively, what is our offsite storage
into a second location.
And you can have multiple OnVault pools.
And you can have multiple policies determining
how long we retain the backups in both the OnVault
pool and the snapshot pool.
Optionally, we can also backup logs.
Log backup jobs are run separately
to the database backup job, which makes sense.
You can run the log backup jobs as often as every 15 minutes.
But the process is exactly the same.
We connect with the application, we share a SCSI disk,
we copy the logs onto that disk, and then we
use internal snapshots to maintain copies of it.
And again, we can optionally push those log backups up
to a vault to store them externally to the backup
and recovery appliance.
From a restoration perspective, we have a lot of choices.
And they're all really good ones.
We can do a mount, where we simply
mount a copy of the virtual disk which the backup is on,
to any server, both the source server or any other target
server.
And we can then, start that database.
The other option is we can do a traditional restore.
So a traditional restore is we connect with the source host,
present the backup disk to it, and then copy
the backup over the top of our presumably corrupted or
unworkable database.
We can also do a thing called a clone.
And a clone is effectively a bit like a restore,
but it's to any host.
So we can clone the database to any host
that we want to in addition to restoring the source host.
In terms of setup steps, we need to activate the backup DR
service, which I just talked about.
We then need to create a Google Cloud Storage
bucket for OnVault. We need to validate our ingress
and potentially our egress firewall rules.
What we're thinking about particularly,
is port 3264 ingress into the backup and recovery appliance,
and port 5106 for ingress into the host servers
that are running the agent.
And obviously for every host that we
want to do an agent-based backup,
we need to download and install the Windows agent, taking care
to ensure that we activate CBT and copy a thing called
the shared secret.
And we've got to talk about all of this in forthcoming videos.
What we then do is we switch across to the backup and DR
service itself, add the Cloud Storage bucket
as an OnVault pool.
We create our backup plans.
We add our Windows host using that shared secret,
on board our applications and apply our backup plans to them,
and then begin the process of recovering our applications
when we need it.
So what are we going to do in subsequent videos is talk you
through all of these steps.