We are using only synthetic full with weekly or daily (since V11a) health checks. FastClone is important to us, so active full is not used :)

Weekly SureBackups are in place to test the Recoverability of all vms. And Manual Testing for the Agent and Nutanix Backups.

We are using synthetic fulls only, too. This is important because we are using the FastClone mechanism with ReFS.

Active full only if there was a problem...

And up to now there were no reliability or consistency problems with synthetic full backups in any of our environments.

Hi @marcofabbri,

I’m in the same camp as @Mildur, I’ll only use Active full if I’ve got failed backup verification which is extremely rare.

There is another story to be told from an IO perspective here however as well, especially when we consider JUST synthetic full vs synthetic full with fast clone.

Per IO, the story is as follows:

Active Full is 1 IO (read) from the source datastore, 1 IO (write) to the destination repository. So it is better from a performance standpoint.

Synthetic Full is 2 IO (1 read, 1 write) from and to the destination repository. This starts to play an important factor in how your repository is configured from a performance perspective, is it spinny (if so what RPM), is it flash and then what RAID configuration is being used.

What I’ve said above for Synthetic full is mostly negated when using Synthetic Full with fast clone, for example a synthetic full that used to take about 20-22 hours for me when I migrated to fast clone went to an average of 19 minutes, that was on Windows Server 2016! 2019 & 2022 have been even better performing. There’s of course some overheads with fast clone but it is nearer to performing just another incremental backup (which is just the same as active full, 1 IO from source datastore = 1 IO to destination repository).

You’ve said about active full requiring more space than synthetic, but that is definitely only the case with fast clone, otherwise it’s just a case of IO placement. It’s also recommended that we size repositories without fast clone optimization in mind, as if we need to create active fulls instead (whether due to bugs or corrupt chain etc), we should have sufficient capacity to retain the full dataset.

Hope that helps!

It depends on the space available at the repositories. I like to do some hybrid-style. For example, when you have monthly tape-outs, you can schedule active fulls to bring them on tape. So you can be quite sure these (active full) restore points are free of any incremental-errors (like fast-cloning or CBR). Otherwise I prefer synthetic full - but just with ReFS/XFS. Which is the default nowadays. 

I love this response a lot! Exactly how backup should be done and tested...

Again as others have said it depends. If you are using ReFS/XFS then Synthetic fulls are great for fast clone.  However, if you also are doing any GFS backups sometimes it pays to do an active full every now and then I find for your backup chains. Also maybe there will be a requirement from the business that an active full is required.  But using either works very well.

If you have an XFS or ReFS go for synthetic with health check like @Mildur wrote.

If you are not using filesystem with block cloning, i will say it will depends of your backup repo and network.

Active FullBackup = more stress on network

Synthetic= more stress on backup repo specially with dedup appliance

It depends on the space available on the repositories. By default I always use repositories with REFS and fast-cloning in combination with Windows 2016 or 2019. Then the default setup I implement is daily incremental and weekly synthetic full in the weekend. In some cases I implement daily synthetic full if the customer wants to have a daily full copy to tape (otherwise we would have to implement reverse incremental and I don’t like that). If using synthetic full it’s important to activate health check which is not needed if using active full because of creating weekly a new backup-chain. If the customer has sufficient space available on the repository, I schedule monthly an active full. Why? Because then we have the same datablocks at least twice available on the repository, otherwise all depends on the first created datablocks and only once available. I trust the synthetic full : never had issues with it, but to be sure I once schedule an active full in the month.

In some cases if the customer is using a very low performant repository : I implement active full because this is quicker : only write sequential on the repository and transfer data from source to the repository, otherwise read and write on the same repository and can be slow especially without fastclonining, because then no pointers to the datablocks are being used, but created a full blown full backup-file.

As @BertrandFR  mentioned about the stress.

same here

Hello,

Unfortunately I have lot’s of customer with small infrastructure and they can use surebackup jobs… They have “false” cluster because if 1 node fails, the others can’t handle the new load.

I do only project with immutable repository with XFS + weekly synthetic. 

Until now, I never check for health but maybe I should because no active full are done. Maybe 1 health / month ?

With health check, you check mainly HW failures (Disk, Raid-Controller, ...) . SureBackup is more for logical failures (CBT, XFS/ReFS, ...). From my perspective running SureBackup just with Ping- and Heartbeat-Test isn’t enough for finding logical issues. 

@damien commenge  check this

How to atomate & schedule Veeam.Backup.Validator.exe | Veeam Community Resource Hub

Lots of great answers and I don't have much to add here. We're also using Synthetic Full (with ReFS) in most environments combined with at least Health Checks or SureBackup. So far it has proven to be reliable and didn't cause any problems.

I always tend to say, if you have a failing disk or damaged blocks/sectors then the chances are high that all of the backup files are affected; included different Active Fulls. It could be a benefit though if you directly offload those backups to tape, like @vNote42 says.

I never thought about daily health checks, but thinking about the performance boost with v11a it could be possible.

It Works great. I‘m testing the daily health check for one job at the moment. The storage is doing nothing after the backup is done. 7 hours until a possible restore from the service desk. Perfect time to let the health check run :)

50 minutes for 60 vms and 15TB per vm backup chains :-)

Thanks for the numbers, @Mildur !

If I don’t need regular off site or tape copy, do I need to schedule a synthetic full, or will a forward incremental with a setting of 7 restore points effectively leave me always with a full and 6 incrementals?

@Serge.Adam1060 

Forward incremental with weekly synthentic fulls and a retention of 7 restore points will get you 2 fullbackup files and 12 incremental → Forward Incremental Backup - User Guide for VMware vSphere (veeam.com)

Forever Forward Incremental with a retention of 7 restore points will get you 1 fullbackup and 6 incrementals (place for a seventh incremental is needed to do the merging). → Forever Forward Incremental Backup - User Guide for VMware vSphere (veeam.com)