Skip to main content

Hi Community

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 the 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 highlighted 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.

Those are some interesting scenarios and I love you can move backups with Veeam.  Great post! 😎


Great test & post @Andanet . If I recall, I’m thinking the Move function doesn’t work for Repositories who’s settings are not configured to use Per-VM...correct?


Great test & post @Andanet . If I recall, I’m thinking the Move function doesn’t work for Repositories who’s settings are not configured to use Per-VM...correct?

From Veeam doc

https://helpcenter.veeam.com/docs/backup/vsphere/backup_moving.html?ver=120

You can move backups between repositories with the Use per-machine backup files check box selected and not selected. However, the move operation does not change the backup chain format (single-file backup, per-machine backup with single metadata file or per-machine backup with separate metadata files). The job will continue the backup chain of the original backup chain format. If you want to change the backup chain format of the chain, use the detach from job operation. For more information, see Upgrading Backup Chain Formats.

mFor moving to object storage repositories] You can move only per-machine backups with separate metadata files.

In my case was from S3 to S3 repos… in S3 repo you can’t choose per-vm backup options… so this means if you want to move from a file or block repository to an ObjStorage. 

 


Ah ok. I remembered there was something about the per-vm setting and moving 😊 Thank you for the clarification. 


Grazie @Andanet for you sharing !


Really good post and VeeaMover is a great v12 feature. One thing I’ve found in my usage is that the above is fine for smaller amounts of data but for larger repositories I would reccomend you do the Copy then delete with manual job update. This protects you from any issues that may occur in the move.

Further if you are moving across clouds or if the storage is remote from your VBR consider using storage gateways to act as your data movers. This can retroactively be added to a given bucket and will greatly decrease egress and other fees for use.


Comment