Synthetic full backups and file versioning

[Hepkat]

Hi everyone,

So we made the switch from Veritas Backup Exec a couple months ago to Veeam, and so far I'm quite happy. I do have a question however about synthetic full backups and file versioning.

My client is a small company with about 15 users and 2 servers (Veeam & Exchange). Current backup strategy: nightly forever incremental backups on 32TB REFS direct attached storage. Due to a couple virus attacks as well as a particularly nasty ransomware episode (all under my predecessor I might add), the client insists on permanent retention of all data, hence forever incrementals. So far so good, but we all know it's only a matter of time before we run out of space and file restoration with hundreds of restore points won't be pretty either.

So I've been toying around with the idea of synthetic full backups, but haven't been able to find any information about file versioning, and believe me, I've been doing a lot of online research these past couple of weeks on the subject. According to Veeam, "A synthetic full backup takes the last full backup and all the incremental backups that have occurred since then and merges them on the backup repository side". But what exactly do they mean by "merge"? What's the algorithm? So far I've been unable to find any explanation whatsoever. More specifically I'd like to know what happens to different versions of the same file. In a forever incremental strategy, you can restore any version of any file going all the way back to the first full backup. How does a synthetic full backup "merge" all these different file versions? Do all file versions get "merged" together into the synthetic full backup file, allowing you to choose which version to restore at a later date? Or does only the latest file version get "merged", meaning all previous versions are discarded?

To date I've been unable to find any details on the above topic. I'd be very grateful if someone more knowledgeable on the subject could provide an answer.

Thanks for your help!
Kurt

[pybfr]

Hello, you will more detail on how forever forward works here:

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

And here:
https://www.veeam.com/kb1932

And here:
https://bp.veeam.com/vbr/4_Operations/O ... thods.html

[Hepkat]

Hey, thanks for the links, but none of that is anything new.

[Mildur]

Hi Kurt,

A restore point in Veeam is a point-in-time snapshot of your machine. It allows you to restore files exactly as they were at the moment the backup was created. The more frequently you run your backups, the more versions of your files are protected.

Synthetic Full and merging processes do not relate to "versions of your production data files."
A single backup file (VBK or VIB) contains only one version of each file, representing its state at the time the backup was taken.

Synthetic Full:
Instead of reading all data from the source machine, Veeam reuses backup data blocks from previous backup files to create a new backup file. With ReFS, Fast Clone is supported, making synthetic full backups performant and space-efficient. Only changed data is written and stored on the repository; unchanged data blocks are referenced from previous backup files.

Merging with Forever Forward Incremental:
You will have a single full backup and a number of incremental backup files. On the day of the backup, the oldest incremental backup is merged into the full backup file, making it the "new full backup file of your backup chain". This process is explained in detail in KB1932, as shared by Pierre-Yves.

Due to a couple virus attacks as well as a particularly nasty ransomware episode (all under my predecessor I might add), the client insists on permanent retention of all data, hence forever incrementals.

Keep in mind that "permanent retention" is not sufficient protection if ransomware targets the backup server. Consider implementing immutable backup storage, such as Veeam Hardened Repository, immutable object storage, immutable deduplication appliances, or a Cloud Connect provider. Backup to tape jobs can also be beneficial. ReFS does not provide protection against malicious actors with access to the backup server.

Best regards,
Fabian

[Hepkat]

Hi Fabian,

Thanks for responding, but I think we might have gotten our wires crossed. That's probably my fault, so let me explain again in more detail.

So let's take a typical office scenario:

1. On day 1 of the week, network admin does a full backup
2. On day 2 user 1 modifies the file Sales_2025.xlsx. An incremental backup is run later that night.
3. On day 3, user 2 modifies the same file, another incremental backup is run later that night.
4. On day 4, user 3 modifies the same file yet again, and another incremental backup is run later that night.
5. And so on until the end of the work week.

So now we end up with:

Day 1: Full backup containing VERSION 1 of Sales_2025.xlsx
Day 2: Incremental backup containing VERSION 2 of said file
Day 3: Incremental backup containing VERSION 3
Day 4: Incremental backup containing VERSION 4
Day 5: Incremental backup containing VERSION 5

Network admin does a synthetic full backup on the weekend, creating a new full backup file in the backup chain. Which version of Sales_2025.xlsx gets included in the new backup file at the start of the new backup chain? According to your answer:

