Solved

Exchange 2007: LOGS vs Storage Group

Posted on 2010-08-25
8
622 Views
Last Modified: 2013-12-01
Hi,

1) This is related to Exchange 2007 in the Cluster Environment
-OS: Windows 2003 server
-Node1: EXCH07_1
-Node2: EXCH07_2
2) There is Volume called "LOGS" or R: drive
3) There are 6 storage groups: Storage group 1 up to 6
4) Per Consultant:
- The volume "LOGS" or R: drive should be more than 75 GB
- If The volume "LOGS" or R: drive is equal to 0 (zero); the Exchange server will fail
-If the Volume "LOGS" or R: drive is LESS than 75 GB; we have to "Run backup NOW" to the largest Storage group; say it if the Storage group 6 is the largest (at that time; when R: drive is LESS than 75 GB), we have to "right-click" the Storage group 6 and select "Run Backup Now"
5) My questions: i) What is the "LOGS" or R:drive?, ii)Why (as per consultant) if the R: drive is " 0 (zero value) ", the Exchange will fail?, iii)Why when we "backup the largest storage group" Now the R: Drive will become Bigger?
6) Thank you

tjie
0
Comment
Question by:tjie
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
8 Comments
 
LVL 8

Assisted Solution

by:bpinning
bpinning earned 60 total points
ID: 33527250
It could be the exchange log files, they are cleaned up automatically when a backup is run?
0
 
LVL 32

Assisted Solution

by:endital1097
endital1097 earned 165 total points
ID: 33527292
it sounds like all of your storage groups are configured to use the same drive for the LogFolderPath
i would run the following to verify where EXSRV is the Exchange virtual server name
Get-StorageGroup -Server EXSRV | fl Name,LogFolderPath

- If The volume "LOGS" or R: drive is equal to 0 (zero); the Exchange server will fail
If the free space on R: drive is 0, yes the databases will dismount

-If the Volume "LOGS" or R: drive is LESS than 75 GB; we have to "Run backup NOW" to the largest Storage group
The only way to determine which storage group to backup (to clear the most log files) is to determine the number of log files for each storage group
0
 
LVL 58

Accepted Solution

by:
tigermatt earned 150 total points
ID: 33527528

Exchange's database (the EDB files on disk) work together with what are known as transaction logs. It sounds to me as though these logs are stored on your R: drive. Every modification in and out of the database is written to a transaction log file first; at a later time, it is lazily written into the database file. Logs are cleared from disk only when an online Exchange-aware (very important) backup is made - an image of the server would not clear the logs, for example.

The intention is to have the database files and logs on totally separate RAID arrays. If you lose the array holding the databases, you can restore from backup and then replay the existing log files into the database. In this way you recover to within moments of the disaster. Logs are not a replacement to a backup, but a tool used in some disaster recovery scenarios - if the whole cluster blew up, you'd lose your logs and only have data back to the last backup anyway. In a properly designed system, the logging architecture can also offer some performance benefits, since logs are generally stored in faster spindles than databases and changes need not be written by the Store to the database immediately.

As noted above, filling your logging drive would cause databases to dismount. If nothing is available to log database changes to, Exchange is unable to operate as designed and dismounts databases as a result. The 75GB threshold mentioned is not a hard-and-fast requirement. However; you should be running regular Exchange-aware backups of your servers with a proper tool (Windows Server Backup, Backup Exec with Exchange agent, System Center Data Protection Manager etc.). The free space you require ultimately depends on how heavy the traffic is, the data in and out per day, how frequent the backups run to clear the logs, how long the backups take to run and so on.

There's a lot more available online if you need to read more: http://www.msexchange.org/articles/Transaction-Logs-Lifeblood-Exchange.html.

-Matt
0
Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

 
LVL 1

Assisted Solution

by:LN41
LN41 earned 125 total points
ID: 33528464
Sounds like he's emphasizing that you don't run out of log file drive space:

* Measure the log file usage per day - watch how much the log file grows each day and make sure your log file drive is large enough to handle at least 7 days worth of logs.

