Throughout this post we will look at the methods and processes that form the Veeam backup file structure. The file structure really depends on each backup method and schedule; it can also vary slightly, dependant on the tuning of settings.

Backup Methods

There are fundamentally three backup methods that Veeam support across their customer ecosystem, the following sections outline these methods and in which environment they are best suited.

Forever Forward Incremental – The most space efficient method of backup. This will keep one full backup file and then only incremental backups thereafter. When the retention period is met the oldest incremental blocks are merged into the full backup file.

This method delivers highly space efficient backups and is suitable for all storage types.

 Picture1

Forward Incremental – Very simple and easy to understand, similar in operation to the “forever forward incremental” method, however forward incremental creates a regular new active full or synthetic backup. The default setting for the creation of this new backup is every 7 days, however this configuration can be changed as per your requirements.
Again this method is suitable for all storage types.

 Picture2

Reverse Incremental
A reverse incremental produces a backup chain that consists of the last full backup and a set of reverse incremental backups preceding it. This results in the most recent restore point always being a full backup.This method however does have an impact on the backup storage. Because of the additional activity of injecting new backup data into the full backup set as part of each backup job, this increases the amount of disk IO created during a backup. Because of this we should not consider deduplication appliances, software RAID or small storage devices with very few spindles as the best design fit.

 Picture3

It is important to remember that all three methods have one thing in common, the first run of a job creates a full backup of the VM image. All subsequent job runs are only ever incremental copies, (unless we are creating new full backup as part of a forward incremental backup job) containing only those blocks changed between backups, ensuring Veeam delivers outstanding backup efficiency.

Backup Process

After outlining each type of backup method, let’s take a moment to look at how each of these processes work;

On day one, regardless of method, Veeam will take a Full Backup of all virtual machines you have selected within that job.

 Picture4

The following day we then see the differences in how each method processes its backup data. Reverse Incremental has written new changes into the full backup and created a preceding incremental (VRB), whilst both forward methods have created (VIB) files containing changes.

 Picture5

The reverse incremental full backup moves along so all the latest changes are stored in that full backup file (VBK), throughout the retention period that file always contains the most recent backup files.

 Picture6

Fast forward the schedule, this is where you see further differences between the methods.

The forever Incremental has merged the oldest file into the full backup, creating a new VBK file, while continuing to take incremental backups.

In the Forward Incremental, a new Active Full is created meaning that the backup process has taken a copy of all data blocks from the virtual environment, if running a full backup is not practical in an environment, then a synthetic full may be used to reduce impact.

The Reverse Incremental continues as normal, ingesting the changes into the full backup with its incremental preceding it.

By default, all backup jobs are written in one single write stream to a single backup file. However, if you have a backup device capable of supporting multiple write streams, this method means potentially the backup repository becomes a bottleneck.

Per-VM Backups are able to address this, this feature which allows you to reduce the bottleneck, when enabled rather than pushing all VMs into one file, it will create a backup file for each VM meaning multiple write threads. Resources of the storage device will be used more efficiently, and the job performance may increase.

Because this technology is aimed at improving performance of the backup storage, it is set on a per-repository basis. A side effect to consider of using Per-VM backups is the negative effect it has on the effectiveness of duplication and compression. Because each VM now resides in its own backup file it will not de-duplicate with its other VMs within the job.

File Types

From the diagrams above we have already seen several file extensions. The important files that will be seen in every Veeam backup job.

There will be at least one VBK file, after the second iteration of a schedule you will see either a VRB (Reverse Incremental) or a VIB (Forward Incremental) You will also see a VBM file.

VBK – Full Backup File, every job on day one will create VBK file, if within the job configuration an Active Full is scheduled, this will also create another VBK file. A Synthetic Full will also create a new VBK file wrapping previous incremental backups.

VRB / VIB – Depending on the Backup Method chosen you will see either a VRB / VIB within the backup repository, these contain the incremental changes from the VM images following the configured schedule.

VBM – The VBM file is the backup metadata file which contains information on the backup job, VMs, structure of backup files and restore points.

Below are the files shown within a backup repository. This particular job has a 14-day retention with an Active Full Scheduled for the Saturday of every week.

 Picture7

Veeam backup files bring many advantages to your Availability experience. The files mentioned are fully portable, they can easily be moved between environments, furthermore the backup files can be used directly by any Veeam Backup & Replication instance (there’s no dependence on a catalog or database). In addition, these Files give you the ability to secure the files using built-in Veeam AES-256-bit encryption.

Leave a Reply

Your email address will not be published. Required fields are marked *