slcain
asked on
Can I Delete Old Exchange Log Files?
Let me begin by saying that I recently (within the past week) took over Exchange admininstration when our admin left. Of course, something had to go wrong. One of our log drives is filling up and is almost out of drive space. We have an Exchange 2003 Server with 3 storage groups. The information store gets backed up every night. The logs for 2 of the storage groups are being automatically removed after each backup, however, there are log files for the third storage group that are over a month old. I read several articles that said you have to be careful about deleting the log files because they may not have been commited to the database yet but wouldn't it be safe to delete the log files that are at least a week old?
swaller
The easiest safe way to get rid of the logs is do a NTBackup on that store. That will force commit the logs and safely purge.
What is being used to back them up? Do you have individual jobs for each of the stores?
My thoughts exactly swaller.
ASKER
We are using Symantec NetBackup. There is only one job for all three stores.
ASKER
I know that it would be best to run a backup, but isn't it safe to assume that a log that is over a week old is already committed?
A successful backup should remove those log entries. Are there any errors in the logs when you do the backup? It may be backing up the first two stores, but unable to backup the third.
ASKER
I will ask the backup admin to check the logs for any errors. In the meantime, is it safe to assume that a log that is over a week old is already committed?
Those log files are used for incremental backups. They may have been applied, but you should definately wait to hear from your backup admin first if you dont know your backup schedules.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You could also enable *circular logging* and let them purge themselves. There is pros and cons to circular logging but I will let you make that choice on your own. ...but, it would purge your files down to the last 4.
>>is it safe to assume that a log that is over a week old is already committed?
No, the fact that they are there means it is safe to assume they are not committed.
And enabling circular logging is a terrible idea on a server hosting mailboxes - there are no pros, and the only time it is useful is on a front end server, or if you are moving mailboxes.
No, the fact that they are there means it is safe to assume they are not committed.
And enabling circular logging is a terrible idea on a server hosting mailboxes - there are no pros, and the only time it is useful is on a front end server, or if you are moving mailboxes.
"and the only time it is useful is on a front end server, or if you are moving mailboxes."
...and when you are running out of space and don't want to follow the directions for manual delete or run an appropriate backup to commit and purge the logs.
As I stated: "...but, it would purge your files down to the last 4."
I also would recommend that if you are going to infatically state that it is a terrible idea then I believe you should state why you think that.
PS. I am not saying I completely disagree with you. I *am* saying that compared to just deleting all the log files over 1 week old that it's a better option than that.
...and when you are running out of space and don't want to follow the directions for manual delete or run an appropriate backup to commit and purge the logs.
As I stated: "...but, it would purge your files down to the last 4."
I also would recommend that if you are going to infatically state that it is a terrible idea then I believe you should state why you think that.
PS. I am not saying I completely disagree with you. I *am* saying that compared to just deleting all the log files over 1 week old that it's a better option than that.
You are right, I should have specified why it is terrible. You reduce your restoration capabilities drastically, when there are exponentially better solutions, if you are running out of space, compress the logs - it buys you time to do a backup.
I agree with that.
Now I have a questions for clarity sake. If you have circular logging enabled on a store that gets nightly full backups. Are you at any greater risk?
Thanks.
Now I have a questions for clarity sake. If you have circular logging enabled on a store that gets nightly full backups. Are you at any greater risk?
Thanks.
ASKER
Thanks....running the NT backup did the job for the most part. It gave me a warning in the event viewer which told me why the logs could not be purged (because the previous admin had 2 unused mailbox stores that were dismounted) and obviously that keeps the logs from being able to be purged. I mounted the stores, ran a backup again and the logs were deleted.
It depends what you define as risk - I do nightly full backups everywhere as a rule, but the added bonus of transaction logs mean that I can restore to the point of failure, meaning that data is accurate and not a day behind.
Most IT managers aren't expecting that - so it becomes a bonus, minimizing risk.
That said, technically speaking, yes you are at more risk with circular logging no matter what you do.
Most IT managers aren't expecting that - so it becomes a bonus, minimizing risk.
That said, technically speaking, yes you are at more risk with circular logging no matter what you do.
Depends on the kind of backup. Also if a database corrupts doesnt this thwart soft recovery as far as saving information goes?
I was wondering why the backups arent running in the first place. NTBackup or any backup solution that uses the ese api will not run on a corrupt db.
I was wondering why the backups arent running in the first place. NTBackup or any backup solution that uses the ese api will not run on a corrupt db.
>>Also if a database corrupts doesnt this thwart soft recovery as far as saving information goes?
Yes, but restoring from tape and then doing a soft recovery will work.
>>I was wondering why the backups arent running in the first place.
They are running, but his backup isn't running properly - it is not doing a proper backup
Yes, but restoring from tape and then doing a soft recovery will work.
>>I was wondering why the backups arent running in the first place.
They are running, but his backup isn't running properly - it is not doing a proper backup