Eliminating Traditional Backups using native Exchange 2010 Functionality (Part 1)

If you would like to read the other parts of this article series please go to:






Most Exchange customers use a traditional disk or tape based backup solution to backup critical Exchange data. There are two main reasons why this is the case. First, because that’s the way they always did it. Secondly, because this is how all other Exchange customers backup Exchange data.


Back when enterprises upgraded or migrated to Exchange 2003 and in most cases consolidated their Exchange messaging infrastructure, they at the same time invested in expensive high-end SAN solution that were used to store Exchange and other application data. Actually, because Exchange data had become more and more critical over the years, large enterprises often invested in two high-end SANs in order to make sure the data was not only protected using RAID but also was mirrored between to SANs typically located in two different datacenters. Unlike Exchange 2007 and Exchange 2010, Exchange 2003 high availability solutions that leveraged Windows clustering functionality only had one copy of the data unless the data was replicated on the storage layer or by a third party software based replication solution. Also, Exchange 2003 had very strict IO requirements to the underlying storage subsystem, which made it a requirement to store the Exchange data on fast low size disks (136GB or lower 10k or 15k RPM SAS based disks) typically configured in RAID 10 or RAID 50 configurations. In addition, Exchange 2003 was limited by a 32-bit architecture, which meant that the Exchange 2003 server could not take advantage of more than 4 GB of memory.


Because of the storage requirements as well as memory limits, an Exchange 2003 server typically did not store more than a maximum of 4000 mailboxes. If you went over this “rule of thumb” limit, you typically experienced memory fragmentations as well as serious performance issues caused by an underlying storage subsystem that couldn’t deliver the required IOs resulting in RPC delays etc.


Because of the storage costs, user’s also had very strict mailbox limits. The norm was around 150 MB and lower. Very privileges users perhaps had a mailbox limit of 250 MB but rarely higher than that. This resulted in two things. The enterprise either invested in an expensive 3rd part archiving solution in order to move Exchange data off the SAN on to cheaper disks, or users moved data from their mailboxes to PST files which meant that the data was no longer under control by the enterprise and often not backed up.


With Exchange 2007 which was the first version that was built on a 64-bit architecture and also included new high availability features such as clustered continuous replication (CCR) changed things to the better. Exchange was no longer bound by a 4 GB memory limit, which among other things meant that the IO requirements (Exchange 2007 reduced the I/O footprint up to 70 percent) to the underlying storage subsystem were much lower than what was the case with Exchange 2003. With CCR, the enterprise could also benefit from native asynchronous replication which made storage level replication and 3rd party replication solutions somehow obsolete. With Exchange 2007 SP1, standby continuous replication (SCR) was introduced and made it possible for enterprise to have more than two database copies. The database copies on the SCR target server could even be lagged copies.


With Exchange 2007, Microsoft IT moved Exchange data for all Microsoft employees from their mirrored high-end SAN solution to DAS solutions and now could offer mailboxes of up to 2GB to the end users and still save many millions of US dollars per year as running a DAS instead of SAN based storage solution cuts storage costs significantly. Although SAN based storage solutions were still fully supported, the Exchange Product group tried to explain enterprise customers why it was a good idea to move Exchange data off the SAN to a low cost DAS based solution. Some customers followed the advice but many also continued storing the data on SAN solutions often because they already had invested in it. And guess what? Yes Enterprise customers still went out and invested in 3rd part archiving solutions because it was too expensive to store all the Exchange data on the SAN.


When it came to backing up Exchange 2007, enterprises still use either a disk or tape based point in time back solution. Although most went with a VSS based solution instead of a streaming based backup solution.


Then came Exchange 2010 and pretty much everything changed even more than when Exchange 2007 was introduced. With Exchange 2010, we once again saw huge storage optimizations. Basically the whole storage schema was re-architected and we saw more improvements than what was accomplished the last ten years! This means that it makes absolutely no sense to store Exchange data on fast low sized disks any longer. You can now use large and slow disks instead. And yes here I’m talking about 1-2 TB Enterprise SATA disks very similar to those in a workstation. Also with the new Database Availability Group (DAG) feature in Exchange 2010, you can now have up to 16 copies of a mailbox database. Granted very few would have up to 16 copies of the same database, but as long as you have 3 or more, you actually have the option of going RAID-less and instead used JBOD to store Exchange data. In addition, one or more of the database copies can be lagged copies (support for up to a 14 day database lag versus 7 days in Exchange 2007). Bear in mind though, that in order to use lagged copies, you should at least have two lagged copies on JBOD or 1 lagged copy still on a RAID.


Exchange 2010 also introduces a new totally re-architected recoverable items folder (aka Dumpster 2.0) and litigation hold feature. The recoverable items folder can be used for short-term and long-term preservation of data and the litigation hold feature for legal hold situations or very long-term preservation of data. In addition, Exchange 2010 includes a new personal archive (that is viewable via OWA 2010, Outlook 2010 and with Exchange 2010 SP1 also via Outlook 2007) that can be enabled for a user and thereby eliminate those infamous PST files. Finally, Exchange 2010 includes new retention policies that can be assigned to folders or items in a mailbox, so that data are moved from the mailbox to the personal archive associated with the mailbox.


