SPEAKER: In this video, we're going to look at how we back up
and recover databases running on Linux servers.
Now, while we're going to focus on PostgreSQL--
and forgive me if I pronounce it wrong sometimes--
what you will learn can be used with any supported database.
So there are a few things we need to do to set the scene.
We obviously need to install the backup
in DR service, which will give us our Management Console
running as a service.
We also need to deploy a backup and recovery appliance
into one of your projects, which runs as a Compute Engine
instance.
That appliance is going to do the work
of creating the backups.
The backup and recovery appliance
will have a snapshot pool based on persistent disk.
And you have some choices about what class of disk
will be used.
And we should have an OnVault pool,
which we'll use in Google Cloud Storage
to hold our long-term backups.
What we then do is deploy our backup and DR agent
into our Linux servers.
Now, that could be a Compute Engine instance,
or it could be a VMware VM.
And obviously, we're doing this because this Linux server
is running a supported database or maybe just a file system
that we want to back up.
Once we have installed our backup in DR agent,
there are three things we need to consider.
We firstly need to validate the database set up.
There may be some specific things
we need to do to ensure that this database can work
with the backup in DR service.
We then run a thing called a discovery process, which
adds the databases into the service
and makes them eligible to be protected.
And then finally, we apply our backup plan to them.
And our backups will start to run.
The backup process consists of six steps.
We first connect with the application--
in other words, the database or the file system--
which means the backup and recovery appliance
talks to the backup and DR agent on the Linux server.
That's done, by the way, on port 5106.
It confirms everything's ready to go
and then brings across a disk over iSCSI in step two.
Now, this is a virtual disk presented out
of the snapshot pool of the backup and recovery appliance.
And while the Linux server views it as a real disk,
it's really kind of a virtual disk.
And what happens then is, in coordination with the backup
and DR agent, we get the database ready so
that we can request LVM to create
a snapshot of the logical volume or volumes
where the database is resident, provided the volume group has
some headroom to handle this.
We can then make a copy of that logical volume snapshot
onto our backup disk.
The first time we do that, a full copy; the second time,
incremental.
In between every snapshot we track the changed blocks
using our change block tracking driver.
And every time we do a backup, we
merge those change blocks into our backup,
effectively creating a full backup every time
in the snapshot pool.
Optionally, after each backup, we
can copy those change blocks-- again,
full copy the first time, incremental after that--
into the OnVault pool, into Google Cloud Storage
to give us our offsite storage in a second location.
And you can have multiple OnVault pools.
And you can have multiple policies on those OnVault pools
to determine how long you retain those backups for.
Optionally, we can also back up logs.
Log backup jobs are run separately
to the database backup jobs.
And you can run those jobs as often as every 15 minutes.
The process is effectively exactly the same.
We connect with the application.
We share the iSCSI disk.
We copy the logs onto that disk.
And then we make internal snapshots of those
logs and then possibly move those logs into OnVault
to store them externally.
You also have the option, if you do not
want to use logical volume snapshots, to actually do
what we call full and incremental snapshots.
This is more of what some might use
the term, "old school," where we effectively
dump the database on a Sunday and then do incremental backups
through the week and then do another dump again
the following Sunday.
So full and incremental backups run effectively
in the same way.
We talk to the application.
We present the staging disk.
We copy the full dump or the incremental.
We then make an internal snapshot.
And then we can offload that to OnVault if we want.
You will note, by the way, that I didn't just say iSCSI there.
I also said NFS.
We do have the option to prevent an NFS staging disk instead
of an iSCSI staging disk.
From a restoration perspective, we have two choices.
On the right-hand side, we do a mount.
A mount is a virtual copy of the backup
presented to any server-- either the source or a different one.
And we then start that database as a running database.
The other option on the left is to do a traditional restore.
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
unworking database.
Now, while I'm being relatively generic,
if you are using SAP HANA, the process
is going to be either one of the two choices
I just presented to you-- backint,
which is more of a traditional backup;
or savepoint, which effectively saves a copy of the database
into the internal LVM of the SAP HANA server, which we can then
offload onto our staging disk.
In terms of restore and mount, we still
have the same two choices.
But we could also do what we call restore to a new target.
In other words, we can restore the source host,
or we can take that backup from the source host
and effectively run a restore on any host.
In terms of Oracle, there's one significant difference,
which is that rather than use logical volume snapshots or LVM
snapshots, we instead use RMAN image copy.
So RMAN image copy can be run over either iSCSI or NFS.
And RMAN image copy effectively does exactly the same thing.
We do a level 0 backup first, and then we
do a level 1 incremental after that, each time incrementally
merging the changes to effectively create
a full copy at every backup.
And optionally, we can push those backups
into Cloud Storage.
In terms of setup, we obviously need
to activate the backup in DR service,
create our Google Cloud Storage bucket
to hold those OnVault backups, and validate our firewall
rules.
Now, I'm showing of the firewall 3260
you generally do not need to add because it has already
been configured for you.
But the firewall 5106 you almost always
need to add because that allows ingress from the backup
and recovery appliance into the TCP port 5106 that's
running on your server.
Once we've done our setup tasks, we add the Cloud Storage bucket
as an OnVault pool, create our backup plans
and templates, onboard our applications,
and apply backups.
At that point, we wait for our backups to complete.
And then we can start using them to obviously do
mounts or restores as required.
So how do we do this?
We're going to cover all of these steps
in this playlist series.