Env:
Hyper-V host: Windows 2012 R2 in a farm with CSV storage (from SAN), NetBackup Client v7.6.1.1
Hyper-V VM: Windows 2012 R2, NetBackup Client v7.6.1.1, and not many other applications installed, e.g. AV.
Master/media: Appliance 5230 v2.6.1.1, with MSDP storage unit.
.
Scenario:
1) A "full" backup of the guest VM using NetBackup Client inside the guest VM, it saves 111,000 files.
2) A "full" backup of the guest VM using Hyper-V Host layer, with 'enable file recovery from VM backup' enabled, saves 242,000 files.
3) A "full" backup of the guest VM using Hyper-V Host layer, with 'enable file recovery from VM backups' DISABLED, saves < 100 files.
.
If I use 'dir /b /s' type commands to list the contents of the C: and D: drives of the client, I can see circa 242,000 files - of which 150,000+ are in the C:\Windows folder structure.
So, each Hyper-V full VM backup with 'file recovery' enabled, causes an additional 130,000 file names to be recorded in the catalog for each full backup of each Windows VM.
.
Now, we know that the NetBackup 'catalog' sizing documentation recommends to use an average file name length of 110 bytes when estimating catalog size, which is clearly good advice, because on a bare bones Windows 2012 R2 system, the average file name length is 113.36 bytes.
.
What I'm leading to is... If a backup admin is to make wide-spread use of Hyper-V backups with 'file recovery enabled' at the Hyper-V host layer, then one will have to factor in the additional space required to 'catalog' all the additional file names that a plain client backup does not have to; because with a plain client backup at the guest layer using NetBackup Client within the guest OS, then the backup will use Shadow_Copy_Components: and System_State: which hides and abstracts the multitude of files which comprise the Windows OS.
.
So, some simple calculations, if I have 400 guest VMs running Windows and I want to be able to recovery individual files, and I have a retention of 8 weeks, and I take a weekly full, then I will need, an additional 44 GB of catalog space more than if I were to use plain client backups:
| average len |
113.36 |
bytes |
| full plain backup |
111,745 |
files |
| full VM backup |
242,027 |
files |
| difference |
130,282 |
files |
| weekly full retention |
8 |
weeks |
| number of clients |
400 |
clients |
| total extra catalog space |
46,153,556 |
KB |
| total extra catalog space |
45,072 |
MB |
| total extra catalog space |
44 |
GB |
.
And I guess there's also got to be some additional overhead on the master server receiving details of an extra 52 million files (i.e. 400 clients * 130,000 file names) each week, which have to be saved within the catalog.
.
My question... Does the above seem reasonable?