The combination of the above, as well as newly introduced features means that many enterprise organizations have said goodbye to the high-end SAN and the expensive disks that comes with it, the expensive third party archiving solution, and finally the often expensive disk or tape based backup solution and thereby cut IT costs significantly.


In this article, I will give you an insight into how it all works. We have a lot to cover, so let’s get moving.


Single Item Recovery Improvements


For almost as long as we had Exchange, end users had the recover deleted items feature (or the dumpster as it’s often referred to among us Exchange admins/consultants) at their disposal.


Let’s quickly summarize what the recover deleted items feature is all about.


When a user deletes one or more mail items in his mailbox, they are moved to the deleted items folder. When the deleted items folder is emptied, the items are not removed from the mailbox. Instead the items are stamped with a ptagDeletedOnFlag property which makes the items invisible and unsearchable from e-mail clients such as Outlook and Outlook Web App (OWA).


When a mail item is deleted using “normal” methods (using the delete key or the click right mouse button approach), it’s considered a soft-delete and as mentioned a soft delete simply moves the item(s) to the deleted items folder. You can also shift-delete (aka hard delete) items which means they are permanently deleted from the store unless you either use Outlook 2007/2010 or run Outlook 2003 (or earlier) have enabled the DumpsterAlwaysOn registry key on the clients where Outlook is installed.


So if you either use Outlook 2007/2010 or have the DumpsterAlwaysOn key set on an older client, soft-deleted and hard-deleted items can still be viewed and recovered via the recover deleted items feature until they are purged and thereby permanently deleted from the store. With Exchange 2003, the deleted items retention window was set to 7 days by default. With Exchange 2007 the setting was increased to 14 days and this is also the default setting in Exchange 2010. This default setting is configured on the mailbox database level and inherited by mailboxes stored in the respective mailbox database, but the setting can also be configured on the mailbox level.


Figure 1: Deleted item retention window for Exchange 2003 Database

Figure 2: Deleted item retention window inherited by Exchange 2003 mailbox


With Exchange 2010, the recover deleted items feature has been restructured significantly in order to better support short term and long term preservation of data as well as legal hold situations. The recover deleted items feature no longer uses the ptagDeletedOnFlag property  to hide items, but is now a mailbox folder named “Recoverable items” that has three subfolders; Deletions, Versions, and Purges. This new folder is stored within the Non-IPM subtree of the mailbox as you can see in Figure 3 where I opened the Non-IPM substree using the MFCMAPI tool.


Figure 3: Recoverable Items folder in Non-IPM subtree viewed via the MFCMAPI tool


When a mail item is shift-deleted or deleted from the deleted items folder, it’s now moved to the Deletions subfolder within the Recoverable items folder. With Exchange 2010, the default behavior for items stored in the Deletions folder is the same as in previous versions of Exchange. When the timestamp for the item exceeds the deleted items retention window, the item will be purged from the store. If a user deleted the item by accident and it was purged, it must be restored from a traditional point in time backup if he wanted it back.


Some of you might wonder what the real improvements of the changes are as well as what the purposes of the “Purges” and “Versions” subfolder are. We will get to that right now.


With Exchange 2010, mailboxes have several new attributes. One of them is “SingleItemRecoveryEnabled”, which by default is set to false (Figure 4).


Figure 4: Single Item Recovery disabled by default


We can enable it using the following command:


Set-Mailbox –Identity hew –SingleItemRecoveryEnabled $true


Figure 5: Warning that setting may not take effect immediately


When enabled, we get a warning stating that it can take up to 60 minutes before the new setting takes effect. How long it takes depends on the size and complexity of your Active Directory topology. In a single AD site topology, it shouldn’t take more than a few minutes.


When “Single Item Recovery” is enabled for a mailbox, all items that are deleted from the Recoverable Items folder will not be permanently deleted from the mailbox, but will instead be moved to the “Purges” subfolder of the Recoverable Items folder from where it will be purged when the item is older than 14 days (if that’s the deleted items retention window configured for the database storing the mailbox). This means that a user by accident or on purpose cannot permanently delete items from his mailbox. They will all end up in the “Purges” subfolder which isn’t accessible or viewable by the user.


Even with Single Item Recovery set to “false” it’s important to note that all calendar items will be kept for 120 days and only be purged when older than that.


In addition, enabling “Single Item Recovery” for a mailbox also enables a new versioning functionality. More specifically, when/if a mailbox item is modified, it initiates a so called “copy-on-write”, which moves the original item to the “Versions” subfolder within the Recoverable Items folder and a new copy is placed in the IPM.Note and IPM.Post subtrees. This is a very handy feature in those legal hold situations, as you always will be able to find the original copy of a particular item.


By increasing the deleted items retention window to 30, 60, 90 days or perhaps a year (depending on the RPO in your organization) combined with enabling Single Item Recovery for all mailboxes, you no longer need a point in time backup solution, when it comes to restoring items from mailboxes in the organization.


Figure 6: Deleted item retention windows set to 90 days


Typically the user can recover the item(s) via the recoverable items feature, and if this is not possible or feasible, then you as the Exchange Administrator/consultant can recover the items using a new mailbox search feature, which I will demonstrate in part 2 of this multi-part article. 


If you would like to read the other parts of this article series please go to:



About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top