Skip to main content
Solved

Recovery from Veeam Hardened Repository


Forum|alt.badge.img

Hello, everyone!

 

I have been studying and doing some labs to better understand how the immutability on a Linux Repository works.

 

This is my current Veeam Backup & Replication structure:

- 1 Backup Job for VMware VMs;

- 1 windows agent Backup Job for a physical machine;

- 1 Backup Copy job for each of the previous jobs, with the hardened repository as the target.

 

The hardened repository is a Ubuntu 20.04 LTS with a XFS disk. The SSH service is disabled and no gateway is set. The Veeam server was first configured to use a single-use credential.

Everything works great!

 

My question is:

In a scenario where all the VMs, physical servers and Veeam server are lost, where all I have are the immutable backups, how should I approach the repository?

What I did so far was:

- Start the SSH service of the hardened repository, open the port 22 in OS firewall;

- Get a separate windows machine running and install Veeam B&R in it;

When I tried to add the Linux repository to the new Veeam server, it could not connect using the "single-use credential for hardened repositories" option (I verified the credentials and they were correct). When I tried using the same credentials with the "Linux account" option, it worked.

 

How should I approach this type of scenario? Is it ok to use this other account option? Will I need to create another account with the same restrictions as before to set it to "single-use" as it was before? How do I normalize the backup infrastructure after this type of situation?

Best answer by regnor

You should be able to reconnect an existing hardened repository with single-use credentials to a new/different installation. I don’t see a reason why it shouldn’t work with single-use, but work with the regular linux account.

Is there anything special about the user, like is it “root” or did you remove it from the sudo group?

Could you post an error message or screenshot from what you’re seeing with the single-use credentials?

View original

6 comments

regnor
Forum|alt.badge.img+14
  • Veeam MVP
  • 1354 comments
  • Answer
  • July 21, 2022

You should be able to reconnect an existing hardened repository with single-use credentials to a new/different installation. I don’t see a reason why it shouldn’t work with single-use, but work with the regular linux account.

Is there anything special about the user, like is it “root” or did you remove it from the sudo group?

Could you post an error message or screenshot from what you’re seeing with the single-use credentials?


Forum|alt.badge.img
  • Author
  • Not a newbie anymore
  • 7 comments
  • July 21, 2022

The user is not in the sudo group.

When I try to use it as Single-use, I receive the following message:

If I enable the ‘Use “su” if “sudo” fails’ option, the message changes to:

 


JMeixner
Forum|alt.badge.img+17
  • On the path to Greatness
  • 2650 comments
  • July 21, 2022

Sorry for the basic question, but did you give the correct root password when activating the su option?

The single use credentials need the su option and the correct root password. It is no problem, because they are not saved.


Forum|alt.badge.img
  • Author
  • Not a newbie anymore
  • 7 comments
  • July 21, 2022
JMeixner wrote:

Sorry for the basic question, but did you give the correct root password when activating the su option?

The single use credentials need the su option and the correct root password. It is no problem, because they are not saved.

I did check the password and it should be correct.

 

One thing that I did was re-add the user to the sudo group and it worked. Is this the right course of action?


regnor
Forum|alt.badge.img+14
  • Veeam MVP
  • 1354 comments
  • July 21, 2022

Normally when I setup a hardened repository I do it just like that; add the service user to the sudo group and remove it afterwards. When doing upgrades or such I temporarily add it back to this group as you need elevated permissions for the setup/updates.

Regarding your error; I was just able to reproduce this in my lab VM. I think the option tries to su root and Ubuntu doesn’t have a root user by default, therefore it fails. Could be a bug or maybe it’s a known issue; I’ll do some research in the evening.


Forum|alt.badge.img
  • Author
  • Not a newbie anymore
  • 7 comments
  • July 21, 2022

I logged in as root (sudo su) and changed the password for the root user.

After that the option to use “su” also worked.

 

I will stick to temporarily adding the user to the sudo group, though.

Thank you guys!


Comment