Solved

Backup Exec 2010 and Exchange 2007: Database logs not flushed for one Storage Group

Posted on 2016-07-25
7
30 Views
Last Modified: 2016-08-01
There are two storage groups backup up by Backup Exec. They are set up as separate jobs.
Both have logged successful completions but on one of them, Exchange is not deleting the old logs.
On Exchange I checked:

1. With Powershell:
get-mailbox database -server 'server' -status | format-table name,storagegroup,lastfullbackup

Open in new window

This shows the last full backup time is 7/24/2016, same as reported by Backup Exec

2.  With cmd:
vssadmin list writers

Open in new window

This shows no errors with any of the writers. All are in State [1] Stable except for 'Microsoft Exchange Writer' and 'Shadow Copy Optimization Write' which are in State [5] Waiting for completion.
There is a backup for the problematic Storage group running now (after I made the changes listed below in the Backup Exec description), so I think this is normal. Please correct me if it is not.

3. Event Viewer shows ID 9827 logged after every successful backup.
Interestingly, I do not see it logged for the Storage Group in which the logs are being flushed.

Backup Exec Settings

I compared the settings set with the other job that is working properly. Everything looked proper except for the #2 and #3.

1. Full - Database & Logs (flush committed logs) - This was already set
2. Verify after backup completes: Yes changed from 'No'
3. Let Backup Exec automatically choose the best copy to back up (recommended) changed from 'Backup from Active Copy only'

I am running the backup job again after changing the "High Availability Settings" to the recommended value.
Is it possible that  backing up from the Active database and not verifying after completion is the cause of the logs not being flushed?
What other logs should I check to see if the problem lies elsewhere?
0
Comment
Question by:SeeDk
  • 4
  • 2
7 Comments
 
LVL 32

Expert Comment

by:Rodney Barnhardt
ID: 41728751
is the database where the logs are not flushing small, with very little change each day? If you look at the logs, do they eventually flush or commit older ones like 5-7 days back? If so, this is normal. I had a case opened with MS a few years ago. There is a minimum log size or change before they commit. He sent me a KB to explain it. I will see if I can locate it if that is the case.
0
 

Author Comment

by:SeeDk
ID: 41728985
They haven't flushed since April.
I looked into this  more and see it could be a problem with SCR.
When I check
get-storagecopystatus -standybymachine

Open in new window

on the Exchange server

I see the status for this Storage Group is Suspended and the CopyQueueLength is 1379183.
There is also an ESE event in Event Viewer:
Event ID 225 the log files cannot be truncated.

In ADSI Edit, if I look under CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<org name>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Servername>\CN=InformationStore\CN=<Storage Group Name>
 
Scroll down to the attribute msExchStandbyCopyMachines...the passive node is listed there.

The strange thing is the other Storage Group shows the CopyStatus as  NotConfigured but when I check the passive node, I can see its database is being copied there.
But when I check ADSI edit, the attribute msExchStandbyCopyMachines is empty for this Group as well.

Is this a bug with SCR or is this expected output? Would un-suspending this Storage Group resolve the problem?
0
 
LVL 29

Expert Comment

by:Sudeep Sharma
ID: 41729287
It seems like the bug with SBE 2010.

Did you tried creating a new job, new backup location for the Exchange and tried full backup with log truncation?

Sudeep
0
Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

 

Author Comment

by:SeeDk
ID: 41729385
Thanks Sudeep, I may try that next before changing anything on the Exchange side.
However, is this known to be a bug with the backup software...I thought log deletion was done on the Exchange side?
Does SCR being suspended mean Exchange will not delete the log files?

I thought this is how the deletion process works:

1. Backup software completes backup successfully.
2. Backup software tells Exchange the backup was successful.
3. Exchange then deletes log files.

Is this correct or am I misinformed?
These are the events logged when a backup is finished which seem to show Exchange is notified of a successful backup.

1. Event 9827 MS ExchangeIS
Exchange VSS Writer (instance 5e6786ec-f740-486c-bd25-02d17a0e5291:219) has successfully completed the full or incremental backup of replicated storage group 'First Storage Group'. The log files will be truncated after they have been replayed.

2.  Event 225 ESE
MSExchangeIS (2076) First Storage Group: No log files can be truncated.  

3.  Event 2006 ESE
Information Store (2076) Shadow copy instance 219 completed successfully.

3. Event 9616 MSExchangeIS
Exchange VSS Writer (instance 5e6786ec-f740-486c-bd25-02d17a0e5291:219) has processed the backup completion event successfully.

4. Event 9648 MSExchangeIS
Exchange VSS Writer (instance 5e6786ec-f740-486c-bd25-02d17a0e5291:219)  has processed the backup shutdown event successfully.
0
 
LVL 29

Expert Comment

by:Sudeep Sharma
ID: 41729449
If you would like you could use Windows Backup (VSS FUll) and you would notice that the log truncation has completed successfully.

Thanks,
Sudeep
0
 

Accepted Solution

by:
SeeDk earned 0 total points
ID: 41731119
Well, I decided to try the Exchange route first and thankfully it worked.
It was SCR related after all.
After both disabling SCR and removing the passive node server entry in msExchStandbyCopyMachines using ADSI edit as explained in this post; I ran a full backup again and the logs were flushed once the backup completed.

Event Viewer also logged an Event 9780 which matches what was being logged for the other Storage Group which has been working fine:

Exchange VSS Writer (instance 3d4e98d5-5485-471c-8ca7-150c763ad243:223) has successfully completed the full or incremental backup of storage group 'First Storage Group'.

The database engine has also successfully executed log file truncation procedures for this storage group. (Note that this may or may not have resulted in the actual truncation of log files, depending on whether any log files existed that were candidates for truncation.)
0
 

Author Closing Comment

by:SeeDk
ID: 41737184
Found solution outside of EE.
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Local Continuous Replication is a cost effective and quick way of backing up Exchange server data. The following article describes the steps required to configure Local Continuous Replication. Also, the article tells you how to restore from a backup…
Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
This video discusses moving either the default database or any database to a new volume.

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now