Forgive me for this new discussion and please do delete if it is not the right place to ask. I am trying to do a bit of studying around my job currently and wanted to clarify a few points with Veeam (in the process of doing a small course).
I'm getting very confused with the differences between forward incremental and reverse incremental backups and wondered if you could clarify. Am i correct in thinking when choosing forever forward incremental backup, that if there is no synthetic backup scheduled, then the first full backup is completed followed by incremental the days thereafter. Therefore, if you wanted to complete a full restore, you would need to restore that original full backup followed by every single incremental up to the date of the full restore? And if a full backup is done, the retention period is approx 6 months and there are no synthetic backups scheduled.. then if there is a day mid way through that the backup job fails, then this runs the risk of not being able to restore at all? Therefore, putting a strong idea on making sure the synthetic backups are indeed scheduled?
Whereas it was my undserstanding that with reverse incremental backups, it doesn't create separate incremental files but instead takes a snapshot of the entire system and overwrites the same full backup file? So therefore, why are there incremental files and what is the point? Is this for restoration?
I apologise for the questions, any help would be massively appreciated.
To further expand on what Chris has shared… Yes, the different backup methods can be a bit confusing...I agree. The specific area in the User Guide which explains what files are needed when restoring data can be found in the Rollback VMs section under Backup Chains information.
~~~~~
~~~~~
So yes...having all files in a chain is a must. But, I will also say, creating a job with 6mos of retention is not common. Usually, it’s anywhere from 2wks to 1 ½ -2mos, then for longer retention, orgs use GFS.
You are indeed correct about the Forever Fwd method. Veeam creates one full backup, and all remaining backups are incrementals. At the end of the retention period...let’s say it’s 14 days (1 FULL, 13 Incrementals), Veeam will create a 14th Incremental. Since this new point is outside the retention period (15 files are now created instead of the required 14), to adhere to the retention period, Veeam “moves” (merges) the FULL file forward into the earliest Incremental, so now 14 days worth is again on disk. This will repeat each day (merge process). Because all this merging can be taxing on the storage and potentially the b/u files, Veeam recommends maintenance on this files in the form of compact/defragging, which can be configured from the Storage section > Advanced button of a Backup job.
Revese incremental is similar, except the FULL is not at the beginning, but the end...or, the latest backup. The latest/most current backup is an incremental, but gets merged into a FULL file.
Hope this helps.
Some important things to note, a forward incremental backup does require all incremental files between the original “full” backup and the restore point you want to restore, so if something happens to one file in between, that essentially means you can’t restore beyond that point. Veeam isn’t entirely useless here though, there is a “health check” feature (which is not enabled by default) that can detect missing/corrupted restore points and backup missing data again. You still lose whatever was in that particular “version” unless it happens to be the latest version and the data wasn’t modified on the computer since then, but if you use the “health check” feature you’ll still be able to restore newer restore points even if a particular incremental “VIB” file goes missing or becomes corrupted.
When restoring though, Veeam does not restore each individual version one after the other, Veeam does check the contents of each file to know what incremental (VIB) files contain what data, so it just restores the latest version of each file in the backup, but it does need access to all the VIB files in order to do so since it will need to get backup contents from numerous files in order to compose the entire “restore point” that gets restored to the computer.
Reverse incremental backups are better in my opinion due to not relying at all on previous versions to restore the latest version. This assumes of course that you put more importance on being able to restore the very latest backup version than you do on being able to restore any previous version. Which is more useful if you’re thinking from the perspective of “my computer spontaneously burst into flames today” vs “a user accidentally deleted something”.
The difference with “merging” comes in as, when you reach your maximum restore points and merging is needed, forward incremental backups merge the oldest incremental “VIB” file into the original full backup “VBK” file, deleting any expired data from the VBK file in the process. Reverse incremental backups sort of do the opposite, the first backup is a full backup file, the second backup (and any after) adds new data to the full backup file during the process, and then splits out old data into a separate file, so the “full” backup file is the latest version all by itself, when you reach the desired number of restore points the oldest incremental “VIB” files, that are now expired, are simply deleted.
So definitely it depends on your primary use-case for restores as to which you may want to pick. However it is worth noting that Veeam considers reverse incremental backups unreliable and plans to remove the feature at some undetermined point in the future, so that’s also worth considering. You may find yourself forced to redo all of your backups one day if you choose reverse incremental backups.
Veeam’s latest recommendation I’ve seen is that for the most reliable and stable backups you should use Forward Incremental and periodically either do a new Active Full backup (copying all the data from the original computer again, even what’s already backed up) or do a Synthetic Full backup, which (similar to if you restore the computer) takes data from across all your incremental “VIB” files and your original “VBK” file in order to compose a single file that contains an entire “restore point” all by itself, allowing you to delete (or at least not need in the event of a restore) previous files in the chain.
The choice of “Active” vs “Synthetic” largely comes down to how you’re backing up. Depending on your specific setup the process of creating the Synthetic Full Backup may occur entirely on the server-side where the backups are being stored, so you don’t need to transfer all the data from the computer to the repository again, as you would with doing an Active Full Backup. Some scenarios are not like that though, for instance if you’re just using the Veeam Agent to backup to a NAS, in order to do a Synthetic, the computer needs to essentially download all the previous backup data from the NAS, merge it together, and send back a new file that contains your Synthetic Full Backup. But an Active Full Backup would just copy everything from the computer again, which would be faster in that particular scenario. If you’re backing up to a Cloud Connect repository for instance, the Cloud Connect infrastructure will handle merging the data to create the Synthetic Full Backup, so nothing gets transferred from the original computer, but an Active Full Backup would still transfer everything from the computer again, so in that case the Synthetic Full Backup would be faster.
I have somewhere a nice animation of how Forward Incremental vs Reverse Incremental work...let me see if I can find it. Also to note, yes, forever forward exists if you are using forward incremental but have no full backups configured at all, be it either synthetic or active full. If either synthetic or active full exist, it’s a forward incremental, and not a forever forward incremental.
I couldn’t find my copy of the video at first looking, but I did actually find that Veeam has KB’s for how the backup and retention works. No audio of course, but this may give you a better idea of how the retention works visually.
Whereas it was my undserstanding that with reverse incremental backups, it doesn't create separate incremental files but instead takes a snapshot of the entire system and overwrites the same full backup file? So therefore, why are there incremental files and what is the point? Is this for restoration?
First off, if a backup fails, Veeam’s default setting is to retry 3 times. If that were to fail, the next successful backup should contain all of the information that has changed between the last successful incremental (or full) backup and the current date.
The long and the sort of the difference is that in a Forward Incremental, the oldest backup in the chain is going to be a full, and each incremental after that is a copy of any changed blocks. With Reverse Incrementals, the most recent backup is always the full. Changes are written into the full backup, and any blocks that were changed, the old change data is written out of the full to an incremental. This is more IO intensive because you write the data, and then write out the replaced data, but it can offer better performance which is negligible with the read/write speeds of modern arrays. The animations at the below links will give you a visual of how the full advances and where change data is written.
First off, if a backup fails, Veeam’s default setting is to retry 3 times.
Wanted to add that one of the Veeam staff on the forums recently informed me that the Workstation licensed Agent (which does not have configurable retry settings) actually attempts to retry every 10 minutes for 23 hours after a failure, not just 3 times. The default setting of 3 times may still apply elsewhere though, I didn’t ask about other scenarios.
First off, if a backup fails, Veeam’s default setting is to retry 3 times.
Wanted to add that one of the Veeam staff on the forums recently informed me that the Workstation licensed Agent (which does not have configurable retry settings) actually attempts to retry every 10 minutes for 23 hours after a failure, not just 3 times. The default setting of 3 times may still apply elsewhere though, I didn’t ask about other scenarios.
Yeah, the 3 times setting is VBR not the Agent which is longer retry.
Hi @alhero -
Just following up on your Backup Method post. Did any of the provided comments help answer your questions? If so, we ask you select which one helped you as ‘Best Answer’ so others with a similar question who come across your post may benefit.
If you still do have questions, don’t hesitate to ask.
