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
-
- Enthusiast
- Posts: 29
- Liked: 2 times
- Joined: Feb 23, 2024 10:02 am
- Full Name: TimD
- Contact:
-
- Veeam Software
- Posts: 2630
- Liked: 611 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: How to understand what has changed between backups
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.
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
Who is online
Users browsing this forum: Bing [Bot], mnordstr and 128 guests