A Quick Overview of Exchange Native Data Protection

In this article we understand the concept of Native Data Protection present in Ms Exchange Server and look at points to keep in mind while implementing the same.

The Native Data Protection options available in MS Exchange are so efficient and reliable that you can totally let go of regular backups for saving the data. The Native Data Protection in Exchange provides users with in-built features for protecting mailbox data, without making use of any backups. If you want to, you can continue using backups, but the Native Data Protection feature in Exchange 2013 and later editions has features which, if deployed correctly, can completely eliminate the requirement of backups. Combining this feature with the high availability in Exchange, you can reduce downtime, data loss and data backups.

Tips to Keep in Mind while working with Native Data Protection in Ms Exchange

If you begin estimating the cost of your backup infrastructure for Exchange Server, you might conclude that having a database with around three copies of mailbox database, is cheaper than having one copy with a backup. You might choose to eliminate traditional backup and make use of the Native Data protection for Exchange, but do consider the following:

1. Before you decide to entirely do away with all types of traditional backups, ensure that you have sufficient mailbox databases copies for deployment. 3 non-lagged copies are a minimum.

2. 指定恢复时间Objective along with Recovery Point Objective goals, and make sure that the set of features you are using are sufficient to replace the need of traditional backups and achieve the specified goals.

3. Determine the number of copies needed for each database to cover all possible failure scenarios the feature can protect against. If you deploy lesser number of copies, you might have to face loss of data.

4. You need to understand if eliminating a Database Availability Group (DAG) or reducing its members can provide support for a backup. If yes, you need to decide whether this backup solution can help you improve your key recovery time objective along with recovery point objective SLAs

5. Being an elaborate email server that it is, Exchange 2013 allows organizations to hold extremely large mailbox databases, with maximum size allowed up to 2 TB. Keeping in mind the large databases of the organizations, you should decide you recovery point objective.

6. The user should be able to decide if it is affordable to miss a point-in-time data copy, in-case of corruption in DAG hosting the copy.

7. You need to find ways for dealing with logical data corruption of active databases, that can be replicated in passive databases. You will have to create a recovery plan for such a situation, keeping in mind the frequency of similar situations that took place in the past. If there are frequent instances of logical corruption in your organization, it is suggested to factor that scenario in the design by making use of lagged copies. This should be done by including an ample replay lag window which allows the user to discover and act on an instance of logical corruption, whenever it occurs. And the action needs to be quick enough to prevent replication of corruption to other copies of the database. Also as a failsafe keep anost file recoverytool handy to deal with emergencies.

Author Introduction:

Van Sutton is a data recovery expert in DataNumen, Inc., which is the world leader in data recovery technologies, includingrepair Outlook mail damageand bkf recovery software products. For more information visitwww.circareview.com