* Monitor your backups daily to make sure they ran OK. A full backup should truncate the logs when complete. There are other methods but this is simplest and most common.

* Monitor all of your hard drives with monitoring software to make sure that the database nor log files ever use more than 80% (or whatever you're comfortable with). Setup alerts so that you get notified if/when free space gets low.

The consultant is telling you to backup the largest storage group so that when the backup completes, the log files will be cleared but it's a last minute strategy. Best practice is to stay away from the scenario altogther.
0
 

Author Comment

by:tjie
ID: 33532458
LN41 & other experts:
- I want to clarify and ask the questions related to the answer from LN41

""" * Measure the log file usage per day - watch how much the log file grows each day and make sure your log file drive is large enough to handle at least 7 days worth of logs."""
- This is my understanding ....
- Say it Today, i note the R: drive is 120 GB; tomorrow: 115 GB; the day after tomorrow is 112 GB ........so everyday it grows around 4 GB; for 7 days: around 28 GB (say it 30 GB) ......; so the worst comes to the worst, it will be around 90 GB after 7 days (so it is OK; it is bigger than 50 GB); is the understanding correct?


""" * Monitor your backups daily to make sure they ran OK. A full backup should truncate the logs when complete. There are other methods but this is simplest and most common. """
-We do the Full backup every week (we are using the backup exec) ...
-Your statement: "A full backup should truncate the logs when complete"; i do not understand here; Per my understanding: "the full backup" should be the same with the "partial backup" (incremental or differential); isnt it?; the "truncate" is similar to "defragmentation" right?; why the full backup will clear "the white spots of the databases"?


Thanks
0
 
LVL 32

Assisted Solution

by:endital1097
endital1097 earned 165 total points
ID: 33532500
yes, 7 days only using ~30GB on a 120GB drive you should be safe for a failed backup

only a full and incremental backup will purge committed logs
full backups are quicker to restore because the minimize the number of logs you must replay
0
 
LVL 58

Expert Comment

by:tigermatt
ID: 33538282

It's not quite the same as defragmentation.

Defragmentation concerns the physical database files. Online defrag, which runs on a daily basis by default, identifies database pages no longer in use and recovers them for future use. Those database pages are marked as white space and overwritten later. Offline defrag shrinks the database by copying to a new database file but leaving the whitespace pages behind.

Online defrag will normally look after itself, and in Exchange 2007 up, there is never a reason to do an offline defrag.

Transaction logs are separate files - they maintain a log stream of EVERYTHING which goes in and out of the databases. Change anything and it hits the logs. If you lose the RAID array holding your database files, you can restore from the last backup and "replay" the log files into the database, bringing you right back to the point when it stopped. When the backup is run, it removes the transaction log stream because it is not needed any more - the changes which the logs are tracking have now been backed up. As I mentioned before, this architecture provides some prospect of disaster recovery.

Consider for a moment the following:

* You run a backup once a week on a Sunday night. The backup is properly purging unrequired log files.

* One week, on a Saturday, the array holding your databases fails. You've now lost the EDB file containing all the email in that database.

* Using the logs, you restore last Sunday's backup. You are now 6 days out of date. However, with the transaction logging array available, you replay the logs into the recovered database. The logs have tracked ALL changes to the database since the last backup and you recover yourself to the point of RAID array disaster.

In your scenario, you have a cluster, so emphasis on this mode of disaster recovery is not so important as a failover event will occur. Nevertheless, you should still focus on logs and follow best practices with regard to them.

-Matt
0
 
LVL 58

Expert Comment

by:tigermatt
ID: 33538291

I didn't notice you closed this while I was typing. Thanks for the points!
0

Featured Post

On Demand Webinar: Networking for the Cloud Era

Ready to improve network connectivity? Watch this webinar to learn how SD-WANs and a one-click instant connect tool can boost provisions, deployment, and management of your cloud connection.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this article we will learn how to backup a VMware farm using Nakivo Backup & Replication. In this tutorial we will install the software on a Windows 2012 R2 Server.
Check out this step-by-step guide for using the newly updated Experts Exchange mobile app—released on May 30.
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an antispam), the admini…

617 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