Netbackup's handling of STUB files (in this case, CommVault)

[Georges_N]

Hi everyone

Thought this would be an interesting Q & A as I haven't found any details about this subject, literally, anywhere.

We've recently started archiving our file server with CommVault, which leaves a 4KB stub file in the place of whatever file it just archived. For example, a 19kb file is archived, leaving an identical file of 4kb, the only differences being the size on disk and the file icon (has a little black X on it)

When Netbackup backups up, let's say, one specific section of our file server (approx 640gb), here's what happened before and after archiving:

Before archiving: approx 640gb in 3h48min

After archiving: approx 640gb in 3h49min

Thing is, of those 640gb, over half of it is archived, leaving only 4kb stubs. How is the size AND time it takes to backup almost identical? We tried recovering files from said backup and it really is the 4KB stub...

Anybody else use both systems together and has an idea what's going on?

Thanks!

[StefanosM]

I think that as netbackup does not have any knowledge about commvault files, it tries to read them with the usual way so Commvault is getting the request and send the whole file to netbackup.

You have to check what can be done from commvault side. Maybe there is a prebackup script to alert commvault not to send the file back to the file system.

[bills]

Stefanos - That was my first thought as well, but Georges says he restored files from the backup and they were only the 4K stub.

I used a similar product years ago that let you configure IP addresses from which file requests would not get rehydrated; we had to set up our media servers this way.

Georges - maybe you can verify that ALL of the files backed up were only stubs with bplist -l or bpflist -l?

Bill

[StefanosM]

try to restore a file to an alternet server, where commvault is not configured, to see what netbackup will restore. Also try to open this file. But the question "how to backup" had to be done to commvault support.

[Georges_N]

Restores are as-is (so if the backed up file is a stub, the restore is a stub)

We tested the following:

Backed up a VMDK disk from server X - 30gb total

Archived it, server is now 25GB

Backed up the same server, post-archiving - 25gb total (so that's fine)

Second test:

Backed up an RDM disk - 5gb total

Archived it, rdm disk is now 4gb

Backed up the same server, post-archiving - it's still 5gb.

Looks more and more like the handling of Raw Device Mapping from Netbackup - also noticed it took 30 seconds more on the second test (so maybe it's searching...loading...something? and then timing out)

[bills]

Ah, I assumed you were doing straight file backups.  If you're backing up the containing VMDK/RDM, then you're relying on the underlying virtual filesystem to reclaim the space once the guest OS releases it - which is not by any means a sure thing.

If you take your server with VMDK or RDM filesystems, and delete a TB of data, does the disk size (as seen from ESX) or the backup decrease in size?

Bill

[Georges_N · Accepted solution]

We will have to resize our disks, I believe.

Thanks guys.