#1 Global Leader in Data Resilience
#1 Global Leader in Data Resilience
BACK TO KB LIST

Alternative Method for Migrating Backups to Hardened Linux Repository

KB ID: 4636
Product: Veeam Backup & Replication | 12.1 | 12.2
Published: 2024-08-06
Last Modified: 2024-09-04
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please, try again later.

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.
req single use creds
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.
req gfs
Example of error that occurs when attempting to complete migration when a Backup Copy Job does not have GFS enabled.

Solution

The complete procedure involves:

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

  1. Stop and disable all jobs targetting the Scale-Out Backup Repository involved in the migration.
  2. 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.
  3. 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.
Cap Tier Window
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.

  1. Add the Linux server(s) that will be hosting the new repositories using single-use credentials.
  2. Create new Linux Repositories (not hardened type).
  3. Add those new non-immutable Linux Repositories to the existing Scale-Out Backup Repository.
  4. Put all the old extents in Maintenance mode.
  5. 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.
  6. 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).

  1. Add the same Linux Repositories to Veeam Backup infrastructure, this time selecting:
    Direct attached storage > Linux (Hardened Repository)
    1. 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.
    2. On the Review step of the wizard, do not select the "Search the repository for existing backups and import backups automatically" check box.
  2. Swap the Non-Immutable Linux Extents for the Hardened Immutable Extents:
    1. Edit the SOBR repository.
    2. Go to the Performance Tier step of the wizard.
    3. Remove each of the non-immutable Linux extents.

      Note: You will likely 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.
    4. With the list of extents now empty, click Add and add each of the hardened Linux repository extents.
    5. Pass through the next wizard steps and finish working with the wizard.

Phase 4: Clean Up & Resume Operations

  1. Remove each of the non-Immutable Linux repositories that were used as part of Phase 2.
  2. Rescan the Scale-Out Backup Repository.
  3. If the Capacity Tier offload window was modified in Phase 1 of this procedure, return the offload window to its previous setting.
  4. 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.

Spelling error in text

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please, try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Start using Veeam:
Download the product
&
Activate the license key
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please, try again later.