Benefits and/or Drawbacks to Synthetic Full Backups?

[smithaetg]

Requirement: 42 restore points (6 wks)
Current job structure: All VMs and physical servers are backed up once a night using forever forward incremental backups.
Question: What are the benefits and/or drawbacks to making weekly synthetic full backups vs just having one full backup and 41 incremental backups?

Potential benefit of synthetic full backups example: A full backup gets created on Sunday on week 1 (restore point 1) and a synthetic full backup gets created on Sunday of week 2 (restore point 8 ), and so on for 6 weeks. If I needed to recover data (i.e. a full VM, file level restore, application, etc.) from restore point 8, does it speed up recovery because the restore process can go to that full backup and doesn't have to go through all of the incremental backups (from restore point 8 through restore point 1) if forever forward incremental backup was being used to generate the recovered data?

Potential drawback of synthetic full backups: More data being stored on the repositories because all of the previous week's incremental and full backup files are now being stored again (duplicated) in the form a that synthetic full backup. Also because you have 42 restore points saved, using synthetic full backups the 7th week's full backup would need to be created before the 1st week's full and incremental backups could be deleted, instead of with forever forward incremental backups the incremental backup closest to the full backup just being merged into the full backup.

Are my benefit and drawback examples, realistic? Do the benefits outweigh the drawbacks (if any)?

[HannesK]

Hello,
I assume that everybody would use synthetic fulls only on REFS / XFS

Except for corner case situations (e.g. move backups to capacity tier after two days), the reason for synthetic fulls is GFS (weekly, monthly, yearly) retention.

For not recommended file systems:

from restore point 8, does it speed up recovery

should be irrelevant. Maybe a bit, if you have hundreds of restore points, but for 42 I can hardly imagine differences. Yes, technically, there are a few more metadata operations.

You pointed out the main drawbacks. The decision whether it outweighs the benefits is something I leave up to you

Best regards,
Hannes

[smithaetg]

Hannes,
Thank you for your reply.

The repository is a SOBR using an ReFS formatted RAID shelf attached to a physical Windows server with data being immediately copied to the capacity tier which is in a cloud.

So, one of the benefits of using synthetic fulls is for GFS retention. Are there any other benefits?

Thank you,
Aaron

[DanielJ]

You will have a lot less I/O on the repository with synthetic fulls instead of daily merge operations, so the jobs will take less time to finish. For us that was the main reason to switch from forever forward. With ReFS/xfs the only cost is the disk space required for the "extra" incrementals.

[smithaetg]

DanielJ,
Thanks for your input! I/O performance is something I hadn't considered.

[PetrM]

Hello,

From I/O perspective, synthetic and forever incremental modes are always equal: 2 I/O per block (1x read, 1x write). In both modes you need to read block from an incremental backup and write block to a full backup whether it is synthesized or not. With REFS/XFS, in both modes merge is performed thanks to block cloning technology which allows eliminating I/O load on the storage. The only difference is the duration of merge, obviously it's much higher in case of weekly synthetic. I guess in Daniel's case, weekly merge just took too much time so short daily merge operations became a good alternative.

Thanks!

[DanielJ]

No, it was the other way around. When we were running forward forever, it was the daily merges that took too much time, up to the point that many jobs were running over 24 hours (with 90% of the time spent on merging) and started missing schedules. As soon as we followed the advice to start running weekly synthetic fulls (scattered over the week) instead, the problems were gone and all jobs finished well within the backup window. I guess you are right that the number of read/write operations should be the same in both cases, but the difference is evident: our jobs nowadays finish much faster and we no longer see the same "I/O pressure" (disk queue numbers, etc.) while jobs are running. Maybe the synthetic full generation benefits from some optimization which is not used when merging in "forward forever" mode?

[PetrM]

It does not seem to be expected that jobs did not fit backup window due to daily merge which could exceed 20 hours. Maybe many parallel merges increased load on the storage and each merge became slower or incremental backups were too huge and a lot of data needed to be merged every day. It's difficult to say what exactly caused it without technical research.

Thanks!