Procedure for expanding virtual disks

[cliffm]

I just got caught out, looking for some advice.
One of my VMs was starting to fill up so I expanded the virtual disk in VSphere and increased the volume size in the OS.
The next time Veeam replca ran it deleted all the restore points for this VM and only warned me at the end of the job.
Is there a procedure for preventing this? Will Veeam backup also delete all previous restore points in this case?
Thanks

[Vitaliy S.]

Hi Cliff,

Is there a procedure for preventing this?

No, currently this is the behavior used by default to handle these situations. There is an existing discussion for more details, please take a look > Resize a disk deletes all your replica history?

Will Veeam backup also delete all previous restore points in this case?

No, backup jobs are not affected by this since they are not using snapshots as restore points.

Thanks!

[cliffm]

OK I have read the other post. I did search before I posted but didn't find it.
So I need some advice. I need to expand the disk on a small business server VM.

Based on advice from Veeam support I have this backup strategy in place:
- every 2 hours during business hours a replica runs
- every morning before business hours a backup runs followed by a surebackup
- every Saturday night a full copy is made for off site storage

So I gather that if I expand the disk all the replicas will be blown away. This means that the next time a replica runs it will be a full replica? So I should run this manually off schedule so the SBS is not tied up during business hours?

Or should I disable the replica job and create a new one (I do have the space to do this)? Then after 2 weeks I can just delete the original replicas and job?

Thanks

[Vitaliy S.]

This means that the next time a replica runs it will be a full replica?

Correct.

Or should I disable the replica job and create a new one (I do have the space to do this)? Then after 2 weeks I can just delete the original replicas and job?

Yes, If I were you, I would definitely create a new replica job and run it for the next two weeks on a usual schedule. This should protect you from any failures within the next 2 weeks.

[tsightler]

So I gather that if I expand the disk all the replicas will be blown away. This means that the next time a replica runs it will be a full replica? So I should run this manually off schedule so the SBS is not tied up during business hours?

I'd just like to clarify a few things for future readers of this thread because there a confusing mix of terminology.

Changing the disk size does not "blow away" all of your replicas. Replica's refer to the individual VMs that are replicated. Each "replica" also has a number of restore points, based on the settings for the replication job. Whenever a change to a source VM disk is made, all restore points for that replica must be deleted so that we can change the size of the disk (VMware does not allow a VM with snapshots to change this disk size). The "replica" is still there, but it will effectively have only a single restore point (the most recent one), after the replication is finished. There is no "full replica" on the next pass, it will still be incremental after the disk size is changed, but only one restore point. From that point, restore points will build up again until they meet the criteria.

So, put simply, after a disk size change, the next replication will remove all restore points except the most recent, then the job continues normally.

[daniel.Soares]

Hello
a customer told me that he has an error messages on veeam b&r for a vm job after having expanding the windows partition of the guest OS
seems that the error was saying that all previous restore points was not anymore usable
is that an issue someone can confirm?
or can some one tell me that veeam allow partition extands
I have no screenshot of the error message

thanks for your comments

[Vitaliy S.]

Hello Daniel, If you're going to change/expand Guest OS partitions, then this is not going to affect Veeam jobs, however doing the same procedure with virtual disks will indeed remove all existing restore points for the replication jobs. Please review this topic for the detailed explanation. Thanks!

[RolandSchauer]

Hi,

We use B&R V7 for vSphere Backup. Recently we've expanded a vmdk's disk size (Entered new size in the VM's properties and extend volume in Windows Server's disk management)
Now a backup job throws a warning: "Disk <vmdk-file> size changed. Changed block tracking is disabled."
Do I have to reinitialize CBT as advised in the "soap fault" error?

Thanks in advance!

best regards
Roland

[foggy]

Roland, as it is stated above, backup jobs should handle source disk size changes seamlessly. If you observe different behavior, I recommend to contact technical support so they could verify the possible reason. Of course, you can try to enable CBT manually for this job and see whether this helps. Thanks.

