cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange Server 2008 Transaction Logs

BloodBaz
Level 3
Hello,

When my BESR performs backups of our system and data drives, the Exchange Server transaction logs are not pruned.

I have carefully followed the two items explained in the following article:

http://seer.entsupport.symantec.com/docs/297799.htm

both of which are present and correct on our server, yet the pruning does not take place.

What else cause be the problem?
(I currently have 14354 Trans Logs dating back to August 2008 consuming 38Gb and could do with them being pruned cleanly)

I am using Windows Server 2008 and Exchange Server 2008 with SP1

Thanks,
Chris
1 ACCEPTED SOLUTION

Accepted Solutions

BloodBaz
Level 3
Hi Chris (Riley),

Thanks for your support.  We have found out the cause of my Exchange Transaction Logs not pruning:

Exchange Transaction Logs only get pruned if both the Transaction Logs AND the Storage Group databases are backed up under a SINGLE BACKUP JOB.

My backup strategy was:

System Backup: One Backup Job running a full backup of C: (System Drive) once a week.

Data Backup: One Backup Job running a backup of D: (Data Drive) daily - Weekly Scheduled Base followed by Daily Incrementals.

It so happened that following advise to hold Logs and Database on separate volumes, my Transaction Logs were located on the C: drive and got backed up via the first Job and my Storage Group databases were located on the D: drive and got backed up daily.  As both objects were not backed up under a single job, the logs were not pruned.

Thanks again for your help in this matter.  Hopefully this discussion will help others out.  I think it would be good also to make the explicit point about "both TLogs and Storage Groups under a single job" in the knowledge base.

Kind Regards,

Chris.

 

View solution in original post

15 REPLIES 15

criley
Moderator
Moderator
Employee Accredited
What version of Exchange are you using? There is no Exchange 2008...

Also, what version/build of BESR do you have?

Are there any VSS errors in the event logs when you run a backup?

BloodBaz
Level 3
Sorry for the mistake in version:
I am using:
  • Exchange Server 2007 with SP1
  • BESR 8.0 (8.0.1.24976)
I cannot find any VSS errors in Event Viewer.  It is as if, BESR doesn't notify Exchange First Storage Group that a backup has been performed and verified.

criley
Moderator
Moderator
Employee Accredited
I would recommend that you update BESR to 8.0.5 by running LiveUpdate (reboot required) to see if this helps.

BloodBaz
Level 3
Thanks for your ongoing help.
Running Live Update states that it is already up-to-date after a few seconds of checking.  Live Update report is as follows:
===START===
The following Symantec products and components are installed on your computer.
> LiveUpdate

Initializing...
Connecting to liveupdate.symantecliveupdate.com...

Downloading catalog file (1 of 1), product up-to-date.
All of the Symantec products installed on your computer are currently up-to-date. Remember to check for new updates frequently.

LiveUpdate session is complete.
===END===
Live Update Version is v3.2.0.68.  
Would you recommend I try to download 8.0.5 manually from Symantec?

criley
Moderator
Moderator
Employee Accredited
Yes, looks like you'll have to do a manual download/install then.

BloodBaz
Level 3
You suggested downloading BESR to 8.0.5.

Going to http://www.symantec.com/business/support/downloads.jsp?pid=53845 lists the following latest versions (with Windows Server 2008 selected):
  • 8.5
  • 8.5 .1 SP1
  • 8.5 .3 SP2
  • 8.5 .3 SP3
Am I right in thinking this is the version I should download and install? (8.5 followed by 8.5 .3 SP3).
I will download these now on the assumption that it is.
Thanks.

EDIT: The link I mentioned above is not to download the product but to download patches.  Do you know where I can get hold of the latest version and whether my product key for 8.0 will actually work for 8.5?  Thanks.

criley
Moderator
Moderator
Employee Accredited
No, that's not the right version - your license key will not work with 8.5.

I have uploaded the 8.0.5 service pack here:

ftp://iosupport:iS*pp8rT1@ftp.entsupport.symantec.com/pub/support/outgoing/besr805/Symantec_Backup_Exec_System_Recovery_8.0_SP5_Patch.exe

BloodBaz
Level 3
Thanks Chris.
Downloaded the patch.  I need to dig out the BESR 8.0 CD in order to complete the installation.  Will get back to you.

BloodBaz
Level 3
Hello Chris.

