Unsolved
12 Posts
0
1686
NetWorker and Exchange IP-less DAG recommendation
Hi,
since a couple of years we've seen an increase in IP-less Exchange DAGs, since this is Microsoft recommended way to setup Exchange.
I'd like to ask the community for recommended ways to set backup with NetWorker.
The way described in the NMM Exchange guide is pretty straightforward:
Pick one node and let the wizard configure it. The wizard will configure the backup type as preferred (try to backup passive copies of the database and if not, do an active backup).
However we have an issue with this setup and therefore are not using it. The reason for this is quite simple: In case the node you picked with the method above is down, you have no backup at all. Manual intervention is needed to configure one of the other nodes and use it for backup instead.
We instead configure every single node and only backup the active databases on each node.
In case a node breaks down with 'our' method, the databases will become active on one of the other nodes and are backed up there. So we can always guarantee a backup, regardless of where the databases are active and regardless of which nodes are online or not.
But sometimes Exchange admins are setting nodes to offline. For example for patching purposes. In that case no active databases are running on that node and the backup for this single node fails.
It's not a lot of trouble to find this out, since the logs state quite clearly that there was no active database on that node and therefore there was nothing to backup. However the backup is still marked as failed for that node.
The other downside is of course that we're always backing up the active databases and not a passive copy, which may lead to a performance impact. So far we had no issues with that, but the risk is there.
Does anyone else have other ideas on how to backup IP-less DAGs?
Thanks!
JChan2020
18 Posts
0
August 12th, 2021 19:00
I don't have experience backing up IP-less DAGs.
When your Exchange admins are going to set nodes to offline, you can set a "skip" schedule for that node on NetWorker Policy action. So that backup task is skipped for that node on the day of maintenance, instead of marking a fail.
Real_Digioso
12 Posts
0
August 12th, 2021 23:00
That's true, but in 99% of the cases the Exchange admin doesn't tell you. You only notice this on the next day because the backup in the night failed.
barry_beckers
393 Posts
0
October 4th, 2021 05:00
Even if you'd regard an IP-less setup as the recommended way to setup Exchange, I'd rather call it the default way from Exchange 2016 onwards.
You know in the past Microsoft stated you wouldn't even require a backup at all, due to recovery options and high availability of Exchange itself. However in case of actually making backups when dealing with an IP-less setup, then the one Exchange node configuring the federated backups for, will become more important than other nodes in the cluster as it is the entry point for NW to communicate with the exchange DAG. So in that sense the it becomes the high-available entry point that the DAG with an IP is, meaning that Exchange admins should make sure that one node is as much available as possible.
By now using the old-fashioned setup, you still have to define all nodes in a DAG and have separate backups configured and running, instead of being able to use the simplified setup that the federated setup makes possible.
When a backup is supposed to be made of an Exchange environment it is a bit of either/or. If you don't regard high-availability required or that important , than a IP-less DAG will just do, taking for granted if the one node used to configure the backups through is unavailable, you'd have no backups at all.
If however it is important to have backups, then a DAG with an IP would be the way forward, making it completely transparent where the DAG is actively running on as NW will always connect through that. This makes - for backup - this DAG with an IP also the most important part of the DAG setup, so it should be made sure it is always available. So in that sense the same as for the node being used to connect in an IP-less DAG setup.
The possible downfalls come with the design.
A bit related, recently from nw19.2 onwards NMM now also supports a clusterless AlwaysON listeners.
However if you'd even would want to implement that is a very valid question (I advised against it) as it will require to have a node configured with the same IP address as the listener in DNS (so do not under any circumstance use nsr_client_fix). You'd have to create 2 separate client entries, one for the listener and one for the SQL node making sure the aliases are not assigned to each others client entry (as that might very well lead to a client index merge, causing havoc) as NW will find the other refrence in DNS as well and add that as alias. In case of fail-over to another node in the AAG, then a complete reconfiguration would be required if you needed backup...
So yes, even though things can be done, even when supported, they shouldn't be done at times as this would be such a peculiar odd-one-out configuration, which was bound to go wrong some day. At least that is what I told the customer.