Veeam B&R – Moving backups files to another repository

Today I’ve spent my time in our lab and I realised I made a mistake by choosing a bucket without immutability in our backup job.

So I dedicated some time looking into how I could move backups to another repository in Veeam B&R Console.

Before I started, I wondered why I would want to use the ‘Move backup’ function in a production environment.

  • I said to myself that it might be necessary to do this in such cases as:
  • Wrong configuration in a backup job
  • Backup repository is close to full capacity.
  • I must replace my repository (because out of warranty).
  • Backup job policies are changed (immutable backup request or different policy needed).

 

“Move Backup” operation permit to continue to use the same Job, moving backup files to a new backup location, and keeping job history and backup chain.

SCENARIO

In our lab we have this scenario:

  • Veeam B&R v. 12.1.2.172
  • OLD repo: S3 Bucket without versioning called Pippo02 (yes is Goofy)
  • NEW repo: S3 Bucket with versioning enabled (immutable) Pippo01
  • 1 backup jobs with 4 Virtual machines with Optimal compression and 4 MB block optimization
  • 1 backup jobs with 4 Virtual machines with High compression and 1 MB block optimization

Both bucket are on th Object First Appliance received in July. This was sizing before to start with moving

Steps

Ok… so let’s start with the operation.

According to Veeam documentation (https://helpcenter.veeam.com/docs/backup/vsphere/backup_moving.html?ver=120)

I disable my backup job and start with moving operation.

Now under Backups-Object Storage I checked the properties of my backup job

Then right-click on the job want to move, select Move Backup.

A pop-up window appears; here you can choose your new repository. As you can see it’s a drop-down menu with all repositories you have.

I want to move on OOTBI_IMMUTABILE target repository.

If you click on “Show Backup” button you can see moving backup job

Click OK

The moving job starts and Veeam move all backups

For every VM backup chain moved you can see these messages on report

At the end this is the moving result

As you can see Target Repository automatically updated on Backup job and backup files are deleted from previous repository.

Checking on Veeam Backup Infrastructure, under Backup repository now I can see the differences on the repo usage:

Before moving

After moving

 

As you can see the OOTBI_IMMUTABILE usage changes from 0 to 236,6GB

 

Same check on the Object First web interface.

NOTE: After moving we can see 254GB as Generic S3 data because, I think, the process is similar to use a S3 client this means metadata file are not directed connected to the backup data.

Only after a backup job run, data has correct size in Backup data column

 

Moving backups – Option 2

The same result as now explained can be achieved during an Edit of your backup job.

At the Storage tabs you can open the drop-down menu, select new repository destination

Click on Next.

At this point you can see this pop-up

When checking finish you receive a question where you can choose if you want to move existing backup chain or perform a new full backup without moving.

Moving backups – Option3

 

A third option is using the Powershell command:

Move-VBRBackup -Backup BAckupJobName -Repository NewRepository

Use the BackupJobName and NewRepository name then you can see the progress in the powershell bar.

On Veeam B&R console you can see the job running

 

Moving backups – Deleting Test

I tried to delete moved  backup files after Move job and after another backup job runs. Results was the same… I cannot delete backup file because are marked as immutable:

Failed to delete backup Error: Unable to delete the backup because it is marked as immutable until 07 September 2024 13:22:21

After backup job running

Before backup job running

What have I learned from these tests?

  1. Moving allows space to be freed up from a distressed repository much faster than before.
  2. Moving allows backup administrators to start quickly when the repository fills up, and to plan ahead for the decommissioning of obsolete storage.
  3. With this functionality, it is therefore possible to maintain the same backup job naming and backup chains.

I look forward to seeing you at the next lab test and thank you for taking the time to read this article.