the oldest incremental backup is merged into the full backup file, making it the "new full backup file of your backup chain".

...meaning VERSION 2 gets advanced to the front of the backup chain. What happens to VERSIONS 1, 3, 4, and 5? Do they just get discarded?

Believe it or not, your regular office employee doesn't tend to be the most sophisticated user, which means as the tech guy I get requested all the time to restore such and such a file from a specific date, which is why this client insists on permanent retention of ALL file versions.

Keep in mind that "permanent retention" is not sufficient protection if ransomware targets the backup server.

We have a backup copy job that stores to an off-site repository on a separate domain.

Thanks again for your time and patience!

Regards,
Kurt

[Hepkat]

Any response anyone? Can no one explain how different versions of the same file are treated in a full synthetic backup per the above scenario?

This is one of my biggest gripes with Veeam, no adequate explanation for simple everyday issues such as this. We find tons of info online explaining that a synthetic full backup merges the last full backup and all the incremental backups that have occurred since then, but NO DETAILS WHATSOEVER as to what that actually means. Even those flimsy animations fail to provide adequate clarity. I've even sat through hours of YouTube tutorials from the Veeam channel, and nada, nichts, NOTHING! They just make blanket statements and YOU have to figure out on your own through days of trial and error how the algorithm that merges all the incremental backups work. Problem is, no one has several days time to sit down and figure this out when you're running a dozen servers with 40TB of backup data.

[Yapman]

So I think the links explain this pretty well.
This one for example (https://www.veeam.com/kb1932) explains your example well.

So now we end up with:

Day 1: Full backup containing VERSION 1 of Sales_2025.xlsx
Day 2: Incremental backup containing VERSION 2 of said file
Day 3: Incremental backup containing VERSION 3
Day 4: Incremental backup containing VERSION 4
Day 5: Incremental backup containing VERSION 5

So for this the Next Full Synthetic would contain Version 5 of the file.

Think of a Synthetic full just like any other backup, the only difference is on how its created.

A simple way of looking at it a Synthetic full is just a incremental backup, then it use's the previous incremental backups and Full backups to create a "Full" backup

[Hepkat]

So for this the Next Full Synthetic would contain Version 5 of the file.

And what happens to Versions 1 through 4? Do they end up discarded?

[tyler.jurgens]

Versions 1 through 4 would be captured in the incremental backup that was taken on those days (assuming the incremental backup was taken at the appropriate time to capture that change).

[Hepkat]

Hi everyone,

Based on all your responses, I'm finding it difficult to see the added value in synthetic full backups. If version 5 is advanced to the front of the backup chain during the synthetic full backup AND I have to keep the incremental backup files containing versions 1 to 4 just in order to maintain seamless access to all versions of the file, then what use is a synthetic full backup? Might as well keep the original full backup as well as all incrementals.

Anyway, thanks for all your responses. Really appreciated!

Regards,
Kurt

[david.domask]

Hey Kurt, will add my 2 cents on the topic.

>I'm finding it difficult to see the added value in synthetic full backups

Value is simple:

1. Workload for creating a full backup is shifted from production to the repository
2. With Fast Clone, you get fast & "space-less" full backups
3. Full backups are usually a requirement

I think part of where you're getting thrown a bit here is that you need to differentiate between image level backups (backups of the entire machine) vs the granularity of file version backups that you've been asking about.

Image level backups capture the state of the machine at time of backup, as was mentioned before in the thread by others. If you're needing more granular control over file versioning, a file-level approach with Unstructured Data Backups is best, as that gives you the fine file level version control with minimal storage foot print.

You can have that kind of file version control with image level backups, it just means you will be having many incremental restore points to reflect that level of granularity -- if that works for you, then it works for you; Enterprise Manager allows you to browse through the guest file index to look for files from image level backups of a machine and helps a lot if you do go with this approach.

So from your original post, you ask about how it handles all the different file versions in a Synthetic Full, and the answer is simply that it doesn't really care, the goal of an image level backup is to capture the state of a machine at a specific point in time.

If you need more granular file level versioning than you get with the frequency of image level backups, use a file level backup approach like Unstructured Data Backup (this can be done in addition to normal image level backups, and it's pretty common option when both are required)

[Hepkat]

Thanks David, you gave me a lot to think about. Seems like this unstructured data backup's the way to go!