Wildly inaccurate Size Reported for Backup Sets

[ruet]

Hello,

I've run into a problem since upgrading BUE from 2014 to 15. BUE is reporting wildly inaccurate backup set sizes for at least on backed up resource. The resource in question runs a full backup every six months with daily incremental backups in-between. The full-backups for the resource are 5-6TB in size and are reported as 7-32GB in size in the "Backup Sets" tab of the storage device details. When drilling down to the "Details" of the backup sets the backup sizes appear correct in the "Contents" tab but incorrect in the "Properties" tab. The backups were successful and restores against the backup sets have been tested. All of the test restores were well above the reported size of the backup set(s). I am running BUE v14.2.1180.1673. Any suggestions?

[ruet]

Additionally, several inventories and catalogs have been run against the storage location.

[CraigV]

...load BE 15 Feature Pack 3 and check to see if this is resolved.

Thanks!

[ruet]

...load BE 15 Feature Pack 3 and check to see if this is resolved.

 Thanks for the suggestion but it did not help

[CraigV]

OK, what are you backing up too? Dedupe folder? B2D?

[ruet]

A 22TB NAS setup as B2D.

[CraigV]

So do the B2D files (*.bkf) correspond to the actual size being backed up?

If this is the case it might be cosmetic, but log a query with Veritas directly so that they can get this checked out. The good thing is that the restores work!

Thanks!

[ruet]

Yeah, I'm 100% sure that it's cosmetic. Unfortunately, it renders the "Size" data from the backup sets on any of my storage devices useless. My next step was to submit a ticket with Sy... er... I mean Veritas. I just wanted to see if anyone here was familiar with the issue or had a quick fix.

Thanks for trying,

[CraigV]

You can check the Known Issues section to see if this is listed there:

https://www.veritas.com/community/backup-and-recovery/issues

As a matter of interest, what does the job log say about the size of the backup?

Thanks!

[ruet]

The size from the log appears to be correct.

[CraigV · Accepted solution]

OK then it must be cosmetic. Check the Known Issues section and if your issue is listed there, vote it up. But log a call in the meantime with Veritas.

Thanks!

[ruet]

Hat's off! ;)

[pkh]

If you use compression in your job, then it could have an effect on the data that is stored.  For example, if you are compressing data which are already compressed, like zipped or movie files, pictures, etc, you might end up with more data than you have started with.

============================

The resource in question runs a full backup every six months with daily incremental backups in-between

It is not advisable to have such a long interval between full backups.  

1) When you do a restore, the full backup plus ALL the incremental backups up till the point in time of the restore need to be restored and this can take a long time.

2) If any of the incremental backups is corrupted, then the rest of the backup chain is useless.

3) DLM will keep the entire backup chain until the next chain is ready and this will occupy a lot of disk space.

It is better to run more frequent full backups, like once a week.