Warning after upgrading to Windows 10

[marius roma]

After upgrading from Windows 8.1 to Windows 10 I gos a warning saying that "Disk 0 layout change detected, resetting changed block tracking for all volumes on this disk": what is the meaning of the message?
Should I do anything?
Are the old restore point still valid?
Should I delete them and restart the backup cycle from scratch?
Regards
Marius

[PTide]

Hi,

resetting changed block tracking for all volumes on this disk

This message means that changed block tracking was reset therefore lost track of incremental changes which implies that next backup session will perform full backup of all volumes that reside on Disk 0.

Thank you.

[marius roma]

Thank you for the message.
So, my only concern will be having enough free space on the NAS to create a new .vbk file, is it correct?
Regards
marius

[PTide]

So, my only concern will be having enough free space on the NAS to create a new .vbk file, is it correct?

Correct. Also keep in mind the amount of time needed to create a .vbk + IOps.

[Dima P.]

Not correct, actually. It's not going to be a full back up (.vbk) – just a huge incremental backup (.vib).

[Gostev]

Not necessarily huge, as only the system disk will have major changes due to OS upgrade.

But indeed, the main point here is that even without changed block tracking, the produced backup file will still be incremental. It is just that VEB will need to read the entire contents of all volumes to determine what blocks have changed since the last backup.

[RCurrier]

I have deleted the endpoint backup job from the Veeam Backup and Replication server repository and created a new job for the Endpoint Windows 10 PC and I continue to get this error.
I have several Windows 10 PCs that I get this error on. I was tired of the Endpoint backups alerting me that the HP recovery partition was getting full and I did not need the recovery partitions anyway since they were for Windows 7. I deleted the HP recovery partitions and extended the C: partition with the available space on some of them.
How do I completely reset the endpoint job so I will stop getting these annoying messages?

[Dima P.]

Hello Rob,

What VEB verion are you using (to check go to Control Panel > Updates)?

[IDATAAB]

Hi - I'm using VEB on a VM that is Server 2012 and backing up to a datastore managed by my Enterprise Plus server. I have a large external data volume (around 4TB and growing) on a NAS that is attached via iSCSI to the VM server. On occasion I have to extend this disk as it is a long term archive storage device. Since its a disk that is external to the VM it is attached to extending the disk causes the "Disk layout has changed" warning and subsequently creates a huge .VIB file. This requires a lot of preparation prior to extending the disk in order to avoid doing the "where am I going to put it" dance.

Before I extend the disk I first have to reduce my number of restore points to 1 or 2, run a backup to force a merge to save space, then extending my volume and running a new backup which generates the new huge .VIB and then running 1 or 2 more backups to force a merge/consolidation. Only after that can I raise the number of restore points back to normal (14). This has to happen each time I extend the disk. A lot of pain!!

I have plenty of VM servers that I am backing up with Veeam B&R that I often extend storage on. A typical scenario is when I extend a volume on a NAS that is a backup repository attached to my Veeam B&R server via iSCSI. In the Veeam B&R environment, Veeam never complains about a disk layout change and never creates an enormous .VIB file.

Any suggestions? This is a real pain for us.

Thanks!

[Dima P.]

Hello Jeff,

The only workaround I can imagine is to switch to File level backup mode but for such huge machine that would not work. May I ask why you are extending the machine size little by little instead of giving it more storage in advance? Thank you.

[tomers@y-tech.net]

Hi,

We are in the same boat here. We are Cloud service providers, we have something like 900 VMs running in our cloud. We backup lots of them using the VAW. A disk extend is a normal day to day procedure when a customer hits his quota and have to extend the disk.
The answer to your previous question is simple - cost. Customers don't want to waste their money on an unused space so we are extending disks from time to time after they purchase more space. When you have 900 VMs it becomes a daily procedure.
This is one big issue for us. Customers also have quota in our Veeam Cloud Connect. Each time we have to extend a disk it causes a new full backup, meaning we have to extend the Cloud Connect repository as well. This a real time consumer for us because we have to follow this procedure for several days, depends on the retention of the VM. If we have a VM with 30 days for example, we will get our space back only after 30 days. We don't want to delete restore points of course.
This issue must have a solution..
Is there a way to backup an entire machine (using entire machine or file level) and not hitting this problem when extending a disk ?

Thanks.

[Dima P.]

Tomer,

Thanks for sharing the real-world scenario.

Is there a way to backup an entire machine (using entire machine or file level) and not hitting this problem when extending a disk ?

Unfortunately there is no workaround for this behavior now, but I've added your vote to this request. Cheers!

[thermoking4mi]

I also am getting this error, only 1 workstation. I have the latest Veeam Endpoint (version 3) backing up to a Veeam B&R repository. I've change the backup type from volume, file, entire computer. Deleted the existing job and backup chain still getting this error every time.

5/23/2019 12:42:37 PM :: Disk 0 layout change detected, resetting changed block tracking for all volumes on this disk

[Dima P.]

Corey,

Can you please clarify what type of workload you are protecting with agent? Is this agent is managed by Veeam backup server? Any changes of the disk layout performed manually or via any automation tool? Thank you!

[daystrom]

case #05792349

I am testing in-place upgrade from windows server 2012r2 to windows server 2016. The windows 2012r2 installation is brand new. I ran an agent backup on that before the upgrade, which created a 409 gb vbk file. After the in-place upgrade, I ran another backup, which would normally have been an incremental (installation uses the default settings for most part), and not surprisingly it generated a 478 gb vib file. The backup has this message:
12/22/2022 8:43:00 PM :: Disk 0 layout change detected, resetting changed block tracking for all volumes on this disk
I imagine that's a way of saying that the change of OS was detected.
For the future does it make sense to create an entirely new backup, not a continuation of the original? Or does what I have amount to the same thing, by that I mean if I wanted to restore the second backup, the original backup would essentially be ignored?

[HannesK]

Hello,

12/22/2022 8:43:00 PM :: Disk 0 layout change detected

if one is using block-based backup (default and recommended), then a change in the disk layout leads to a new full backup, because the data of all blocks "changed". So the behavior is expected for each situation, where that happens. Please see the answers above for a similar scenario.

For restore of any incremental backup (VIB file), you need the full and all dependent incremental backups.

Best regards,
Hannes