Best method to move/copy backup copy jobs to Vault

[suntech]

Hi,

Case #07628082

We are using AWS as our capacity tier. What is the best way to move (or copy) the backup copy jobs from AWS to Veeam Vault?

The vault is set up and ready. I suspect I have to recreate the jobs themselves, but I need to retain the current backups and continue working with them.

I'm trying to find the right documentation but am also attempting to reacquaint myself with Veeam software and usage because I'm sure the software has new attributes that I don't know of.

I also like when people discuss what works for them, how it works, and what to watch out for. Other user's experiences are valuable.

[georgi.matev]

@suntech were you able to get a recommendation on the procedure from your support case (I can't check it right now)? This is something the support team should be able to help you with.

If you have not gotten anything yet, please check out this for VBR12 you can check out the relevant section of the docs at https://helpcenter.veeam.com/docs/backu ... positories. In this case Vault will be just like any other object storage repository.

Please let us know if the above is not helpful.

[suntech]

I have a handful of web pages with documentation but I was hoping for something more specific.

I also realized I could specify that I'd like to move or copy the AWS capacity tier files along with files on the onsite performance tier. I saw a suggestion that Veeam Mover can move or copy the backup files from one repository to another. If this is a valid way to handle populating the New Veeam Vault Repository, I'm curious concerning creating the backup copy jobs that will recognize the copied files and go on as it has been for the past year.

I suspect, Copy the backups, create (or clone the old jobs) point them to the new repository, and possibly import the files into the jobs if necessary. I'm probably overthinking but want to avoid going sideways on this.

I'm checking the link you posted too when I can.

[veremin]

If you plan to migrate the capacity tier, we recommend disabling any offload activity on Capacity Tier first (you can go into the Scale-Out Backup Repository settings and disable all Capacity Tier policies: be it move or copy policy). Then, enable sealed mode on the previous capacity extent (AWS S3), add the new repository (Veeam Data Cloud Vault), add it as additional capacity extent to Scale-Out Backup Repository, enable maintenance mode on the previous capacity extent, and start the evacuation from it.

Thanks!

[suntech]

I'm walking through the docs which reflect your suggestion. I want to avoid making a mistake.

[veremin]

You can also refer to the "What's New" document dedicated to the new features of version 12.3, where we explicitly describe this functionality:

Enhanced migration experience — Extents from different object storage systems and/or extents with different immutability settings can now coexist within the same Performance and Capacity tier, unlocking many migration scenarios. For example, this allows you to easily move your backup from one cloud object storage provider to another, or from non-immutable bucket to a bucket with immutability enabled. To add an extent of a different type, you need to first put existing extents into the sealed mode.

Thanks!

[suntech]

I am going through the suggested documents. I really thought there would be a simple copy option by right clicking on a backup job. I don't want to make a mistake.

I believe one suggestion is to copy or move all the backup jobs from the capacity tier to the performance tier, but the performance tier doesn't have the space available.

[veremin]

The functionality for copying backups is not available for backups stored in the Capacity Tier. Therefore, you should follow the procedure I described earlier—it is straightforward and should not cause any issues. Simply disable all policies on the old Capacity Tier, then enable sealed mode on it. Next, add a new Capacity extent (Vault), enable maintenance mode on the old extent, and initiate the evacuation of backups.

As stated in the document referenced above, this procedure was specifically designed to support migration scenarios similar to yours.

Thank you.

[suntech]

Okay. What you wrote makes sense. I'm going to try to get started. I tend to overthink.

[suntech]

Veeam Vault capacity extent needs to be placed inside the same scale-out repository as the AWS one? I want to be certain. I'm a visual learner.

I performed the first part. Sealing the current extent and placing it in maintenance mode.

[suntech]

I think I went sideways on this. I'm going to ask support if they can look at it. The AWS capacity object is no longer in its scale out repository with the Local performance tier.

[veremin]

Yes, you should add the Vault repository to the same Scale-Out Backup Repository, to its Capacity Tier.

I didn’t quite understand your last sentence, but you can add the AWS repository back as a Capacity Tier and then initiate evacuation from it. However, I agree that if you’re not confident in performing these actions, it’s better to contact technical support.

Thanks!

[suntech]

I seriously appreciate your feedback. In the old days, I could have spent more time absorbing these tasks.

I'm going to make it the way it was and walk through your suggestions again. I'll contact support if I slip.

[veremin]

As I mentioned, you can add your former Capacity extent back. In this case, when you add a Capacity extent back to a SOBR, the wizard will verify if any backups are present on it during the "Next" step, and once the wizard is closed, a rescan will be triggered.

After the rescan is completed and the previous backups are detected, you can follow the migration procedure described earlier.

Thanks!

[suntech]

Cool! I wish I had come straight to this discussion this morning.

[suntech]

I have the evacuation started. I suspect this will be quite a while considering the size of the AWS capacity.

[veremin]

I'm glad you managed to start the backup evacuation. Indeed, depending on the size of the data being transferred, the process may take some time.

[suntech]

I totally should have asked whether the move goes straight to vault, or if it goes to the performance tier.

[veremin]

Evacuation takes places between previous capacity extent and new one, and performance tier is not involved in this process.

[suntech]

Thank you for your good advice, Veremin.

The evacuation is still running.

[suntech]

I didn't have the performance tier set for maintenance. Is it okay to place the performance tier in maintenance and evacuate without causing an issue? I'm not sure how I missed having both in maintenance mode if I was supposed to.

[veremin]

If you don’t plan to change your current performance tier, then there’s no need to put it into maintenance mode and evacuate backups from it.

[suntech]

Okay. To be honest, I was uncertain of our ultimate plan, whether it was to backup directly to the vault or to use the performance tier. It can stay the way it is. I removed the AWS object.

One job folder does not show in the capacity tier disk view. I'm running a full backup of the unseen job in case it helps trigger the folder to appear.

[veremin]

This seems unusual. Perhaps you should enlist the help of our technical support engineers if the backups previously stored in the previous capacity tier do not appear in the new one.

Thanks.

[suntech]

I suspect that the backups in the previous S3 tier haven't been transferred. I notified support. I could be wrong about that but I pretended to do a restore and didn't see backups from before 2025. There should have been yearly options.

[veremin]

A wild guess—could it be that the archive tier is also enabled, and the GFS points might have been moved there from the capacity tier? If not, please continue working with the support engineer—they will review the debug logs and will likely be able to identify the issue.

Thanks!

[suntech]

Good idea. I'll ask which logs.

[ericschott_OF]

I would suggest watch your egress fees in AWS doing this