In the previous Veeam Architect post, we talked about the different transport modes available to move our data from the production VMs, into the backup files, which will be stored in a backup repository that we define.  But, there are a couple different options for a backup repository in Veeam Backup and Replication, so which should you choose?  The one that best fulfills your requirements of course!

A backup repository is simply a location where Veeam stores it’s backup files.  When choosing to add a backup repository in the Veeam console, you will see there are some options:

Microsoft Windows Server

With a windows server, Veeam would deploy the Data Mover agent onto that box, and be able to utilize the local disks attached.  When using windows, we have two options to format our logical drive:

1. NTFS – The default for Microsoft for a while, NTFS is the tried and true file system.  With Server 2012 and above, you can also enable the Deduplication feature.  With this, we can allow windows to deduplicate out backup files.  Be warned, it is recommended not to be used with files over 1 TB.  If your backup job has a lot of VMs, you may go over this size with your VBK (Full backup) file.  Enabling Per-VM-Backup-Chains is a way to bypass this restriction, as each VM will be it’s own VBK file (for full backups) and VIB (for incremental).
2. ReFS – Resilient File System, the newest file system for windows is usually the recommendation for a Veeam repository hosted on Windows storage.   While deduplication is not yet supported on ReFS, Veeam can utilize another feature – Fast Clone.  When the backup job is configured to use a transform operation (synthetic full, Reverse Incremental, etc), what used to happen was each block would be read from the VBK and subsequent files in order to create a new VBK file.  Windows would write each block over to create that new VBK, which can be time-consuming.  With Fast Clone, windows doesn’t bother copying blocks that are already written to disk; instead it simply updates the pointers, so multiple files point to a single common block. Over time, this will result is space saving, as the subsequent full backup files (VBK) will not take up the full file size on disk, due to pointers.

Linux Server

Like Windows, this option allows you to utilize the local storage in a Linux server.  However, we can also utilize an NFS mount too on that server.  Since Veeam runs on Windows, we can’t directly mount an NFS share; but by using a Linux repository we can.

One case where I’ve used this in the past, was with a low-end EMC Data Domain that was not licensed for DD Boost (see below).  The network performance os using an SMB share on the DataDomain was horribly slow, but the NFS implementation was not.  So, I shared the DataDomain to a Linux server as NFS, and added the Linux server as a Linux Repository in Veeam.  In this instance, the backup speed almost doubled vs the SMB implementation.

Shared Folder

Selecting this will allow Veeam to send backup data directly to an SMB share on another device.  If the device is on another network, you can select a managed server to act as a gateway device, so that all traffic destined will be transported via the gateway device, to ensure reliable throughput.

Deduplicating Device

This is the option to choose when using EMC Data Domain with DD Boost, HPE StoreOnce with Catalyst, or and Exagrid device.  Both DD Boost and Catalyst allow Veeam to assist with source-side deduplication.  Essentially, instead of sending all the data, and letting the dedupe device toss what blocks it already has, and only write the unique – Veeam won’t send duplicate blocks over the network, and instead instructs the device to simply update it’s pointers.  This cuts down in network traffic, and data ingestion on the dedupe appliance, which results in speed increases.  With Exagrid, Veeam is able to deploy the Data Mover service directly onto the box, like it does in a Windows or Linux repository, which allows for faster transfer than a standard SMB share.

As you can see, Veeam has some great options for clients on where to store backup data, in a way that is best for the client’s needs.   In the next architecture post and video, we will go over some real-world design scenarios.