Yesterday, I ran the patch that you have kindly supplied above and rebooted.
BESR 8.0 version is now 8.0.5.34563.
LiveUpdate Express shows no new updates (it didn't before however!).
The scheduled backup ran last night as usual.

My Exchange Server Transaction Logs however have still not purged, i.e.:
"C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group" still contains 14687 files comsuming 14.3GB, the latest 19 "E000000xxxx.log" files have today's date on it (i.e. they are live)

Rechecking the usual suspects:

1) "vssadmin list writers" still shows
Writer name: 'Microsoft Exchange Writer'
   Writer Id: {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
   Writer Instance Id: {d80f6ab2-5441-4181-b6f1-9a4b480c7f6d}
   State: [1] Stable
   Last error: No error

2) Manage Backups still shows:
Drive Backup of system (C:) -> Edit Settings -> Options Step -> Advanced Button -> Perform full VSS backup = Checked

I am now using the latest BESR 8.  
Any other ideas?

BloodBaz
Level 3
Hello,

Sorry to bump this problem but I was getting good suggestions from Chris Riley but none have identified the problem yet and 3 weeks have passed.

My Transaction Logs are still growing and it won't be long before the problem becomes more serious (regarding disk space)

Thanks,

Chirs

criley
Moderator
Moderator
Employee Accredited
I think you are going to need to open a case with Tech Support on this one.

BloodBaz
Level 3
Hello Chris (Riley) et. al.,

Contacted Symantec Tech Support who weren't very helpful.  Eventually cottoned on to the fact that I needed to contact Dell who I purchased BESR 8.0 from.  We have Gold Support with them at the moment so was able to get hold of some experts.

Atif at Dell is an expert in this area.  He looked at our server via WebEx (desktop sharing thing).  He could see in Exchange that backups had not been performed (under Properties on the Storage Groups).  He had a good look around BESR 8 but eventually came to the conclusion that BESR 8 doesn't have the means to perform a specific backup of Exchange Server (or SQL Server or anything else) and it would be this that would be required to convince Exchange Server that a backup has been performed and verified.  He also thinks that you COULD do this BESR 7.

Can anyone confirm this to be the case?

His initial suggestion to me was to download a trial version of Symantec Backup Exec 12.5 and perform a one-off backup of Exchange Server storage groups.  This will inform Exchange that a backup of the Storage Groups has in fact been performed and initiate the pruning process (releasing those 15,000 transaction files).  I can then uninstall Symantec Backup Exec 12.5. 

This would be a (most likely one off) workaround to prune my logs.  

I do feel a disappointed that we spent a lot of money on a server level backup utitlity (BESR 8.0) only to find that it has this flaw in it, even if backups of Exchanage are in principle safely backed up via the Volume Shadow Copy Service.  There is no way I could have predicted this flaw when choosing my backup software last year.  As we are only a three man small business, the various costs to buy and run a single server network are heavy going.

Back at Dell Atif is going to read up on some documentation about any better solutions.

Chris.

criley
Moderator
Moderator
Employee Accredited
Thanks for the update.

This should be working with BESR - that's what the 'perform full VSS' option is for. More info here:

http://support.veritas.com/docs/297799
http://support.veritas.com/docs/313732

It's clearly not working so this needs to be looked into in more detail by Symantec support. If necessary, we can work with Microsoft to determine what might be causing this.

Running a test with Backup Exec 12.5 might be a good idea - if this does truncate the logs, it would then point the finger at BESR that is not doing what it should be. If 12.5 does not work, then this is likely to be a Microsoft issue.

Hope that helps.

Chris

BloodBaz
Level 3
Thanks for your reply.

OK.  So BESR 8 SHOULD manage pruning of Exchange Server logs (even though it backs up at the disk level and you don't explicitly set anything in BESR about how to manage which storage groups and its logs).

I am waiting to hear back from Dell's research before instlaling the trialware but yes if I end up doing that it should help point the finger towards the Backup Tool or Exchange.

Just to recap, your first link refers to enabling the VSS option in BESR which I have done and check many times.  The opening paragraph however does allude to the fact that BESR can be used to manage log pruning.

Thanks.


BloodBaz
Level 3
Hi Chris (Riley),

Thanks for your support.  We have found out the cause of my Exchange Transaction Logs not pruning:

Exchange Transaction Logs only get pruned if both the Transaction Logs AND the Storage Group databases are backed up under a SINGLE BACKUP JOB.

My backup strategy was:

System Backup: One Backup Job running a full backup of C: (System Drive) once a week.

Data Backup: One Backup Job running a backup of D: (Data Drive) daily - Weekly Scheduled Base followed by Daily Incrementals.

It so happened that following advise to hold Logs and Database on separate volumes, my Transaction Logs were located on the C: drive and got backed up via the first Job and my Storage Group databases were located on the D: drive and got backed up daily.  As both objects were not backed up under a single job, the logs were not pruned.

Thanks again for your help in this matter.  Hopefully this discussion will help others out.  I think it would be good also to make the explicit point about "both TLogs and Storage Groups under a single job" in the knowledge base.

Kind Regards,

Chris.