Hi,

I think you should look at some other results to try to find out where the discrepancy lies.  Are the amount of savesets the same for each?  If you only take one week, is it correct? Are there any incomplete backups during this time (you are excluding them from the mminfo result)?  If you can narrow down where the difference lies, you should get a better idea of how they are counting that would explain the difference.

-Bobby

Hi,

I'm in a similar situation, but the report from DPA are lesser that the report from NMC or Networker.

The savesets are the same, but the space is different.

Have you got a solution for that?

You need to dig into it to see if same query is used and if yes, where discrepancy comes from (it is only size or also number of ssids too?).

Hi Hrvoje,

I'm pretty sure that the difference is in the size.

But I know that the size reported by networker is different from the real files size.

I would like to know if the DPA size reported is the sum of files size, or there are some other issue.

In other words, if the saveset for c:\ reports on networker a size of 100GB, the sum of files saved is less than 100GB.

I didn't check for DPA to undestrand if the size is the real SUM of files size

Do you know that?

Regards

Ambrogio

I assume they both use mdb - so they obtain information from mminfo.  Depending how you make query and if you use old style disk devices with RO, you may have some duplicates.  Further, do you have clones?  So, there are few basic instances where query might give you different numbers and I have seen in past examples of that.  If this is size only, give it a check. When I was using DPA couple years ago (EBA called back then) there was a log file (actually there is KB article too) where you could see query.  Repeat the same query outside DPA and compare values.  They should be the same.

As the difference is "little" I thought to some rounding or to the overhead on writing to media.

I opened a case, so I will wait for them.

Bye

Ambrogio

Do you use tapes?  In case you use tapes and small number of ssids spans multiple tapes, it might be the case of incorrectly using head and tail instead of seeing that as single ssid.

There is a Primus (I don't remember the number).

The problem is that Networker write the correct size, but in the reports the conversion from Bytes to GB i smade using a strange formula (/1024/1000/1000).

DPA is using a correct formula (/1024/1024/1024) so that starting from the same data, the report is different.

The differences in save set sizes can in fact be very confusing. I have noticed those as well.

That's why i exclusively rely on NetWorker because is has the only capability to get the size down to the byte if you extend the width of the 'sumsize/totalsize' field. With Powershell you can easily do the math with a script.

I prefer to do that in 2 steps:

  1. Use Powershell to run the mminfo report of your choice to retrieve all backup data for that period.

  2. Use Powershell to extract the statistical data of your choice. Repeat that for each client if necessary.

Back to the calculation ...

In fact,

  "/1024/1000/1000" is the correct formula to calculate the size in GB  (Giga-bytes).

  "/1024/1024/1024" is the correct formula to calculate the size in GiB (Gibi-bytes).

If you prefer to believe OS vendors, create a file of 1.000.000.000 bytes on a Windows NTFS partition and verify the size with Explorer.

BTW - for statistical calculations i do not trust DPA at all - or does anyone know where the input data comes from?

That's why I always calculate totals in bytes based on totalsize - whoever is the end user for report can do with it whatever they want   (I use perl as I can use same syntax for sum calculation on multiple different OSes).