Changes in V6

[clint]

Hi Veeam,

Since upgrading to v6 we have had a couple of small issues:

1. Backup jobs stop at 99% and sometimes fail - even though all VMs within job have backed up successfully. Console does not seem to refresh automatically?

2. Having just moved backup files to a different repository, Veeam will not allow me to change repository, keeps telling me to move files first even though they are already in the new location? Tried re-scanning all of the repositories.

Support case logged for first issue - not sure if this is justified for second issue.

All the best,


Clint

[Gostev]

Hi Clint,

You must include your support case ID when posting about any technical issue, or your topic will be removed (as explained when you click New Topic).

1. Console does refresh automatically every few seconds.
2. You should click "Map backup" and pick the backup file in the new repository.

Thanks!

[clint]

Hi Gostev,

Thank you - mapping to the backup files worked.

Support case is: 5163097 for 99% issue. Finally uploaded logs by FTP.

Following the upgrade I have noticed jobs stuck at 99% - following a manual refresh sometimes the 99% jobs clear but I find that other jobs are underway that were not visible until the manual refresh.

I am happy following the upgrade and the backup repository approach is a big improvement for us.

[ashleyw]

In terms of the 99% complete, just check on the job status to see what is happening at that stage. What we see is that if we have jobs set to run synthetic full backups and it is the day for synthetic fulls, the initial incremental goes through fine, and the job will stay at 99% for as long as the synthetic full rollup occurs (or the synthetic full process dies as is often the case in our situation -the rollup can take hours depending on the size of your jobs and the speed of your backup target).

[clint]

Hi Ashleyw,

Do you think it would be better if we reduced the number of large VMs on each job (we have some that generate lots of change data) and reduce the number of daily incremental backups by having some separate weekly ones?

With the forever incremental functionally, is it worth even having synthetic full jobs?

We backup to multiple locations using separate jobs just in case of corruption or backup target failure.

Regards,


Clint

[ashleyw]

Well just from the point of synthetic fulls, our view is that it's great to have an active full backup and whole loads of incrementals, but the more incrementals you have, the more likelihood there is of part of the chain being broken/lost (for whatever reason), so in our view we prefer to have active full backups once per month, daily incrementals and synthetic fulls once per week. It also makes moving the dedupe files to a different media device easier.

I'm working through the synthetic full issues with support (just search the forums) - issues I'm battling with are;
- Synthetic fulls randomly failing which seems to be memory related.
- Job retry code in Veeam not taking into account a synthetic full failure when the first pass incremental goes through fine.
- The job scheduling limits not taking into account a synthetic full generation is running (resulting in overloading of the engines).

I do not know at this stage if the failures are due to the size of the VMs in some of the backup jobs.

We have around 350 VMs and 13 jobs with 2xbackup proxies (2 threads each) - backup set about 20-25TB.

We are extremely impressed by Veeam v6 - it is by far the best piece of backup software we have ever used, and the issues we have are relatively small and hopefully resolvable.

[Gostev]

I generally agree on Ashley's recommendations regarding active fulls, since this is the approach many customer seem to be using. Internally at Veeam, we do not use active fulls though. We do, however, run SureBackup jobs to validate recoverability of our forever incremental backups.

Here is the dedicated topic on full backup scheduling > How often do I need a full backup?

And this is the topic Ashley is referring to > Synthetic full rollup failures. Not a wide spread problem indeed, so I do hope it will be nailed down and resolved soon.