[tuscani]

Same issue as Roland on one of my VMs today after expanding the C: VMDK 20GB..

"vmdk size changed. Changed block tracking is disabled"

Are you saying we shouldn't have to reset CBT manually?

[tsightler]

Does it happen on every run, or just the first run after changing the disk size?

[tuscani]

It's only tried to run once since the disk change. Will let you know after tonight's job.

[tuscani]

Error did go away on 2nd nights run

[ashman70]

Yesterday I added 40GB to a drive on a VM, Veeam only runs a full backup on Saturdays, yet tonight it seems to be running another full backup when it should be running a reversed incremental. Is it running a full backup because I added space to the drive?

AM

[foggy]

Please review the thread above for details. Basically backup jobs should not be affected by guest disk resize, do you see the CBT warning in the job session log?

[ashman70]

Hi Foggy, no there were no CBT warnings at all, the job does not indicate it was a FULL backup either, odd. I am using Veeam version 6.5.109

[foggy]

What made you think it was a full run? Anyway, you can check how it goes during the next job run and contact support in case your suspicions are confirmed.

[ashman70]

I know it was a full run because of how long it took and how much data it backed up, the usual nightly incremental job takes maybe 7 minutes to run and transfers anywhere from 1.3-3.2GB and reads anywhere from 1.2-7.4GB depending on how busy it was.

The job that ran last night ran for 6 hrs and 17 minutes although it says it only transferred 2.4GB?? but read 250GB.

So it took longer then a regular full job which usually runs 5 or so hours.

Not sure what happened.

[foggy]

The job that ran last night ran for 6 hrs and 17 minutes although it says it only transferred 2.4GB?? but read 250GB.

That means CBT has indeed broken and our proprietary change tracking mechanism was involved, which resulted in reading of the entire VM. Let's see at the next job run.

[ashman70]

The job ran as expected the following night as an incremental, do I need to be concerned about anything? I am migrating this VM to a new host this weekend and want to have a good backup before I do so.

Thanks

AM

[foggy]

If you have successful backup job run, no need to be concerned about this. To be on the safe side, you can test its recoverability using Instant Recovery, for example.

[loelly]

So, I have a file server VM protected by a Veeam B&R 8.0 replication job (twice a day, 12 restore points kept). As the data disk was reaching capacity at 1.4 TB, I increased the disk to 1.6 TB. On the next run, the following happened:

11/19/2015 6:02:36 PM :: VM disk size changed since last sync, deleting all restore points

All restore points have been deleted. This took around 2.5 hours. Question: is this expected behavior when a disk has changed in size?

Next:

11/19/2015 8:38:14 PM :: Calculating digests for Hard disk 2 (1.6 TB)

This took around 9.5 hours. Reading on the Veeam KB, calculating digests can be time consuming, comparable to an active full. An active full in this case takes less than 2 hours, so this seem to seems to be a bit off.

I'd be happy if anyone could help me here. Thanks!

[Shestakov]

Hello Maik,

All restore points have been deleted. This took around 2.5 hours. Question: is this expected behavior when a disk has changed in size?

Please take a look at this post.
Thanks!

[dipjjcas]

I am surprised that 4 years later this problem continues to occur. In addition, in our case it is more flagrant:
Yesterday we expanded the system disk of our Windows file server (from 40 to 60 GB) and today we find that Veeam has erased all the restore points of the replica. So far, no problem, but... it has started to digest the 8 TB disk where the user files are (this disk has not been resized!) ... and this process costs more than a full backup or replica. The real problem is that: this VM is included in the daily backup of all VMs and this backup is locked pending resources until the digest ends; that is, 4 days without backup!.
Veem has a lot of room for improvement here

[wishr]

Hi Jose,

It's quite an old post. If you are experiencing the same Cliff mentioned the best way to proceed is to contact our support team (don't forget to let us know your case ID once done). I had a talk about this to QC team and restore points deletion is not the expected behavior.

Thanks