Application-Item Restore which Depends on Native Tools Might Not Be Good Enough

Some talk of "Universal Application-Item Recovery" has been offered in the market, describing how it might be able to work for organizations interested in being able to use a single approach to restoring any object from a backup image. Like other people paying attention, we were interested in what sounded like a good benefit to offer for admins working with images.

We took some time to examine the approach, and what we now believe is that an approach to restoring objects from images which is dependent on native tools is not a practical solution. The limitations are too extreme. The requirements for their use are too inflexible. Ultimately, we don't believe that organizations will find these approaches to be beneficial. Instead, we believe that what is required is a true Object-Level Recovery (OLR) solution built to enable flexible and fast restore of any object from the image.

Exchange Item-Level Recovery Using Native Tools

Let's take a look, for example, at how a native-tools dependent item-level restore would operate for Microsoft Exchange email. In Exchange 2010, Microsoft offers a capability called Deleted Item Restore. As a native tool, end-users can use Outlook to connect back to a VM in a backup repository from an earlier Point-In-Time (PIT). Then, they can search for, find, and restore the individual email that was deleted.

Sounds OK so far, but let's look at the details of what has to happen:

  1. In the first place, this scenario REQUIRES that end-users DO THEIR OWN RESTORE - the Admin cannot assist.
  2. Outlook search capabilities are pretty basic - end-users will WASTE A LOT OF TIME on this type of restore.
  3. ONLY INDIVIDUAL MESSAGES can be restored using this native tool - if an entire mail folder is required, it cannot be recovered.
  4. The VM in the backup repository must be launched by the Admin before the end-user connects to it - the Admin cannot easily know which backup copy to launch. Which one has the right PIT for the end-user to find what they need?
  5. If a vendor does not name their backup files by the name of the VM like we do with vRanger Pro, then which file, exactly, has which VMs?
  6. If a vendor uses Synth Full to perform backups, then while the VM is running from the repository, any new backups will write changes into a temporary location - which then must be merged into the backup file after the VM is stopped. How safe/reliable will this be for backup jobs?
  7. Each end-user may need a different VM to be running to perform restore -- or the same VM but from different Points In Time. How many VMs will need to run in the backup repository at the same time? How much memory will this require?
  8. Does running say 20 Exchange VMs from the repository at any given time violate Microsoft's licensing?

There is a way, using Microsoft native tools recovery, that Admins CAN assist in restore. However, it is so impracticle that I cannot imagine an admin considering its use. To make this work, a Microsoft Discovery Mailbox would have to be defined and used for the browse and restore of email messages. The real purpose of the Discovery Mailbox, as the name implies, is to assist with email discovery and production for legal purposes. Retrieving email into the Discovery Mailbox does not restore them; getting a retrieved message back to an end-user mailbox is a multi-step process. Also, using the Discovery Mailbox REQUIRES that Exchange be set up with Full Text Indexing on every mailbox. This means that the Exchange server will perform a full text index on each and every email received into the server, which slows it down. It then stores all of the indexing metadata which dramatically increases the storage requirements for the Exchange server.

Some Questions to Consider When You are Considering an OLR Solution for Exchange

  • Running a second Exchange instance is potentially a license violation with Microsoft - how will Microsoft view this?
  • How many Exchange instances will be needed to serve all of the end-users in an organization, who need email from different PITs?
  • How will the Admin manage the process of starting up all of the VMs in the repository which are required?
  • How much memory will be required to enable all of the VMs to be running simultaneously for end-users?
  • How much storage will be required to collect subsequent chanages in the repository backup file while the Exchange VM is running?
  • How safe/reliable will the process be for re-synching changes in the backup file after the Exchange instance is stopped?
  • Microsoft Outlook search is pretty basic and may be time-consuming for end-users to use to find the messages that they need.
  • Microsoft Outlook restore is limited to individual messages ONLY.
  • The end-user has to do all of the work for restoring messages.
  • Requirements for Full-Text Indexing to enable a Discovery Mailbox so that an Admin could perform mailbox recovery for an end-user is impractical to support in the environment, and the multi-step restore process that would be required is too complex and time-consuming to be useful.

True OLR for Exchange Working with vRanger Pro 4.5

In contrast to a native tools method, the Object-Level Restore (OLR) for Microsoft Exchange that shipped from Vizioncore in late May offers flexibility and efficiency. A complete description of how it operates has been offered in an earlier blog entry, which you can read here. In summry, you may want to keep these key points in mind:

  • Throught the RME console, an Admin has access to every email folder in the Exchange database.
  • With no need for Full-Text Indexing at the Exchange server, RME offers comprehensive keyword and boolean search of email headers, body content, attachments and metadata.
  • Comprehensive search is critical for being able to find the Exchange objects that are required for recovery, quickly and easily - and without wasting time.
  • Objects selected from the Exchange database can be restored directly back into the production Exchange environment, without disrupting that environment.
  • Objects that can be restored include ANY of the Exchange objects in the database, and is not limited to email messages only.

Exchange OLR is Just the First Step

Vizioncore has full access to the Intellectual Property at Quest, including the complete suite of Recovery Manager solutions. Recovery Manager for Exchange is just the first in a long list of proven solutions which we are in the process of offering with vRanger Pro to enhance image-based data protection, either as qualified or integrated solutions.

If you are interested in a native tools approach to OLR and if you think that I and the core team at Vizioncore has missed something in terms of the potential benefit of this type of approach, I am interested in hearing from you. Object-level recovery from images is critical for the industry, to enable a transformation from traditional backup into Backup 2.0 image-based methods. In short, OLR unlocks the potential of image-based backup and we want to get it right in all possible useful forms.