Active Full vs Synth Full: are the benefits reversed in my case?

[m@x]

After consulting the documentation, I understand that Synthetic Fulls are less resource intensive compared to Active Fulls because of the way the backups are being synthesized (reads and writes happen on the target location, while the source is affected for a much shorter period due to incremental vs full).

I am trying to identify the behavior of active & synth in my specific scenario and and determine if the same benefits remain true:
1. Veeam Agent/Job running on the server that is being backed up (local data volume).
2. Backup target is a FreeNAS device connected to the server directly over iSCSI.

Synth Full:
- Server creates latest incremental of its data volume
- Server reads previous full + incremental chain from the target (iSCSI)
- Server consolidates full + incremental chain + latest incremental
- Server writes the new full back to the target.

Conclusion: Simultaneous reads and writes from/two the iSCSI target. The amount of data going both directions equals a full backup. Server resources used for full+chain read, prepare new incremental, consolidate, then write back.

Active Full:
- Server performs a full read of the volume copies the backup data directly onto the target.

Conclusion: FreeNAS drives don't have to fight in agony for simultaneous reads and writes. Server resources are not required for consolidation job. The full read of the volume is fast because it is local, compared to reads over iSCSI.

------------------------

To me it seems that Active Backups put way less stress on my infrastructure. Is my observation correct?

[Dima P.]

Hello Max,

Sounds right, but mind me asking if you are using Veeam B&R with added SMB repo or SMB target is defined in the Veeam Agent for Windows job? Thanks!

[m@x]

Looks like the forum has a bug, where the latest comment is missing a quote/reply button. Only [Like] button is available. I am writing this comment to push yours to the #2 position and get the quote button back...

Hello Max,

Sounds right, but mind me asking if you are using Veeam B&R with added SMB repo or SMB target is defined in the Veeam Agent for Windows job? Thanks!

Ok much better. I am using Veeam Agent for Windows Server License. The backup target is a local drive (in my case F:\) because the iSCSI targets are presented to server OS as locally attached volumes.

I am running iSCSI with multi-pathing (2 dedicated NIC interfaces). It's mostly for redundancy, because despite aggregated 2Gbps bandwidth, the bottleneck is on the FreeNAS side: my target volume is a ZFS pool built from 2 mirrored 4TB drives. So the writes are equal to max sequential speed of a single drive, and it's 5400rpm. I am getting about 60-70MB/s writes from Active Fulls.
I really want to see how Synth Full will perform, despite it's low footprint on the actual local data. Because it will have to read one Full from the FreeNAS target, while compiling the new Full and writing it back to FreeNAS.

[m@x]

It is confirmed.

Active full completed in 1hr 05min (225GB of data).
Creating synthetic full backup (2% done) at 43min and counting. Disk activity (iSCSI target) at 100% all the time, 100ms avg response time. Clearly, simultaneous read/write puts the NAS pool to its knees.

[Dima P.]

Looks like the forum has a bug, where the latest comment is missing a quote/reply button. Only [Like] button is available. I am writing this comment to push yours to the #2 position and get the quote button back...

Thanks, I'll ask web team to check this behavior!

Active full completed in 1hr 05min (225GB of data).
Creating synthetic full backup (2% done) at 43min and counting. Disk activity (iSCSI target) at 100% all the time, 100ms avg response time. Clearly, simultaneous read/write puts the NAS pool to its knees.

Good results. Indeed synthetics is more resource consuming but it conjunction with ReFS 3.1 (or later) & Fast Clone on the repository level you can get noticable performance benefits (and transform operations in case of Veeam B&R repository will be performed at the repository gateway server, so the host will be handling only the incremental backup creation). Cheers!