I ask this question which I think is very important starting from the thread in the forum veeam .
There is a best practices in a small environment (<4TB) about using only synthetic full backup, active full backup or both togheter alternating?
What do Veeam recommend, since synthetic is selected by default?
Use only Synthetic full lead to risks in terms of reliability and consistency of backups?
On the other hand, using active full requires a lot of space in repository.
I ask you Veeam gurus. 
+12
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.
+17
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...
+17
And up to now there were no reliability or consistency problems with synthetic full backups in any of our environments.
+22
Hi
I’m in the same camp as
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!
+13
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.
+9
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.
I love this response a lot! Exactly how backup should be done and tested...
+21
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.
+8
If you have an XFS or ReFS go for synthetic with health check like
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
+12
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
+10
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...
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 ?
+13
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.
+10
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 ?
How to atomate & schedule Veeam.Backup.Validator.exe | Veeam Community Resource Hub
+14
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
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.
I never thought about daily health checks, but thinking about the performance boost with v11a it could be possible. 😄
+12
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.
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 :-)
+13
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.
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,
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?
+12
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?
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)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
