Comprehensive data protection for all workloads
Post Reply
JosvwHLT
Enthusiast
Posts: 47
Liked: 3 times
Joined: Dec 24, 2015 4:15 am
Full Name: Jos van Wordragen
Contact:

Preventing accidental server power on server replicas

Post by JosvwHLT »

Hello all, are there negatives or downsides in using "network mapping" and mapping the replicated server to a ESXi network with no physical NICs connected. I know it won't stop the server from booting. But it will prevent it from connecting to the network. Are there any other options? Thanks in advance for replying!
Mildur
Product Manager
Posts: 8755
Liked: 2304 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Preventing accidental server power on server replicas

Post by Mildur »

Hi Jos

What is your end goal with this replicas if they don't have a network uplink?
In my opinion, if I do a failover to the replica, I want them to be connected to the network.
I know it won't stop the server from booting.
Replicas doesn't just boot up on the second ESXI host. You have todo that manually in the VBR console with failover or starting them manually on the ESXI Host or vCenter itself (not recommended).

Thanks
Fabian
Product Management Analyst @ Veeam Software
JosvwHLT
Enthusiast
Posts: 47
Liked: 3 times
Joined: Dec 24, 2015 4:15 am
Full Name: Jos van Wordragen
Contact:

Re: Preventing accidental server power on server replicas

Post by JosvwHLT »

Hello Mildur, thanks for replying. Our goal is to have exact copies of the production network servers available at all times. They will be regularly updated through the replica jobs. But I don't want them have a connection to a network during the time these replicas are in waiting to be triggered to be online. These servers will need to be available during a catastrophic failure at the production site. In the meantime, and hopefully we never need them, they are awaiting the signal to brought online. To prevent accidental powering on these servers I want to separate them from the production network and have them preferably connected to a network with no physical connections. There are several ways of doing this, my thought was why not remap them to a network with no physical NICs and when needed change all the replicated servers and connected them to the production network.
You mentioned that the preferred way of starting the replicas is through the VBR Console, but in case of a failure on the production network we loose (in the worst case) also our Veeam Server, that would leave us with the only option of starting the replicas by means of vCenter or in our case directly from the ESXi host. Or would it be possible to backup and copy the Veeam Server config to the 2nd Veeam Server (@DSR), import the file there and start the replicas through the VBR console connected to the DSR Veeam Server?
Mildur
Product Manager
Posts: 8755
Liked: 2304 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Preventing accidental server power on server replicas

Post by Mildur »

Hello Jos

You're welcome.
But I don't want them have a connection to a network during the time these replicas are in waiting to be triggered to be online.
Understood. You can do that and it's supported by us. It just requires additional steps when you have to power on the replicas. If you are ok with it, then there is no disadvantage from our site.
and when needed change all the replicated servers and connected them to the production network.
I recommend to test the DR process. Failover to the replica, change the network adapter on the replica and then do a failback. I believe it will work, but it should be tested if you can. You can use a test VM, don't use the production VMs.
You mentioned that the preferred way of starting the replicas is through the VBR Console, but in case of a failure on the production network we loose (in the worst case) also our Veeam Server, that would leave us with the only option of starting the replicas by means of vCenter or in our case directly from the ESXi host.
The issue with starting the replicas manually, the backup server doesn't know about it. If you do want todo a failback, you can't. You have to delete the replica jobs and configure a new replica job to replicate the VMs from the second host back to the primary host.
And if the backup server comes online again while your people are working on the replica server, chances are great that Veeam will start the replication again and overwrites any changes done in the replica with the old state of the original VM.

Or would it be possible to backup and copy the Veeam Server config to the 2nd Veeam Server (@DSR), import the file there and start the replicas through the VBR console connected to the DSR Veeam Server?
Yes, you can import the configuration backup to a new VBR Server. The new server will then be able to failover the VMs.
Do you use Veeam Disaster Recovery Orchestrator?

Thanks
Fabian
Product Management Analyst @ Veeam Software
JosvwHLT
Enthusiast
Posts: 47
Liked: 3 times
Joined: Dec 24, 2015 4:15 am
Full Name: Jos van Wordragen
Contact:

Re: Preventing accidental server power on server replicas

Post by JosvwHLT »

Hello Mildur, thanks again for your very helpful reply. Points taken. I will carry out some tests to see if it works as planned. We know that there is some manual work involved to get the replicas online. We will add instructions to our documentation. The failback is a good point you mention. That only can occur when we still have the "old" Veeam Server alive. In case it is a complete failover because of complete loss of production that issue won't be the case. Manual work is also than involved to get the server back to a new server.
In answer to your question if we use Veeam Disaster Recovery Orchestrator the answer is "no". I think it is not part of our current license (Essentials licensing) schema.
rweis
Veeam Software
Posts: 462
Liked: 73 times
Joined: Jun 13, 2011 7:46 pm
Full Name: Randy Weis
Location: Raleigh, NC, USA
Contact:

Re: Preventing accidental server power on server replicas

Post by rweis »

My suggestion about the replication job control is to install a Veeam Backup & Replication Server at the DR Site. Use the same license you use in the Production VBR. Use Enterprise Manager to push the license to both server. You will not consume twice the licenses because you are replicating the same VMs that you are backing up and Veeam won't charge you twice for that. If production goes down, all the replication jobs and failover plans are still available because they are running at the DR site. Solves that problem.
Randy Weis
Enterprise SE, NA Strategic Accounts
dloseke
Service Provider
Posts: 60
Liked: 28 times
Joined: Jul 13, 2018 3:33 pm
Full Name: Derek M. Loseke
Contact:

Re: Preventing accidental server power on server replicas

Post by dloseke »

I too recommend running the VBR server from the DR site (make sure you still have Proxy's and repository servers as needed at the primary site), but then the event that productions goes down, your VBR site is still running at the recovery site. With your current config, you'll want to just make sure that the configuration database is encrypted and stored at the recovery site so that you could build a new VBR server at the recovery site and restore the configuration database, but that's going to take time to spin back up.

With that said, unless I'm missing something regarding the Enterprise Manager recommendation, I'm not seeing that as a necessary step. Unless running Enterprise Manager allows you to have a backup server at both sites and they are in sync in more of a HA configuration, but I'm not aware of that capability here. @rweis, is that what you're getting at?
Derek M. Loseke, Senior Systems Engineer | Veeam Legend 2022-2023 | VMSP/VMTSP | VCP6-DCV | VSP/VTSP | CCNA | https://technotesanddadjokes.com | @dloseke
veremin
Product Manager
Posts: 20285
Liked: 2258 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Preventing accidental server power on server replicas

Post by veremin » 1 person likes this post

Such capability does not exist. Randy recommended Enterprise Manager as a console allowing you to manage backup servers and DR actions conveniently. Thanks!
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Semrush [Bot], StrongOBackup and 40 guests