Synthetic full every day for backup copy

[FrancWest]

Hi,

we use a backup copy for our exchange server that runs every hour. We have als scheduled weekly and monthly backup copies. This creates a synthetic full using fast clone on reFS. However, due to the amount of incrementals (every hour during 7 days), the health check of these backup copies takes ages (now running for 23 hours and only at 81%, in the mean time now backups are being copied). So I thought if I created a synthetic full every day, the health check only checks that backup and the incrementals for that day, which should run faster than it does now. Is that correct and if so, how do I configure veeam to create synthetic fulls every day for a backup copy? I can't find that option.

Franc.

[HannesK]

Hello,
there are some chances that health-check will be faster, because it's less data to check. If you do that only for one server, it might work. If you do that for all your jobs, there are also chances that at some point REFS metadata operations slow down things. That's hard to predict.

No, there is no option for synthetic fulls for backup copy jobs.

Actually I would think about getting faster backup storage: if health-check is slow, I assume that your restores would also be slow.

Best regards,
Hannes

[FrancWest]

Our other copy jobs don’t have this issue, it’s only this one that’s so slow due to the many increments. It’s our secondary storage so indeed not that high end, but our primary repository is.

[foggy]

Hi Franc, health check performance is mostly defined by the backup size and by what the storage can provide in terms of the read speed. Any chance this job is much bigger in terms of processed data? Since health check always verifies the latest restore point, the number of files it needs to open to get related blocks also affects performance, so as Hannes has already mentioned, the more frequent schedule might help.

[FrancWest]

Hi Foggy, it's the backup of one of our Exchange servers, which holds the passive databases. The backup is taken every hour and then the backup copy processes the backup. Average data processed is around 6GB. So we have 24 backup copies every day. Number of restorepoints to keep is set to 96 (so 4 days). Lowering this number to for example 24 will limit the restore capabilities I assume since the number of restorepoints to keep is less than a week (I only have the GFS fulls then and the full when the rention expires).

[foggy]

I meant the more frequent schedule for the health check that you were thinking of trying, not decreasing the number of restore points.

[FrancWest]

But if I have 96 restorepoints until the last synthetic full, it doesn't matter if I run the health check more frequently or not does it? It still needs to check all those 96 restorepoints eventually since they are part of the latest backup chain until the last full. Or...?

[foggy]

Ah, right, this is the backup copy job... So no periodic fulls in-between and to up the health check frequency, you would need to lower the retention. Unless you enable the 'Read from source...' check box switching the job to simple forward incremental but losing ReFS benefits.

[FrancWest]

Read from source is not an option due to the limited bandwidth between the primary and secondary site... So we're out of options then and can only limit the number of restorepoints... Feature request then would be to be able to schedule a synthetic full with the benefits of reFS. Even on our slower secondary storage the reFS merges are quite fast with a limited number of incrementals.

[foggy]

The upcoming v10 will boast the new backup copy mode that will basically mirror source backup files to target and will have GFS capabilities, so might address your needs here.