Hyper-V GRT backup and volumes > 2 TB

[stephan_vanheld]

We want to virtualize our file server to Hyper-V, but of course this should have a volume larger than 2 TB. Is there any option to perform a GRT-enabled backup?

I understand that disks > 2 TB must be GPT-formatted, but BackupExec does not support GRT on GPT disks.

Another option would be a stripe set over multiple 2 TB disks, but these must be "dynamic disks" and I understand that this configuration is not supported by BackupExec too.

So, am I correct that there is really no option to have a Windows volume > 2 TB in a virtual machine that can be backed up with GRT enabled?

(Of course I can back up the files direclty from an agent in the virtual machine, but that's definitely not what I want.)

[RLeon · Accepted solution]

So, am I correct that there is really no option to have a Windows volume > 2 TB in a virtual machine that can be backed up with GRT enabled?

You are 100% correct.

For a virtual disk > 2TB, it must be a GPT partition, and GRT doesn't work with GPT partitions.
Windows Logical Disk Manager, i.e., Dynamic Disk volumes don't work with GRT restores.

You also don't want to having to perform OS level agent based backups.
Because that would be very slow and inefficient. (I am guessing that is why you don't want it.)

Your only option would be to use the "Off host" backup method.
Backup Exec calls it the "Advanced Disk Based Backup".

You have to use Raw Device Mapping (that's a VMware term, I think Hyper-V calls this Passthrough disk, or something) to present a LUN directly to the VM's OS, bypassing the Hyper-V.
So if you are using fiber SAN, then you present a raw lun directly to the VM' OS, instead of using it as a virtual disk that the Hyper-V host manages.
For the following examples, suppose the VM's OS mounts this LUN as drive E:\ (10TB, GPT NTFS, doesn't matter)

Next, you have to use your SAN vendor's specific snapshot methods to 'clone' this lun in the underlying SAN storage.
Not on the VM OS level, not on the Hyper-V level, but the SAN storage's level.
Now I use the term 'clone' loosely because the method for creating the snapshot for the lun can be based on a variety of ways, like mirroring, copy-on-write, redirect-on-write, replicating.... etc.
But in the end, they all create this 'snapshot' of the original lun, which, as we know, is drive E:\ for the VM's OS. (Very simplified explanation...)

Now back to Backup Exec.
You would have to "zone", i.e., present the lun of the snapshot (not the original lun) to the Backup Exec server.
You will also have to configure the SAN vendor's special VSS provider (not VSS writer), tools, and stuff on the VM, and possibly on the Backup Exec server too.

So what would you achieve by doing all of the above?
You configure a backup job for backing up just the drive E:\ of the VM, and you configure the offhost "Advanced Disk" backup for it.
When the backup starts, the snapshot lun inside the SAN stops updating itself from the source lun. (So essentially it is a 'snapshot' of a specific point in time, of the data of the original lun, which is the E:\ drive for the VM)
Next, the Backup Exec server backs up directly from this snapshot lun, via fiber, which in most cases is much faster than via LAN, and doesn't stress your Hyper-V host nor your VM's bandwidth.

Hope that helped in someway.

RLeon

[stephan_vanheld]

Thanks :) ... We'll definitely not go for the SAN snapshot thing at the moment. (Besides, that possibly won't help me if I need to restore individual files.)

So, IF we virtualize the server, we'll likely go for multiple 2 TB volumes then. Or we'll spare GRT and find another option for single file restore (like keeping copies of changed files on another machine).

I understand that backup of GPT/Dynamic disks itself works fine, it's just GRT that doesn't work on these.

[RLeon]

We'll definitely not go for the SAN snapshot thing at the moment. (Besides, that possibly won't help me if I need to restore individual files.)

After a successful offhost backup of the snapshot lun (i.e., SAN snapshot backup, Advanced Disk Backup), Backup Exec is smart enough to associate it with the VM's E:\ drive.
When you restore, everything should look 'normal'. You could restore individual files from the VM's E:\ as if the backup was done normally, just like all other backups.

SAN snapshot backup has many benefits, and it bypasses all the issues related to GRT restores.
But it IS kind of a hassle to setup the whole thing.

About using multiple 2TB MBR partitions with Basic volumes (non-Dynamic) to solve your problem:
Technically it would work, and you are right that GRT would work.
The only problem is, if you use tape, GRT restores will have to be "staged" on the backup server's disk, before you could get your tiny 1kb file back.

So say if your VM has two 2TB virtual disks, you backup 4TB of stuff right?
If that all goes to tape, then when you do a GRT restore, even if you only want a single file back (e.g., a 1kb file), Backup Exec would dump the entire 4TB backup somewhere on your backup server, before you could get your tiny file back with a "restore successful" message.
The trouble is, most backup servers don't have 4TB free lying around waiting for this to happen...

Of course if you do not use tape, then you could safely ignore all of the above about restore staging.

RLeon

[stephan_vanheld]

> The trouble is, most backup servers don't have 4TB free lying around waiting for this to happen

Ours DOES have ca. 30 TB available :) ... We would have the latest backup set on disk anyway, and the previous one we would duplicate from tape to disk and then do the restore.

Anyway, there is still some need for internal discussion. But my original question has clearly been answered, so this is enough for now. Thanks!

[Kiran_Bandi]

@Leon

Consider posting it as an article with this info (with a bit more explanation).....

[RLeon]

It is difficult to write about SAN-snapshot-based off-host backup procedures because there are many different SAN storage vendors and just as many ways to configure.

So to make it work for everyone, you'd have to generalize the steps. A lot.
But if it is over generalised, no one would be able to follow.
On the other hand, if you make it too specific to one SAN storage vendor, then it would only be useful to a specific group of people.

If you want to know what I mean by over generalising, just have a read through the "Off-host backup" section of the Backup Exec admin guide, you'll find no more than 10 pages of it, and you wouldn't come out knowing everything you need to know to setup a working SAN-snapshot-based off-host backup configuration.

All that above hasn't even taken into account the different combinations you could create in different Backup Exec environments; some simple, some complex (Like the ones with CASO, managed servers, VMs, and stuff).

Ok I'm just babbling. But thanks for showing interest.
Maybe when I have more materials at hand, I'll post something about it.

I did post something about snapshot technology (Semi-related to off-host backups) a while back on the Netbackup forum. It was very crude and unpolished, and was quickly buried into the depths of the forum. Only if interested:
https://www-secure.symantec.com/connect/forums/concept-snapshot-levels-and-quiescing

RLeon