Hello I need some advice on what to do.

I have a two-member Exchange 2010 DAG.  One is an active server where everything is mounted.  The other is simply the passive server.  I will need to power down the passive server in a few days for some extended maintenance.  Roughly several hours.  I know for a fact (because I've been through this before) replication will be cut off during this time and as a result I cannot run a full Exchange backup to flush all the transactions logs and secondly, the copy queues will be very backed up.  Last time they were so backed up all efforts to reseed the passive copy of the mailbox databases failed.  In the end I think I had to delete and copy the active server's databases over.  That took a really really long time.

So to avoid all that headache what should I do for this upcoming maintenance to make life easier?  

- Is there a way I can literally STOP replication or even delete the passive copies of the mailbox databases just so I can run full backups and truncate transaction logs?  

- Otherwise, assuming I have backed up copy queues, should I simply try reseeding or resuming synchronization?  Or should I not even waste time and delete all the passive copies and their files and start fresh with NEW copies?

There's no reason that a huge backup of logs would cause databases to fail.  I've never seen that unless disk space is exhausted or something like that.  If you're having a problem you describe and it's reproducible, I'd open a support ticket with Microsoft because it's not normal.

I don't know why you can't take a backup of the active database copies, but it won't truncate the logs because of the logs still need to replicate to the passive copy.

You can certainly delete the passive copies but you'd just have to recreate them afterward.  That defeats the purpose of having a DAG.

Hi Ed,

Actually what I mean to say was that the huge copy queue kept failing every time I tried to resume copying or synchronizing.  Not that the databases on the passive server would fail.  They'd mount fine.  It's just the log copying from the active to the passive server failed.  Sorry if I wasn't clear on it.

I can definitely take a backup of the active database but without the logs flushing, the directory holding the transaction logs would slowly fill up over time.  

I'm afraid I may have to delete the passive copy if the copy queue fails to decrease.  I know this goes against what a DAG is for.  

Is it possible then to copy the active database and then paste it over in the passive server?  Would I need to dismount the active database first before I can copy it to, let's say a locally attached USB drive?

• Edited by khunkao Tuesday, April 28, 2015 9:37 PM

You might want to find out why the failure mode you're describing is happening because it shouldn't.  I haven't seen that failure mode.

Hi Ed:

I never did find out why.  It's not like the copying failed immediately.  It's more like after running the command and waiting for some time, it stopped and went right back to "Failed and Suspended".  

That may not have anything to do with the number of log files.  That usually means that there's a missing log file or some other problem.  You can fix that with a reseed afterward, and that's really no more work than assuming it'll fail and removing the copies ahead of time.

What procedure are you using to place your server into maintenance? Are both servers in the same AD site? For short maintenance I use the Start-Databasemaintenance script, for longer outages or outages that affect iSCSI I do a datacentre switchover. With either of the options there is no attempt to replicate and once everything is back to normal queues are pretty high (we are over 3000+ active accounts) but never cause the DBs to go into a failed state. What happens to your quorum during maintenance? I've miscalculated before and accidentally broke quorum which wouldn't allow any of my dbs to mount. Here is a good explanation on what you need based on the number of servers you have in your deployment: https://blog.credera.com/technology-insights/microsoft-solutions/when-do-dags-need-a-file-share-witness/

Using that script is good advice.