How to Tell What Will be Backed Up

[stonewall]

I have searched the forums and the internet for the past couple of days and I have not been able to find an answer to my inquiry.

Is there a way in Veeam or a piece of software or tool out there that can tell us what will be backed up before the job starts? Or a general idea of how much data will be backed up in the next job?

[Gostev]

The backup job wizard provides the source data size right on the step where you select what to backup. It is updated every time you add or remove objects. Thanks!

[Vitaliy S.]

Also you may want to use Veeam ONE predefined backup report, that estimates the amount of changes for each VM in the job to help with planning disk space usage by incremental backups. Thanks!

[stonewall]

So Veeam ONE predefined backup report will show me the changes made to the VM since the last incremental backup? And then I can see the amount of data that will be backed up when we run the replication job again?

[Vitaliy S.]

Veeam ONE has two reports, one can estimate the changes based on the VM write activity, the other one will report on historical VM changes for the backup job. In order to report on exact amount of changes you still need to create the snapshot and then get CBT ID and match it to the existing data blocks on the VM disk.

Answering your question - we cannot say how much data has changed since the last backup, but we can tell you what is average VM data change rate.

BTW, can you please elaborate on how would you use this data (the number of changes for the next backup job run) further?

[veremin]

Is there a way in Veeam or a piece of software or tool out there that can tell us what will be backed up before the job starts?

Additionally, you can get information about jobs' sources in automatic fashion, using GET-VBRJobObject. Thanks.

[stonewall]

To answer your question we're attempting to figure out the amount of data that will be backed up in order to better plan out our replication and to see if we need to bring our offsite backup onsite in order to move a large amount of data if that is the case. Our replication has gotten behind due to copies of large databases being created and we have it set to automatically run every night but stop in the morning so it does not conflict with Production hours.

[Vitaliy S.]

Thanks for clarifying, but doing it prior every job run and then deciding on what to do can be really time-consuming, right? If you want to optimize first replication run, then backup seeding (should be the latest backup file) should be a way to go.