File inclusions and exclusions explained with Veeam Backup & Replication

A few years ago, the file exclusion engine was introduced to Veeam Backup & Replication. This was primarily meant to handle situations such as a large set file data that you didn’t need in an image-based backup. One example I had users liked was a SQL Server (especially before Veeam Explorer for Microsoft SQL Server) that had SQL Server DBAs performing SQL Server Agent jobs or SQL Server Maintenance Plans to export flat backups on disk and transaction log exports.

With the file exclusion, Veeam could optionally take the image-based backup of the VM running SQL Server and exclude the disk geometry that stored the files specified in the backup job. This is an extension of the same logic used in the backup job to exclude the swap file.

The other half of this capability is the file inclusion. This becomes very interesting as it can be very useful for giving parts of a VM the opportunity to have additional RPOs in addition to that of a regular Veeam backup job that takes the whole image. The figure below shows where you can set a file inclusion:

This may seem like a small capability, but when you think about the logic for including files only, it can be very flexible. With this configuration in a backup job, a few things need to be considered:

When talking to customers and partners, this capability has been very useful as an extra backup job to give “that one folder” (that is very important) a bit more Availability than what the regular backup job may bring. It is important to additionally note that at VeeamON we announced NAS backup support for Veeam Backup & Replication v10. This will be an option as well, but if the system is a virtual machine and the requirement for a file backup logic is very specific to include all files in a folder, this logic may be better. The NAS backup logic coming in v10 will be based on revisions of a file at the time of the backup job. The retention is also based on the number of revisions where the file inclusion job is based on a restore point (always) for all files selected in the backup job.

An additional angle here is an extra layer of ransomware resiliency. By having the file inclusions in a separate backup job, this may be more resilient in a situation where you restore a file server from an image-based backup only to have the ransomware re-infect the restored data. This is the perfect time to remind everyone about SureBackup (which by the way is 7 years old in 2017!).

Do you have a use case where you have an image-based backup and a separate backup job just for some particular files? The file inclusions and exclusions may be something to consider. Share your ideas below.

Exit mobile version