VM is doing Full while increment expected

[tfloor]

Hi,

Last night we saw our backup (6.1) was doing a job with several linux vm's.
All vm's did an incremental, except 1 vm (same as other vm's).
It did a full!, (both disks on the vm).

How is that possible.
I backup based on vcenter folder structure.
The only important thing that i have done with the vm is storage vmotion to another lun, and the vm is powered off twice that day.
I have not remove it from inventory or something.

What's the trigger that veeam is doing a full in this case?

Thanks.

[dellock6]

Hi Tristan,
have you moved the VM with storage vmotion while it was running, or powering it off? Because in the second scenario,if I'm not wrong vCenter changes the VM moref ID...

[habibalby]

Hello,

Have you run job on time other that the specified time in the scheduled? You may reach your Retention Period as per how you configured it and deleted the VM as per the Deleted VMs From Disk Retention, then a full backup of the job is expected to run on a day other that the specified Active Full Backup.

Thanks,
Hussain

[tfloor]

I had definitly powered off the vm before moving it with storage vmotion!

[tfloor]

Hello,

Have you run job on time other that the specified time in the scheduled? You may reach your Retention Period as per how you configured it and deleted the VM as per the Deleted VMs From Disk Retention, then a full backup of the job is expected to run on a day other that the specified Active Full Backup.

Thanks,
Hussain

I have not run the job on another time!

[Gostev]

How do you know if it's doing full backup for this VM?

[tfloor]

My backup tape was full ,.. so that was weird!,
Then looking at the file size of the job, and that was very big,

Normal Full = 1100 GB
Normal Incr= 40 GB
Weird jobsize because of full vm: 757 GB (the vm is one of the biggest in the whole job)

[Vitaliy S.]

If there was a moref ID change then this information would be reflected in the backup job log files, besides if you take a look at VeeamAgent log files you will see how much data VMware CBT has returned as new blocks for this VM. Please contact our support team and let them assist you with the logs review.

[dellock6]

Another possible cause could have been a defrag operation or sdelete on a VM prior of the backup execution. It would still be an incremental backup, but with a really large amount of changed blocks to save as modified...

[tfloor]

Another possible cause could have been a defrag operation or sdelete on a VM prior of the backup execution. It would still be an incremental backup, but with a really large amount of changed blocks to save as modified...

There is no defrag or sdelete actions done on the linux vm.

It must be something with powering off and storage vmotion that i've done. But I'm wondering if that is normal, and if i can check which ID is used, and if it changed. Can i find that somewhere?

[Vitaliy S.]

Yes, this information can be found in the backup job log files, just compare the VM moref ID between two last job sessions.

[dellock6]

It must be something with powering off and storage vmotion that i've done. But I'm wondering if that is normal, and if i can check which ID is used, and if it changed. Can i find that somewhere?

So you are confirming, as I supposed in a previous post, you first powered off the VM and then you migrated it? This is for sure supposed to change the Moref ID !!!

[tfloor]

Yep,

So why is that :S, if i'm not power it off the moref id stay intact

[foggy]

Perhaps some specific conditions should be considered here as I've just migrated the powered off VM and the moref ID did not change.

[dellock6]

To be sure, we first need to know from the OP if the more was effectively changed, Tristan have you checked the logs?

[babarc]

Hello, two days ago i moved all my vm from an iSCSI SAN to another iSCSI SAN for maintenance.
I had also changed the repository of my backup: from a windows server through a NAS (CIFS repository).
I do a full on friday and incremental each week's day. last night backup job was not running, but tonight yes.
The VIB files are about 5/7GB, but the last VIB are 180GB! I see the report and in the past the "data read" is about 20GB, this night about 1014GB, like a full.... but the file is .VIB, not .VBK.
Is it normal? It is cause by storage vmotion or by changing repository's type?
Thanks

[Vitaliy S.]

I guess this most likely was caused by the storage vMotion (see this thread discussion for more details).

Can you please tell me how exactly have you migrated your VMs? Be aware that every VM re-registeration in the VI changes the unique VM identifier (moref-id), and if VM ID is changed, then it gets treated as a brand new VM.

[habibalby]

Hello,
if you do a Storage vMotion to a VM, make sure you go to the Veeam Backup Job where the VM that Storage vMotion-ed and you hit Re-Calculate button to get all the storage reclaimed. I have been once in this issue but after doing the recalculation to the other VMs, the CBT SOAP warning / VIB files increased go to normal state.

[habibalby]

Check this out, might help you http://www.interworks.com/blogs/ijahans ... ror-vmware

[babarc]

Hello,
if you do a Storage vMotion to a VM, make sure you go to the Veeam Backup Job where the VM that Storage vMotion-ed and you hit Re-Calculate button to get all the storage reclaimed. I have been once in this issue but after doing the recalculation to the other VMs, the CBT SOAP warning / VIB files increased go to normal state.

Thanks a lot! I'll try!! It seems exactly the same situation!

[pwinterbourne]

Hi,

I am looking for some help with the best way to continue my backups with veeam after a rejig of my iscsi storage.

I currently have a starwind san with RAID10 that houses 10TB of vm's on. These vm's are backed up by veeam everynight and it all works nicely however we are running out of space on our iscsi san and I have decided to copy of the .img files from starwind to some other storage, wipe the server (build the volumes in raid 50) and reinstall windows/starwind and configure the luns again (plus copy back the img files).

I will have to reregister the vm's in my virtual center after doing this and dure to the unique id that Veeam uses I am presuming that at that point either my backup jobs will fail or they will perform a full backup of the vm's again.

What is the best method for veeam to cope with this scenario?. i did read that I could remove the vm's from the existing backup jobs and then readd them which would initiate a full read of the disk and only transfer the blocks that have changed? ios this the case?

Of course the problem is that even the reread on 10TB of data is going to take a lonnnggg time.

I do kind of wish that veeam had some sort of UID mapper/changer tool so that you can just update the UID in the veeam db and the backups can continue as normal after virtual infrastrcuture changes. Quite a few times now I have had to initiate a full backup again on my vm;s due to things like removing ESXi hosts from the cluster and then adding them back in (in order to fix an issue with vsphere HA etc).

thanks for any help much appreciated.

Paul

[pwinterbourne]

I know this is probably unsupported but in theory would following this article work?

http://www.interworks.com/blogs/ijahans ... are?page=1

[Vitaliy S.]

You're correct in your assumption that any manual interaction with our configuration database is not supported, but if you want, you can give it a try.