Skip to main content

Hello -

To start with a short breakdown of our environment:

We have three separate Veeam “instances” across our org. It works like this:

 

Branch A

VMWare instance with 8-10 servers both Windows and Linux

Windows server running Veeam B&R

Windows server serving as proxy

Windows server serving as repository

Repo contains backups of the machines here 

 

Branch B

VMWare instance with 15-20 servers both Windows and Linux

Windows server running Veeam B&R

(3) Linux server serving as proxy

(1) Linux server serving as repository

Repo contains backups of the machines here

 

Branch C

VMWare instance with 4-6 servers both Windows and Linux

Windows server running Veeam B&R

Windows server serving as proxy for Branch A

Linux server serving as proxy for Branch B

Windows server serving as repository

Repo contains backup copies and replicas of VMs from Branch A and B

 

 

On to the problem. Our third-party vulnerability scan started to flag all our proxies and repositories and Branch A and B as needing Linux OS updates.

 

I asked Veeam support what the proper process was, and they just said "we don't help with that."

 

I took the chance and just ran the Linux updates as I have done a couple times before, sudo apt-get update and so on.

 

Now, our jobs are all failing. The repo at Branch B is no longer recognized by Veeam and rescanning fails.

 

If I access that repo itself, it says that it is in emergency mode and shows this:

 

"Failed to start default target: Transaction for graphical.target/start is destructive (emergency.target has 'start' job queued, but 'stop' is included in transaction)."

 

What is really strange to me is that I took a snapshot of the fully working VM before I did anything. I reverted to that snapshot, and after rebooting it does the same thing, with the same error message as above.

 

What did I do? I would swear on my mother that after I upgraded the repo and restarted it that it came back up successfully WITHOUT any errors. Then after the weekend, this is the behavior.

 

I know very very little about Linux, and we contracted the build out of the environment to a third-party. I was involved in the buildout, but I was mostly along for the ride while their Veeam expert ran the show.

 

I can provide more info if needed. Any help would be magical.

 

Thank you.

The copy jobs are in pruning mode.

I did a re-rescan of both the vCenter where the secondary repo is, along with the repo itself.

Jobs are running now, just waiting for them to fully complete.

I need a drink. Cheers to all of you, I’d buy you one if I could.

No problem ​@gmattbrown . We like to help if/when we can. We have generally experienced some of the same issues over the years. 😊


Comment