Configuring the Recovery Storage Group
If you set the file paths for the recovery storage group database to the same logical drive as the original database, you gain the advantage of being able to instantaneously swap database files between storage groups. However, there are some disadvantages, as follows:
You must have sufficient disk space free on the database drive to hold the original and the dial tone databases.
Note
As a best practice, half of your database drive should be empty at all times. (If multiple database files are stored on a single drive, you should have at least a little more free space than the size of your largest database.) It may seem wasteful to keep so much disk space free, but there are significant benefits: First, you reduce the chance of running out of disk space from a sudden surge in user data. Second, if you decide to defragment the database, you can do it "in place" rather than generate the defragmented database remotely and rewrite it over the original database. This greatly reduces the time needed to defragment a large database. Third, in case of disaster, you can quickly move or rename the current failed database before a restore operation. Though you may intend to restore from backup rather than to repair a failed database, it is always a good idea to preserve the failed database in case restore from backup is unsuccessful or rolling forward from backup is incomplete. If the failed database is still in place when restore from backup begins, it will be immediately overwritten and destroyed. If you lack sufficient disk space on the same drive to hold an extra copy of the database, you will slow your restore process while you back up or copy the existing database.
There may be a noticeable performance degradation from restoring or repairing a database on the same drive that is servicing users. Typically, restoring and mounting a database in the recovery storage group has little effect on performance from an end user perspective, but this depends on hardware and configuration, and may not be true in your environment. If it becomes necessary to repair a database in the recovery storage group with the Exchange Server Database Utilities (Eseutil.exe) and the Information Store Integrity Checker (Isinteg.exe) tools, performance degradation may be noticeable. Before you count on being able to use the recovery storage group on the same drive and server, you should test and measure the impact of both restoration and repair operations.
You can even configure the recovery storage group on a different Exchange server in the same administrative group if you wish. However, if you do this, you lose the advantage of being able to quickly swap database files between storage groups because you will have to copy databases across the network.