Walkthrough of "moving" a prototype repo VM to a physical host?

[cosmik]

I've been cooking my B&R installation: part of it is of a production level, whereas part of it is unfinished.

One of the major parts is the backup repo. For testing purposes I've implemented it as a Linux VM, running on Debian 11. The Linux VM itself does not have any storage though; it is attached to an iSCSI share, formatted for XFS/reflink. The VM also is setup with single-use credentials and has activated immutable backups.

Now is the time to "move" this thing from virtual to a physical host (a 10th gen i5 with 16Gb of RAM). So far I'm installing the same packages that exist on the VM (xfstools, open-iscsi, ntp etc) and I've reached a point where I can attach just fine to the same iSCSI LUNs. Obviously, mounting the XFS iSCSI LUN shows me the backups I've already taken with BR.

The new physical system will have the same DNS/IP with the one it is going to replace.

My question is how to proceed from here. Or, IOW, how to properly decommission the virtual repo and add the physical-based as a new one without losing the backups!

If Veeam can "detect" and import the backups, my idea would be to delete the existing repo, power down the VM, powerup the physical server, and add it as a repo asking to import the existing backups. Not sure if this a good practice.

[veremin]

If you are going to add new server as a new repository, you will need to re-map existing jobs afterwards (map backup link on the Storage setting page).

However, since it’s the same name and the same content (the same LUN) I believe you can simply proceed with existing repository (just power down old machine and power up new machine). Once it comes alive:

- open a managed server wizard, walk through it and re-enter credentials
- open a backup repository wizard, walk through it (this will detect and install missing components)

After that, everything should be working smoothly.

Thanks!

[cosmik]

Sounds great, will try it on Tuesday, once my last test with the VM prototype completes!

[veremin]

You're welcome. Kindly, keep us updated on the results of your migration. Thanks!

[cosmik]

Does not work unfortunately. Like I said, since it has single use credentials it can neither connect to the repo, nor repair it

I'm in a deadlock: in order to remove the repo, I had to move the vbr config backups elsewhere (done) and also move the existing backups of my jobs elsewhere (can't do, not enough space elsewhere). What can I do?

[veremin]

Have you re-entered credentials from scratch while in the managed server wizard (not in repository one)?

[cosmik]

I'd be grateful if you could point out where exactly I should do that.

Can this be done with single use credentials?

[cosmik]

Have you re-entered credentials from scratch while in the managed server wizard (not in repository one)?

Found my linux repo under backup infrastructure -> Managed Servers -> Linux. Went to the wizard properties and was able to re-enter my single use credentials. Upon pressing reply though the procedure ended with errors:

(Green tick) Starting infrastructure item update process
(Red X) Failed to save Linux server: Single-use credentials require Veeam Data Mover service installed
(Red X) Infrastructure item save failed error: Single-use credentials require Veeam Data mover service installed.

Ideas?

[veremin]

Discussed with Q&A team. To make the scenario work, you will need to remove the backup repository and managed server first and re-add them again, using the approach above. Otherwise, you can open a support ticket and let them remove the data mover service entities from the configuration database (this will solve the given issues).

If you proceed with opening a support ticket, share its number here so I can ask the Q&A team to assist with the resolution process.

Thanks!

[cosmik]

Strange, I thought I had replied this one, stating that there was a reddit response prompting to add the non-root Linux user to the adm group. That did the trick! See also https://www.reddit.com/r/Veeam/comments ... &context=3

Backups are taken just fine from the new physical server.

[veremin]

Thanks for coming back and sharing the resolution; much appreciated!