Comprehensive data protection for all workloads
Post Reply
tjdoc
Enthusiast
Posts: 29
Liked: 2 times
Joined: Feb 23, 2024 10:02 am
Full Name: TimD
Contact:

How to understand what has changed between backups

Post by tjdoc »

Hi,
I have a test Windows server being backed up and have created a full and two incremental backups.
We are not using the server for anything, no changes are being applied to it, it's just a test build.
However, there is a 2GB change in the data size of the VM between the two incremental backups:

Day 1 full - Data size = 262GB
Day 2 incr - Data size = 2.75GB
Day 3 incr - Data size = 2.38GB

This is being reduced by the backup, but the incremental Backup file size is still 900MB which is being stored on disk and copied to the Capacity tier, therefore will have a cost associated to it.

As we are not actually using the server, I'd like to find out why there is still a 2GB+ change in the data each day.

I'm guessing there might be something like AV going on, but is it possible to actually find out where the changes are coming from on the server? I know it's all block level changes, but it would be really useful to find out what's going on, in case we can add some exclusions to avoid excessive backup sizes.

I've also looked at the .rct and .mrt files but they only add up to 8MB, which I don't understand as I thought these contained all changes used for Change Block Tracking? Why are they not over 2GB as well?

It would be really helpful to know what is changing on a daily basis, as we will be adding some larger servers into our environment at some point so I'm worried that our storage costs will balloon and we won't know why...

Many thanks for any help
Tim
david.domask
Veeam Software
Posts: 2630
Liked: 611 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: How to understand what has changed between backups

Post by david.domask »

Hi Tim,

Likely this is a combination of two factors:

- Files changing/temp files being created and deleted/other such filesystem changes
- How Resilient Change Tracking (RCT, Hyper-V's version of Changed Block Tracking (CBT)) works in general

If even a single byte in a block is changed, the entire block is returned by RCT as a changed block and read/transferred. As you observed, Veeam's deduplication/compression will handle this fairly well, but it's expected that a combination of how RCT works and how operating systems work. Remember, the RCT files are metadata about the changed blocks, so that's why the math is likely off.

These values look pretty normal even for "non-busy" servers, as the OS is still making lots of changed data even if the total OS disk usage doesn't increase.
David Domask | Product Management: Principal Analyst
Post Reply

Who is online

Users browsing this forum: Bing [Bot], mnordstr and 128 guests