How to get an accurate change rate estimate?

[mcsmithSOP]

We're currently using a legacy backup solution and I am evaluating Veeam. We'll need to purchase at least one and possibly two storage servers (depending on if we have enough available storage on-site). Money is an object, so I need enough but too much storage.

I installed Veeam ONE hoping that the VM Change Rate Estimation report would help, but my two highest I/O VMs are reporting unexpected estimates.

The mail server (Alt-N MDaemon) is reporting daily estimates of 72-118GB during the week; however, the legacy incremental backups are 3.5-5GB.

The ERP is reporting daily estimates of 53-64GB during the week; however, the legacy incremental backups are 130-140GB. I believe the discrepancy in this VM is due to the legacy database (providex) - pretty much all the database files are touched in a day, and the legacy backup backups the entire files.

These two VMs are going to be the driving factor for storage requirements. Short of setting up a backup job and doing a few incremental backups, is there a way to get an accurate estimate of the incremental backup sizes?

[foggy]

Jason, the most accurate estimate is the actual backup job, so I recommend setting up a test job and perform several daily cycles - at least you're evaluating Veeam B&R, hard to do that without running jobs.

Also, probably this thread will be useful in estimating the required storage space.

[Vitaliy S.]

Hi Jason,

The report you're looking at in Veeam ONE is based on the write rate performance counter. If VM writes data to the same virtual disk block, then it might be counted multiple times by report calculation engine. On the other hand, when we were doing extensive tests for this report, the max difference we had observed was around 20% for Exchange VM.

Can you please tell me what legacy incremental backup you're referring to? Is it an agent based one? If it is the case, then file level backup taken from inside the guest OS are usually smaller due to the nature of agent-based backup solutions.

If you want to get real values of changed blocks, you need to run the backup job and then check what VMware CBT driver returns for these VMs. Other than that, I would expect to have this number of changes for your VMs.

Thanks!

[mcsmithSOP]

We are using BE Agents. The ERP is Linux based (so no Linux GRT using BE VMware) which is the primary reason we need to change backup strategies.

I did come across the thread foggy linked to; however, there ends up being a big difference in a 5-10% change rate and the 20% estimated rate. I will set up jobs for those two servers and see what the resulting backup sizes look like. I am assuming that since our BE Agent based backups and Veeam are using two different technologies, the Veeam backups won't interfere with our existing backups.

[foggy]

I did come across the thread foggy linked to; however, there ends up being a big difference in a 5-10% change rate and the 20% estimated rate.

5-10% is a typical change rate of an ordinary VM, while for highly-transactional applications like SQL or Exchange we usually take 20%.

I am assuming that since our BE Agent based backups and Veeam are using two different technologies, the Veeam backups won't interfere with our existing backups.

That is correct, they won't interfere.

[Vitaliy S.]

...they won't interfere until you start using application-aware image process (VSS) option for both jobs and trigger them at the same time.

[hoFFy]

...they won't interfere until you start using application-aware image process (VSS) option for both jobs and trigger them at the same time.

just want to add my two cents: They COULD interfere also if they are not running at the same time. I saw some VMs which had the BE-Agent still installed, or even an uninstalled BE-Agent, but the uninstaller left the VSS-Provider from BE registered. And then only removing the provider via the registry helped.

[foggy]

Ah, I took the question as whether backup sizes of both solutions should correlate...

[mcsmithSOP]

Thanks for the replies. I don't need to worry about VSS on the Linux machine, so I'll set up an evaluation job on that VM (after I change the disk mode back to Dependent).

We are going to be switching mail to Exchange within the next year, so it's good to know that it'll be approx 20% change rate. Fortunately I'm not the lead on that, so I can get the other guy to get me an estimate on disk requirements for that VM.