SPEAKER: Now that we've applied our backup plan to our SQL
instance in this example, where we could have protected
databases as well, we can monitor the jobs
by going to Monitor, Jobs, to see if our jobs are running.
In this example, you can see all my jobs are succeeding.
We can also go to App Manager, Applications,
find the instance or database that we
applied the backup plan to, right select, and go Access.
This brings up what we call the Timeline View.
And the Timeline View shows graphically
all the backup images that we've got in both the Snapshot
pool and OnVault pool.
If you don't like that look, you can also
change this to Table View.
And this clearly shows all the same things,
but in a table format.
What we can now do is start using our backups.
One important point is that you can also
access these same backups by going to Backup and Recover
and choosing the Recover option.
Choose the backup you're interested in.
And then, in this example, I've got a pop-up.
And I've got three significant choices.
There are several here.
But the three that matter most are Mount, Clone, and Restore.
Mount creates a virtual copy of a database,
meaning that it does not copy the data.
It creates a virtual disk on which your database exists,
maps that virtual disk, usually over iSCZI,
to the host to where you want to access this database,
and then brings that database online.
Let's go and have a look at what it does.
Firstly, we can select any target host.
Obviously, this host needs to be a Windows host that
is running SQL Server.
We can then choose to create new virtual applications, which
makes a lot of sense because I want
it to access the database rather than just the files,
though if I wanted to access the files,
I could just turn that off.
I then choose which databases in this instance I want to mount.
Now, because this is an instance,
I'm seeing all the databases.
Obviously, if I was just protecting one database,
I would see just that.
Choose the database you want.
And then you can rename it.
Now, in this example, I'm going to mount it
back to the same host where it comes from.
So if I jump over to that host, you can see,
I'm running Microsoft SQL Server Management Studio.
I have my ProdDB.
And that DB is currently accessible.
And there's some rows and tables.
I'm now going to bring it up as TestDB.
I do have some advanced options that I can explore.
I also have some mapping options,
such as what drive I want this to be presented as.
I also have the ability to add scripts.
I'm going to hit Submit.
The job begins, and I can monitor
the job in the system monitor.
Now, while waiting, if I go over to here,
one thing that you will note is under this PC,
I currently only have a C drive.
I didn't specify a drive, so the mount job
will add a virtual disk.
And it will usually create it as the Z drive.
When the mount job gets to the point
where it is able to present the disk,
you'll see it presented there.
You can see, it is my backup of my drive.
If I go and explore the drive, I can actually
see that the backup files are currently
present on that drive.
But, more importantly, if I go over to SQL Server Express,
what we can see under databases is I have two databases--
ProdDB and TestDB.
Remember, we looked at a table on ProdDB.
And if we go and look at a table on TestDB,
we can see that it's there, and it's accessible.
And all the data is usable.
I can read it.
I can write from it.
I can use it.
However, the data is not on the C drive.
It is on a drive being presented by the backup and recovery
appliance over iSCZI.
One of the things I can do is I can
go to App Manager, Active Mounts, find the mount,
and then migrate the mounted database onto the system drive.
What migration does is run copy jobs on a frequency--
by default every 24 hours, but I can make it as often as every
hour--
to effectively sync the mounted database to drives--
the system drive, in this case the C drive--
on the host where I've mounted it to.
I can also move it to different locations if I want to.
So in other words, I can mount, and then I can migrate.
If, on the other hand, I don't want to keep this mounted copy,
I can instead choose to unmount and delete.
Delete doesn't delete the backup.
It deletes the virtual copy of the backup.
So, in general, it's the right choice.
I hit Submit.
I can see my Unmount and Delete job is running.
When the job completes, you can see
the Z drive is already gone.
But, more importantly, if I close databases and refresh,
you can see TestDB is also gone.
It's done the complete cleanup.
Now, in that example, I chose to do a Mount.
I could have chosen to do a Clone or Restore.
What is the difference between these two?
A Restore restores the source database on the source host.
So if I choose Restore, I cannot select to which host this is
targeted because Restore always targets the source host.
I can choose to do a traditional Restore, where the files will
be copied over and then the database started,
or a Mount and Migrate, which is no different to what I just
did before, except that it is already set up.
And in this example, it would mount and then migrate
the database, which would allow me to start using it prior
to the copy being finished.
Note that when the copy is finished,
there is a task called Finalize, which needs to be run,
which will require a small outage on the mounted database
as we switch over from the mounted copy
to the migrated copy.
Finally, I could have chosen to do a Clone.
The fundamental difference between a Clone and a Restore
is that, in a Clone, I can choose
which host I want to target.
I can also choose which databases I want to clone.
It looks very similar to a Mount,
except that instead of doing a Mount and Migrate,
I'm effectively doing a full copy onto the server disk
immediately.
And I can choose to put the files into the same location
or different locations at the file level or the volume level.
I can also choose whether or not the files get renamed to match
the new mounted database.
So a Clone is like a traditional Restore,
but to any host, where a Restore restores the source
host, either traditionally or with the Mount and Migrate.
And a Mount simply creates a virtual copy,
which I could optionally migrate later.