Force Exchange 2010 to consolidate transaction logs without Windows Server Backup

There's no "typical log size" for exchange as this is dependant on activity, not the product itself.

There's an interesting discussion on the microsoft support site here which might be relevant (extract follows).

i had the same issue, and it turned out to be 2 users with android phones in a sync loop on contacts. I basically ran reports showing the top 10 mailboxes by item count (as opposed to size), and was able to narrow it down to the 2 problem users that way (their item count was incrementing very quickly compared to everyone elses. Running the report every 3 minutes let me find the trend

The poster suggested running the following powershell script as their "report"

Get-Mailbox -database databasethatkeepsgrowing | Get-MailboxStatistics | Sort-Object ItemCount -descending |Select-Object DisplayName,ItemCount,@{name="MailboxSize";exp={$_.totalitemsize}} -first 10 | Convertto-Html | out-File c:\temp\report.htm

I reckon you could see this issue from any device that might have problems, including outlook itself if a user or two have messed up OST files or badly behaved plugins - keep in mind that transaction logs aren't just a list of mail but a list of, well, transactions which includes mail but can also include anything that changes the properties of an object in your message store, which can be any number of things. I'd suggest that the high CPU you've noticed could be very relevant, and worth checking out at least.

In addition to that lot, I'd be checking for things like spam relaying and the like, but I'm sure you're all over that.

The backup process is no different, the only thing that's different is recovery, and then only if a particular failure scenario occurs.

The whole idea behind transaction logs being on different physical disks is that if the disks your databases are stored on fail so catastrophically all data is rendered useless, you can still recover to the point of failure with a combination of your most recent backup and the transaction logs. This works because before Exchange does anything to the database, it writes it to the transaction logs. If the disks fail which render your databases unusable, you would restore from backup and then "replay" the transaction logs, which would contain the data between the backup and the failure.

If your separate partitions are actually the same set of physical disks and they all die, you don't have the benefit of recovery to the point of failure, but rather you have recovery to the point of your last backup. That's an important distinction, and you should do what's required for your business.

Microsoft recommend you have 3 separate sets of physical disks for your operating system, Exchange databases and transaction logs. That's not to say any other combination isn't supported, and it's certainly fine to have everything all on your C: drive if you are constrained for example by number of physical disks that fit in your server.

Regarding your comment saying one big system partition including everything, I assume you are talking about doing a full filesystem backup of the server. If you do that, be sure to exclude the Exchange databases and transaction logs from your filesystem backup and do separate Exchange backups using supported software which backs Exchange up in a logically consistent manner. If you just back up the whole filesystem, you will get an inconsistent backup of Exchange and chances are nigh on certain your databases won't mount if you restored the Exchange database and transaction logs from a filesystem backup.