Plan backup and recovery
Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
By carefully planning and implementing a backup and restore strategy, you can help protect your environment against data loss. In addition to the transaction data that is stored in the business databases, all models and customizations are now stored in the model store databases. Therefore, we recommend that you protect both the business databases and the model store databases in your Microsoft Dynamics AX environment. Develop a strategy, and regularly test your backup and recovery procedures to make sure that you are prepared to effectively respond to a failure or disaster.
Tärkeä
Microsoft Dynamics AX does not include any built-in backup and recovery tools. We assume that you rely on Microsoft SQL Server or other tools that support backup and recovery. For example, Microsoft System Center Data Protection Manager can be used to protect Microsoft Dynamics AX. For more information, see How to Protect Microsoft Dynamics AX 2009 with System Center Data Protection Manager 2007 sp1 and the Data Protection Manager documentation.
The importance of backups
A backup is a copy of a database that is used to restore and recover data after a system failure. By using appropriate backups, you can recover from many failures, such as the following kinds:
Media failures
User errors, such as a table that is dropped by mistake
Hardware failures, such as a damaged disk drive or permanent loss of a server
Natural disasters
Database backups are also useful for routine purposes. For example, you can use a database backup to copy the database from one server to another, set up database mirroring, or archive the database for governmental purposes. For information about how to select and implement a backup and recovery strategy, see your database documentation.
Databases that must be backed up
Include all the databases in your Microsoft Dynamics AX system in your backup and restore strategy:
The SQL Server Microsoft Dynamics AX business database.
The Microsoft Dynamics AX model store database. The name of this database consists of the name of the business database plus _model.
The Microsoft SharePoint Server 2010 databases that support Enterprise Portal for Microsoft Dynamics AX.
The SharePoint 2010 products databases that support Enterprise Search.
The Microsoft SQL Server Reporting Services database that supports ad hoc reporting.
The Microsoft SQL Server Analysis Services database that supports OLAP reporting.
The Microsoft BizTalk Server database, if BizTalk Server is deployed.
Databases that are used by any applications that are integrated with Microsoft Dynamics AX.
Backup and recovery strategies
A well-designed backup and recovery strategy maximizes data availability and minimizes data loss. The actual amount of data that is available and the amount of data that is lost depend on your business requirements, environment, and resources. A backup and recovery strategy is based on service level agreements for recovery point objective (RPO) and recovery time objective (RTO).
A recovery point objective specifies the acceptable interval between backups, or how much data loss is acceptable.
A recovery time objective specifies the service level agreement for the time that a recovery takes.
A backup strategy defines the type and frequency of backups, the nature and speed of the hardware that is required for backups, and backup security. A backup strategy also defines how backups are tested, where backup media is stored, and how it is stored.
A recovery strategy defines how to restore databases to meet your goals for availability of the database and for minimizing data loss. A recovery strategy also defines who recovers the data.
We recommend that you document your backup and recovery procedures and that you keep a copy of the documentation in your operations manual.
Designing an effective backup and recovery strategy requires careful planning, implementation, and testing. Consider the following factors:
RPO and RTO
Availability requirements
Constraints on resources, such as hardware, personnel, space for storing backup media, and the physical security of the stored media
The use of each of your databases:
How often does the data in each database change?
Are some tables modified more often than others?
What are your critical time periods? What are the usage patterns during these periods?
When does the database experience heavy use that causes frequent inserts and updates? You may want to schedule differential or log backups during periods of heaviest use, and full backups during off-peak hours.
Does the database require additional protection, or can the information that it stores be re-created from other sources and still comply with your service level agreements?
Planning for disaster recovery
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.
Next steps
For more information about how to implement a backup and recovery strategy for your environment, see the following documentation: