Plan for disaster recovery [AX 2012]

Updated: August 9, 2013

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

To guarantee that all your systems and data can be quickly restored to regular operation if a disaster occurs through natural or human causes, you must implement a comprehensive disaster recovery plan. As you create this plan, consider the various kinds of disasters that might affect your organization. These disasters might include natural disasters, such as a fire, and technical disasters, such as a multi-disk failure in a RAID. When you create a disaster recovery plan, identify the steps that are required to respond to each kind of disaster. You must test the recovery steps for each scenario. We recommend that you verify the robustness of your disaster recovery plan by simulating a catastrophic event.

When you plan for disaster recovery, consider your specific environmental and business needs. For example, if a fire occurs and wipes out your 24-hour data center, are you sure that you can recover? If you can recover, how long does it take you to recover and make your system available? How much data loss can your users tolerate?

We recommend that your disaster recovery plan specify how long recovery should take and the final database state that users can expect. For example, you may determine that recovery can be completed in 48 hours after replacement hardware is acquired, and that data can be guaranteed only until the end of the previous week.

A disaster recovery plan can be structured in various ways and can contain many kinds of information. A comprehensive recovery plan contains the following elements:

  • A plan to acquire hardware, or to create and share virtual servers in another location.

  • A communication plan.

  • A list of people who must be contacted if a disaster occurs.

  • Instructions for contacting the people who are involved in the response to the disaster.

  • Information about who will administer the plan.

  • A checklist of the tasks that are required for each recovery scenario. To help you review the disaster recovery later, initial each task on the checklist as it is completed, and indicate the time that the task was completed.

To guarantee that you are ready for disaster, we recommend that you periodically perform the following actions:

  • Perform regular backups of databases, transaction logs, and file systems to minimize the amount of data that is lost. We recommend that you back up both system databases and user databases.

  • Test your backup and recovery procedures thoroughly. You must perform appropriate testing to make sure that you have the backups that are required to recover from various failures, and that the backups function correctly. Testing also helps you make sure that your procedures are clearly defined and documented, and that they can be executed smoothly and quickly by any qualified operator.

  • Maintain system logs in a secure manner. Keep records of all service packs that have been installed for Microsoft Windows, your database, and Microsoft Dynamics AX.

  • On another server or set of servers, test the steps that are required to recover from a disaster. If necessary, modify the steps so that they are appropriate to the server environment, and then test the modified steps.

  • Make sure that you understand and document the database rights that are required to recover the database.

  • Plan for the loss of your whole infrastructure and each Microsoft Dynamics AX server component. Additionally, consider the effect if the domain controller for your Microsoft Dynamics AX implementation is lost.

  • Make sure that you identify all employees who perform recovery tasks. Additionally, make sure that you document all tasks that are required, so that the tasks can be performed even if those specific employees are unavailable.

The methods for protecting databases for disaster recovery are similar to the methods used to ensure database availability. The following table lists options.

Option

Pros

Cons

Database mirroring

Fast failover, consistent when "high safety" mode is used.

Almost real time

Servers can be geographically dispersed

Mirrored datas is not accessible

Dual commit in "high safety" mode require SQL Server Enterprise Edition

Log shipping

Relatively easy to set up

Stable

Data is only as consistent as the last transaction log applied

Log shipped database is not accessible

One way transactional replication

Almost real time

Difficult to configure with Microsoft Dynamics AX

Difficult to determine which transactions were committed and which were rolled back at failover

AlwaysOn availability groups

Fast failover

Consistent

Less overhead than mirroring

Readable secondaries

Multiple secondaries

Can be geographically dispersed

Requires SQL Server Enterprise Edition

Database backups

Time to restore, migrate to a new environment

SAN replication

Robust

Almost real time

Consistent

Can be geographically dispersed

Expensive

Difficult to configure

Virtual environment snapshots

Easy to restore

Requires that you run virtual environments

Only as consistent as last snapshot saved


Announcements: To see known issues and recent fixes, use Issue search in Microsoft Dynamics Lifecycle Services (LCS).

Community Additions

ADD
Show: