01-31-2012 08:26 AM
in our exchange 2010 environment we load balance our databases on two different servers in the cluster. meaning we have an A and B server for the Dag and some DB are mounted on A and some are mounted on B but replicated between both (i hope that makes sense). When i run a backup of the dag it shows jobs for both servers and backups the databases. (active then passive copy). Fulls on saturday and incrementals sun-fri.
Once a month we do server refreshes to update our systems to current patches. I noticed this week that since the refresh all of the databases that are on my B server error out with status 13.
When we do the refresh we never take exchange down. We will move all databases to one server run patches/reboot then do the same when its back up to the other. Once they are both patched/rebooted we run a powershell script that randomly load balances the database between the servers.
Could the fact that my full backup ran on saturday, an incremental ran on sunday morning and then we did the refresh sunday afternoon be what is causing the backups for paticular databases to fail because they once were mounted on A when the full was taken and are now mounted on the B server?
Solved! Go to Solution.
01-31-2012 09:06 AM
As you are using a DAG backup type you effectively have all databases muti-streamed from a single policy.
The catch here is that the final status is down to the parent job, which will reflect the status of the failed job, so it reports a failure to Exchange and hence logs are not truncated
With Exchange 2003 / 2007 we keep Storage Groups in seperate policies to avoid this but with DAG you dont really have a choice
So in this case you need to fix your failing backups to get the logs to truncate for all databases
Hope this helps and hope my information is correct - sure someone else will comment if I am not accurate here.
01-31-2012 08:44 AM
I would be surprised if this were the case as I am sure it would have come to light and makes the whole DAG backup routine as the idea is that the backup should follow the database around
I know there can be issues with Incremental backups if the logs are not synchronised between the nodes
Check the state of the log replication and also check the bpbkar log for more information and post it on here if you have it.
Also check the Exchange servers event logs to see what is being logged around the time of the failure
01-31-2012 08:59 AM
Mark your probably getting tired of answering my questions. LOL!
As i was going down thru the logs like you suggested i noticed that it seems that only two of the databases actually are failing within one of parent jobs but heres what i dont understand that lead me to beleive that all of them are failing.
When I look in the netbackup activity screen i can see DB XXX was 100% successful but when i go into the exchange console and do properties on the same database it shows its last incremental was the morning of the refresh and the logs have not been truncated since the last incremental.
Does netbackup not notify exchange that the database is backed up once each stream has completed or does it wait until the entire parent job has finished before it lets exchange know.
01-31-2012 09:06 AM
As you are using a DAG backup type you effectively have all databases muti-streamed from a single policy.
The catch here is that the final status is down to the parent job, which will reflect the status of the failed job, so it reports a failure to Exchange and hence logs are not truncated
With Exchange 2003 / 2007 we keep Storage Groups in seperate policies to avoid this but with DAG you dont really have a choice
So in this case you need to fix your failing backups to get the logs to truncate for all databases
Hope this helps and hope my information is correct - sure someone else will comment if I am not accurate here.
01-31-2012 09:21 AM
As always you have helped me shed some light. One day maybe i will be posting solutions instead of always needing them. LOL!
01-31-2012 09:24 AM
Always happy to help - thats why we are here and do it!