v6 initial incremental massive

[averylarry]

I just upgraded to v6. This is a straight upgrade and one of my normal jobs (incremental, synthetic full on weekend, CBT has been working, virtual app mode) just fired off at it's regular time. I didn't look at it or change anything (other than the upgrade, obviously).

I have 120 restore points on this incremental job. The .vbk file is 942Gb. The incremental files (both .vrb and .vib) average 4.5 Gb, with the largest at 17.3Gb. My last backup was last night as normal. It usually takes 30 minutes to do the incremental backup (there are 4 VMs in the job).

It's been running for 2 1/2 hours, and the .vib file is 215Gb and growing -- the job only showing 16% finished.

Is this expected? With the job running, I don't see any useful logs (but I might not know where to look) that might indicate an issue.

[dlove]

At least you got to use your old backup job. I did the same as you but the job kept failing so support told me to create a new one Now I have 84 vm's that are backing up over the network for some reason because it's set to automatic. I'll try hardcoding the transport mode to virtual appliance next run.

I also tried creating a new job and mapping it to the "old" backup files, thinking I would save the day but it crapped out again complaining about RPC errors just like the original upgraded job did...

From "what's new pdf":

Backup mapping. When creating a backup job, you can map it to existing backup files produced
by another backup job. The new job re-uses the backup files and continues incremental runs,
without the need to perform a full backup of VMs that are already present in the specified backup.

[Gostev]

Please note that backup mapping feature requires v6 or later backup files.

[Vitaliy S.]

Ted, your backup job behavior is not expected. To browse for the job log files, select Help > Support Information from the main menu, but I think it's better to open a support ticket with our team, so we could figure out what's happening. Thank you.

[mrt]

Please note that backup mapping feature requires v6 or later backup files.

does this apply to replica mapping, too?

[Gostev]

No, there is no such limitation there. This scenario is actually suggested for use in the VMware-specific FAQ under Upgrade section. Because replicas are stored in the native format (as a regular VM), you can re-use replica VMs created by any Veeam B&R version, or even by 3rd party product.

[aaron_228]

Is it just me or does the automatic selection method for SAN/Network, etc.. just really not seem to work? I forced it to Direct access and even manually put in each LUN that should be backed up via SAN but yet I still am seeing some erratic behavior. Just ran a backup with like 10 VMs in it and 1 out of the 10 was backed up via network. All are on the same hosts, SAN luns, etc..

[Gostev]

It works perfect. That 1 VM has some issue preventing its disks from being backed up via direct SAN access, which is why (according to your proxy server settings) the processing fails over to the network mode. If you disable failover to network in case when primary processing mode fails, the VM processing would just fail out instead.

If you are interested to investigate what is so different about this VM, you should submit all logs to support for investigation.

Thanks!

[aaron_228]

It works perfect. That 1 VM has some issue preventing its disks from being backed up via direct SAN access, which is why (according to your proxy server settings) the processing fails over to the network mode. If you disable failover to network in case when primary processing mode fails, the VM processing would just fail out instead.

If you are interested to investigate what is so different about this VM, you should submit all logs to support for investigation.

Thanks!

I'll keep an eye on it, just upgraded yesterday. This did start after upgrading though, I've never seen one fail to network with v5

Thx

[averylarry]

I see this in the log file:

The item was not backed up early. Full backup is required.

It's just under a section that looks like it's starting to process a virtual disk.

[Gostev]

Yep, looks like it is doing full backup there for you. Looks like you have some newly added VM in the job, so it goes into the VIB file. Or may be something changed the unique VM ID for this VM, so the job considers it as newly added.

[averylarry]

No possible changes to the VMs or the jobs since last night. Only thing new is v6 upgrade. It's a bummer -- I don't have any where near enough disk space for full backups on top of all the old stuff.

[mrt]

i'd also like to report full backups being performed when incrementals are expected. on top of that, its failing over to nbd mode for every vm. i've got a case opened.

[Vitaliy S.]

It's hard to guess what might the reason for that, so yes our support team will definitely help in this situation.

[Davd]

i'd also like to report full backups being performed when incrementals are expected. on top of that, its failing over to nbd mode for every vm. i've got a case opened.

Same here

[srebucci]

Hi, Gostev same issue here.

