Best Practice for transitioning ExaGrid deployments to use Veeam SOBR

Challenge

Solution

Requirements

1. Veeam 9.5 update 2 or later. Enterprise Plus license is required to configure more than one SOBR repository with more than 3 extents. Most ExaGrid deployments will require an Enterprise Plus Veeam license.
2. ExaGrid 5.0.0 or later
3. Use of ExaGrid Veeam Accelerated Data Mover – i.e. not using CIFS Veeam shares

Goals

1. Simplify the interop between Veeam and ExaGrid
2. Increased operational flexibility while maintaining high overall deduplication:
   1. No need to move around/balance Veeam jobs to “fit” the ExaGrid deployment
   2. Move VM(s) between Veeam jobs at any time without negatively impacting ExaGrid dedup or repository storage consumption.
   3. Expansion of ExaGrid deployment (adding appliances to site) is seamlessly integrated into Veeam job/VM/retention management. True end-to-end scale out in your backup environment.
3. Let Veeam decide where to put VM backups rather than burdening backup administrator
4. Load balance Veeam jobs across ExaGrid servers based on target storage capacity and other Veeam policy settings – see below.

Key Concepts

1. Entire ExaGrid site (collection of servers) is configured in Veeam as a single storage space via a single Veeam Scale Out Backup Repository (SOBR). Each ExaGrid server has only a single Veeam Data Mover share, and it is configured in Veeam as a SOBR “extent”.
2. For Veeam to make good decisions about where to put new backups, there should be only a single Veeam data mover share on each ExaGrid appliance that receives backups. If there are multiple ExaGrid shares (not in maintenance mode) configured as multiple Veeam SOBR extents, Veeam will double or triple count the free space reported by an ExaGrid server, allowing Veeam to start backups to a target that in fact does not have sufficient space – ultimately leading to the failure of the mis-placed Veeam backup job or backup copy job.
3. Veeam decides where to put VM backups – based on free space on each ExaGrid server at time of backup and other Veeam policy settings. See the section Extent Selection in this Veeam document.
4. When using Veeam backup copy jobs for extended retention, Veeam does require one SOBR for backup jobs, and a separate SOBR for backup copy jobs, so each ExaGrid site (collection of servers) requires only two Veeam SOBRs.
5. Utilize Veeam’s “data location” SOBR policy to encourage Veeam to keep fulls and incrementals in the same ExaGrid server. Not strictly necessary with ExaGrid version 5.0.0 and later, however this increases ExaGrid processing efficiency.
6. Utilize Veeam’s job option to start a new backup chain on a different SOBR extent when the extent with the backup job chain does not have sufficient space.
7. Veeam’s SOBR algorithms are covered in Veeam documentation – such as how it estimates target storage requirements for full backups, incremental backups, etc.

Transition to Veeam SOBR

Most ExaGrid deployments with Veeam Backup and Replication will have either one or several Veeam shares allocated on each ExaGrid server. The steps below outline how to transition from an ExaGrid multi-server, multi-share configuration to the most efficient Veeam SOBR configuration.

1. On each ExaGrid server:
   1. Create a new Veeam share that utilizes the Data Mover (cannot be CIFS)
   2. Create two new Veeam repositories for each server, each pointing to an appropriate new directory in the share (i.e. backups, copy_job). During the creation of the Veeam repository, you create a new folder that uniquely separates the backups from copy jobs.
2. Create two SOBRs, one for backups, and one for copy jobs
   1. Add the old and new Veeam repositories to their appropriate SOBR.
   2. Existing jobs will be re-pointed automatically to their appropriate SOBR.
3. Put all old backup and copy job repositories into maintenance mode
   1. This will allow Veeam to still see the old locations/backups, but all new backups will go to the new ExaGrid shares
4. Run active fulls for all jobs, or ignore the Veeam warning about having to start a new backup chain on the next run
   1. In any case, a new full will be forced for all jobs, as the existing chains are on extents in maintenance mode. This new full will be send to the new ExaGrid Data Mover share.
5. Wait for the data to age out on the old repositories
   1. Veeam will not automatically delete aged-out backups from repositories in maintenance mode. If no backups are running or will run in the near future, you can take the extent out of maintenance mode, delete the backups using Veeam (under the “Backups..Disk” item in the BACKUP & REPLICATION navigation), and then be sure to put the extent back into maintenance mode so it won’t be used for new backups. Or, work with ExaGrid support to manually delete aged-out data from each old repository.
   2. Note that Veeam will only delete older backups when a Veeam job runs.
   3. As each repository becomes empty, delete the repository from Veeam
   4. As old ExaGrid shares become empty, delete them from each ExaGrid server

When the transitions is completed, there will be two repositories per ExaGrid server, and two SOBRs in total for the entire ExaGrid site. While waiting for data to age out, individual repositories can be brought back online temporarily, if needed, for restores. Be sure to put old repositories back into maintenance mode when any legacy restores are complete.