Veeam Copy Jobs - Immediate - Synthetic Full Only

[forums101]

Hi,

Is there a technical reason why the choice to do a full backups by reading all information from the source on immediate copy jobs is not available? Or was this just overlooked and coming in the next version?

The reason being, we are not using ReFS so it is much faster for us to do an "Active Full" rather than Synthetic, which can take over 24hrs especially if a health checking is also required.

Second part, why on a Periodic Copy Job can I not do SQL log shipping?

At the moment we don't have a copy of our SQL logs in a second location because we need to use period because of the problem above.

It is also disappointing that there is no way to convert copy files from periodic to immediate when the first issue of not being able to select active full is resolved. This will make for lots of additional backup files in changing over to maintain restore points for compliance

Cheers,

Paul

[HannesK]

Hello,
and welcome to the forums.

first: It was intentionally due to lack of resources to implement that feature. Your request was counted +1

second: because of it's technical limitations.

I can fully understand your problem. You are not the only one. Seeing that the feature is not coming with V11, I recommend to switch to REFS / XFS or improve the performance of your backup copy target.

Best regards,
Hannes

[forums101]

Hi Hannes,

Thank you, and thank you for your quick reply!

Okay, we will have to wait until it is available in future releases.

Our target storage is not the problem, it can process data at 2-3GB/s. We have some large VMs 16TB+, Health checks on these files only run at 1GB/s (not sure what in Veeam limits this) hence why we use Active Full. With AF we can process backups 2 or 3 times faster an don't need to do health checks.

Cheers,

Paul

[Gostev]

Why does AF not need health checks? They are used for the storage-level corruption detection, and AF does not magically protect against that.

[forums101]

Hi Gostev,

Sounds like I may have been given miss information if that is the case by a Veeam source, I will have to log a call to investigate why health checks perform badly. In the past any job re poor performance with Veeam has resulted in blamed the storage even though I have proven time and time again that I can push much more throughput on the storage than some Veeam process can.

I fear this may result in a fruitless pursuit.

Our health check can't process large 10+TB VMs in a timely manner so we can't have that option turned on. We have a large number of VMs of these sizes.

Cheers,

Paul

[Gostev]

Take one of the more common silent data corruption scenarios: RAID controller in your storage writing rubbish due to a sticky bit in its RAM module. With this happening, an Active Full will obviously be just as corrupted and unrecoverable as a Synthetic Full. It's very important not to put any false expectations on Active Fulls! Testing backups has the outmost importance regardless of the backup mode.

If your backup storage does not have enough performance to do a health check for all VMs, then maybe you should consider doing spot checks of a few most critical VMs with a SureBackup job at least?

[pirx]

Hi Hannes,

Thank you, and thank you for your quick reply!

Okay, we will have to wait until it is available in future releases.

Our target storage is not the problem, it can process data at 2-3GB/s. We have some large VMs 16TB+, Health checks on these files only run at 1GB/s (not sure what in Veeam limits this) hence why we use Active Full. With AF we can process backups 2 or 3 times faster an don't need to do health checks.

Cheers,

Paul

+1

We now have to go back to periodic fulls for BCJ as they just take too long for the syn. operations.