Alternative Method for Migrating Backups to Hardened Linux Repository
Please review the information in this article closely before performing any actions documented herein.
This article documents a series of steps that if not performed precisely as documented, could result in data loss.
Purpose
This article documents an alternative method for migrating backups from a Scale-Out Backup Repository (SOBR) utilizing non-immutable performance tier extents to one using Hardened Linux Immutable performance tier extents.
This method is useful in situations where a SOBR contains backup data that cannot be moved using the Backup Move function, such as those created by:
If your environment does not involve any of the aforementioned job types that cannot be moved using Backup Move, you are welcome to use the much more straightforward migration method of simply adding a new repository using Hardened Linux Repository (either simple or as extents part of Scale-Out Backup Repository), and then use Backup Move to migrate the backup data to the immutable storage.
Requirements
The migration procedure documented in this article requires:
- All backups being migrated are currently located on a performance tier extent of a Scale-Out Backup Repository.
The migration procedure utilizes the Evacuate Backups function to relocate all backup data from the non-immutable extent(s) to the hardened linux repository extent(s).
If backups are currently located on a simple repository, create a new Scale-Out Backup Repository and add that simple repository as a performance tier extent. - The Linux Server that will, in the end, be used as a Hardened Linux Repository must have been added to VBR using single-use credentials.
Example of error that occurs if Linux server was not added with single-use credentials.
Clicking Yes will load the Edit Linux Server wizard and force you to enter single-use credentials.
- All Backup Copy Jobs that will have their backup files migrated must have GFS enabled.
- If any Backup Copy Job that will be migrated does not have GFS presently enabled, simply enable at least 1 weekly GFS point.
Example of error that occurs when attempting to complete migration when a Backup Copy Job does not have GFS enabled.
Solution
If the current performance tier extents utilize Fast Clone functionality, this migration procedure will preserve that space saving and functionality, so long as the destination Linux storage is configured appropriately.
Phase 1: Prepare for Migration
- Stop and disable all jobs targetting the Scale-Out Backup Repository involved in the migration.
- Review each Backup Copy job and ensure they all have GFS enabled.
Note: If you are unsure which jobs do not have GFS enabled or there are too many to review manually, this prep step can be skipped, and the software will stop you during the migration and present a list of Backup Copy jobs that need to be adjusted. - If the Scale-Out Backup Repository utilizes a capacity tier, modify the Offload window to prevent offload tasks from attempting to run during the migration.
In this example, the migration is occurring on Tuesday, so the single selected window is a week out next Monday.
Phase 2: Evacute Backups to Non-Immutable Linux Storage
The Linux Extents will be initially added to the SOBR as non-immutable, allowing existing backup data to be evacuated to them.
- Add the Linux server(s) that will be hosting the new repositories using single-use credentials.
- Create new Linux Repositories (not hardened type).
- Add those new non-immutable Linux Repositories to the existing Scale-Out Backup Repository.
- Put all the old extents in Maintenance mode.
- Highlight all the old extents and Evacuate their backup data.
Since the new Linux-based extents are the only ones not in Maintenance mode, all backup data will be evacuated to them. - After the evacuation has completed, edit the SOBR repository and remove each of the old extents from the SOBR.
Phase 3: Swap Mutable Linux Extents to Hardened Extents
Now that the Linux Extent(s) contains all the backup data, you'll add Linux-based repositories again, but this time as hardened. Then, as a single action, you will both remove the non-immutable extent(s) and add the hardened immutable extent(s).
- Add the same Linux Repositories to Veeam Backup infrastructure, this time selecting:
Direct attached storage > Linux (Hardened Repository)
- Ensure that on the Repository step of the wizard, the same directory is used as was selected when the initial non-immutable Linux repositories were added.
- On the Review step of the wizard, do not select the "Search the repository for existing backups and import backups automatically" check box.
- Ensure that on the Repository step of the wizard, the same directory is used as was selected when the initial non-immutable Linux repositories were added.
- Swap the Non-Immutable Linux Extents for the Hardened Immutable Extents:
- Edit the SOBR repository.
- Go to the Performance Tier step of the wizard.
- Remove each of the non-immutable Linux extents.
Note: If the capacity tier is in use, you will be warned that "The scale-out backup repository extent selected for removal contains backup files." And, you will be asked whether you wish to remove the extent without evacuating the backups. Select Yes. - With the list of extents now empty, click Add and add each of the hardened Linux repository extents.
- Pass through the next wizard steps and finish working with the wizard.
Phase 4: Clean Up & Resume Operations
- Remove each of the non-Immutable Linux repositories that were used as part of Phase 2.
- Rescan the Scale-Out Backup Repository.
- If the Capacity Tier offload window was modified in Phase 1 of this procedure, return the offload window to its previous setting.
- Enable all jobs that were disabled in Phase 1 of this procedure.
More Information
Immutability on the migrated backups will be set after the next job run.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.