I've upgraded to the 6.0 version and I've started an incremental backup. The new one produces a .VIB that, in size, is equal to the weekly .VBK. I rerun the same task again and a little incremental VIB is created as normal. I cannot stay this way cause lack of space and backup window for the file servers machine (TBs of data).
Luckly my Veeam Server is a virtual one so now I've come back to the last snapshot: the only thing I've changed during the setup it's the location of the VBRCatalog directory to a new one, but the machines and the jobs are all correctly imported. I've just set a new blank directory so it preserved the old one but the sizes at the end are slyghtly different (a few MB vs a few KB) event with the GUI started.

I hope you could help me, I could repeat the upgrade job in a few minutes if asked but I have to return to a correct state before evening 'cause my first backup starts at 17.30.

PS My machines are all backup over the network 'cause the virtual machine is in a different server that doesn't see the SAN directly.

[Gostev]

Hi Simone - for any technical issues, you must contact our technical support and have them investigate your log files. We do not provide technical support over the forum. Thank you for understanding.

[Gostev]

Just talked to QC about this, and they said this could be happening if you are attempting to map backup file produced by backup job on one backup server into the backup job on another backup server.

Backup mapping works correctly only if you create the new backup job on the same backup server that produced the backup you are mapping into.

[srebucci]

Hi Gostev, thank you for you time but this is not the case. My repository is a drive Z: on the same server. I've just done an in place upgrade and then, short after the reboot, started the backup with right click, start. This afternoon I'll update my server again and try with another job and creating a new the job mapping the backups.

[Davd]

same here...no mapping was done... only in place upgrade, reboot, then launched an existing backup job with right-click. If anyone that expirieced this issue has tried to recreate a job and perform backup mapping, please update status here so that I know if thats the solution. So far only 1 of my backup jobs is "broken"... and I would like to run the remainng ones as correct incrementals

[Gostev]

Well, the thing is, you have to run your existing jobs at least ones before you can map into backup files, as backup file mapping is only supported for v6 produced backups.

David, it might be best to let our support look at the logs to understand what exactly happened with your job.

[Davd]

Alright... I'll contact them

[srebucci]

I've tried again same result. No change of VBRCatalog directory this time, just next, next, next and reboot. The problem is that now I need to stop all my backup everynight jobs and lauch them one at time during the daytime. I could survive 'cause v.6 is fundamental for our DR 'cause of the enhanced replication ratio but now I'll wait monday to do the upgrade.

[mwpreston]

I'm seeing the same results as well, never remapped backups at all, just simply upgraded and ran old jobs - ran out of space on my backup drives
I'll have to open an issue with support to fix this...not sure if maybe a full backup would fix this issue or not....
Has anyone heard back of any solutions?

[Gostev]

Creating the new jobs will certainly resolve this, but other than that you all need to resort to support for investigation - until they have the logs, they cannot troubleshoot this. Although I believe at least David already provided his logs, so that helps. Thanks!

[srebucci]

Hi mwpreston, I could confirm you that after a first backup where the VIB files take the size of a full backup, the next one is a regular one. I think that like Gostev said

Well, the thing is, you have to run your existing jobs at least ones before you can map into backup files, as backup file mapping is only supported for v6 produced backups.
David, it might be best to let our support look at the logs to understand what exactly happened with your job.

it's a matter of vbk/vib versioning. I hope they could fix this with a workaround 'cause I've run the first full backup job by network a long time ago and since then I do synthetic and incremental only. If this will be not fixed, I will need to replay the full one, one machine at time: one of my files server is a 2 TB machine and via network the first replication take from Saturday 1 pm to Sunday 9 am vs my everyday that is 20 mins.

PS I'm waiting too for support answer on David case: as soon you get them please share them to the community. In the meantime I'll wait for the upgrade. I'm absolutely positive about this: Veeam it's a great company and every post I've put in this community I've always received a clear and quick response. This is rare in the software world: I hope that when the will became even bigger (and I think it's just a matter of time), they will mantain this level of support to the community.

[Gostev]

Sounds good. I will also be updating this topic with the news. I have just came to the agreement with R&D that if we determine the cause of the issue above to be a bug with the upgrade code, we will re-issue the product build with this one issue fixed (other than this, no other major issues are being reported by customers on v6). The new build may take a few days though. Thanks.

[EvilTwin]

I am also seeing this behavior. We upgraded to v6 yesterday. I have two fairly large jobs that appear to be running full backups into the VIB files.

[mwpreston]

So, do you think I'm best to hold tight, open up a support request, or just reseed? I don't really have the space to support it for much longer

[Gostev]

Right now best is of course to move old backups to some other storage, and start fresh. And support case is a must.