cancel
Showing results for 
Search instead for 
Did you mean: 

Is BackupExec committing transactions to DB if log files are not deleted

jeff_Podjasek
Level 2
I am working a new network running SBS2003-Standard with Exchange. I am backing up Exchange with BackupExec v10 to an Iomega 35/90 storage drive. Everything appeared to be working well. The backups list as 100% successful - no errors and complete in good time. But here is the rub :

Drive space on that server was being eaten up at a fantastic rate. Well... much, much quicker that I could account for. Then I discovered that the transaction-logs (edb000XXX.log) from Exchange were not being deleted when the backups were complete. This is a problem, but not just of space.

I am running the exact configuration (Server2003 or SBS2003 w/ Exchange with the Iomega 35/90) on 4 other networks and have not run into this problem. The difference is that those other networks are running BackupExec v9 - not v10.

I have "circular loging" turned off, so the Transaciton logs build up (5MB each) until a backup is run. Then they should automaticly delete. This is from the VERITAS site:


"How does Backup Exec use circular logging

Backup Exec will back up and then delete the committed (post-checkpoint) log files during a full backup job. This manages the log file and provides the protection that is required against hard, soft, and media failures of the exchange server. Performing a full backup of the Microsoft Exchange Server is the preferred way of saving the log files and removing these logs from the disk to utilize the space effectively."


On 4 networks this is working perfectly. In every case with BackupExec v9, once the log files (transactions) are successfully committed to the data base they are deleted. But on that t one server running v10 they are not. So are they committed???

In light of this anomaly I fear that the transactions are not being committed and that is why the logs are not being deleted. This is a huge problem. I cannot keep saving the logs for ever (due to storage space issues) and I have no idea if the process is giving me good backups.

Has anyone had this problem with BackupExec v10?

I have checked and v9 and v10 are compatible with the Iomega 35/90 drive. That shouldn't be an issue.

Is there another setting or config that I am missing in v10? I really need to know if these backups are good and I need to know yesterday.

Anyone...?Message was edited by:
jeff Podjasek
4 REPLIES 4

Ajit_Kulkarni
Level 6
Hello,


You can refer to the below mentioned technote:

After a backup of an Exchange 2000 Information Store, the transaction logs are not flushed, even if the backup method was set to "FULL (flush committed logs)" or "INCREMENTAL (flush committed logs)".
http://support.veritas.com/docs/252680


Hope it helps you.

Regards

NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

jeff_Podjasek
Level 2
Ye, thanks. I read tht link before I posted. The backup are set for the entire info store, so I don't think that is it.

I am going to run NTBackup on the Exchange and see if that helps, as per: http://support.veritas.com/docs/235367

I'll post one way or another.

Thanks

shweta_rege
Level 6
Hello,

- We will wait for your further update


******************************************************************
*****************************************************************

Note : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to ‘answered questions’ pool.


Thanks.

jeff_Podjasek
Level 2
I ran the NTBackup and that has reset the log files from whatever was keping them bound up. The next night a full backup with BackupExec did commit the transaction logs to the jet database. The DB grew noticably in size while the logs were purged as per the setting in BackupExec.

Thank you everyone who followed this link.

The issue has been resolved by running a full NTBackup.