Backup and disaster recovery for Microsoft Dynamics GP

How do I protect my Microsoft Dynamics GP environment from data loss? The answer, very often is, “It depends.” Each organization is unique and has unique requirements, and the key question gets boiled down to “What kind of recovery solution is right for my organization?” Specifically, it depends on answers to some of the following questions…

• What is your recovery time objective (RTO)? In other words, how fast do you need to recover?
• What is your recovery point objective (RPO)? How much data can you afford to lose or re-create?
• What data are you trying to protect?
• What kind of scenarios are you trying to recover from? Hardware failure, virus attack, data corruption?
• How much money do you want to spend?

A solution which is right for a Fortune 500 company could be completely inappropriate and unaffordable for a smaller organization. I will use the rest of this post to provide what I believe to be a tried and true, solid approach to backing up a Dynamics GP environment. With a few “tweaks”, this approach will work for any sized organization and should fit nicely into an already existing backup strategy.

First, let’s start out with a few assumptions:

• The organization has an existing backup strategy in place.
• The “disaster” type does not involve hardware replacement.
• Recovery back to the prior business day is sufficient.

We also need to define what data we are backing up. Here is a starting list:

• SQL Databases: Include all companies, Management Reporter, Management Reporter Datamart, Report Server and ReportServerTempDB. It doesn’t hurt to back up the SQL System databases either. Those are master, model, and msdb.
• GP Application Files: These are generally stored in C:Program Files (x86)Microsoft DynamicsGPxx where xx is typically the Dynamics GP version identifier (GP10, GP2010, GP2013, GP2015, etc.)
• GPShare: If you configure a common location for the data associated with your Dynamics GP environment, it becomes easy to back up. For example, we typically create a folder called GPShare. In it we create sub-folders for ISV applications or additional Modules as needed for Dynamics GP. For example, GPShareIM is where the Integration Manager database(s) are kept, GPShareExcel are where the Excel Reports are kept, etc.

This will provide the basic framework upon which we can build. We will look at other scenarios in future blog posts.

The first step in preparing for a data disaster, is to make sure your company data is backed up on a regular basis. There are several approaches to doing this depending on the complexity of the IT environment (storage snapshots, off-the shelf backup applications, etc.) but the tried and true method is the good, old-fashioned SQL dump to disk. This is a backup done within the SQL Server and copies databases to the hard disk of the serer. These can be automated by using the SQL Server Maintenance Plan Wizard to create the backup plan and schedule it to run nightly.

Once the databases have been backed up to disk, the next step is to protect the backup – i.e. backup the backup. Typically, local IT departments will include the storage location of the SQL Maintenance Plan in their nightly IT backups – either backup to another disk set onsite or an offsite location. Wise organizations use both. Offsite backup storage is critical in the event of a building disaster (such as fire or earthquake) while onsite backups are critical for speed of recovery. Please note that this is also when the Dynamics GP Application files and GPShare are backed up.

The last step in your backup strategy is to ensure that the data can be successfully restored. The easiest way to do this within Dynamics GP is to restore the data to a test company. There are plenty of posts in Internet world which can walk you through these steps. My go-to is the Microsoft Knowledge Base Article #871973,
Set up a test company that has a copy of live company data by using SQL Server 7.0, SQL Server 2000, SQL Server 2005, SQL Server 2008, or SQL Server 2012″>Set up a test company that has a copy of live company data by using SQL Server 7.0, SQL Server 2000, SQL Server 2005, SQL Server 2008, or SQL Server 2012.

A note about other backup options:

There are certainly other ways to back up your Dynamics GP environment. Among those are storage or virtual machine backups or by using your favorite backup application. As an IT old-timer, I never learned to trust their abilities to adequately protect the SQL database. I’ve much preferred to trust the built-in mechanism of the SQL Maintenance Plans and have always stuck to the SQL dump to disk method. I’d then back up those flat files with whatever backup application or strategy your organization’s IT department may use.

Here is a picture of what we discussed in this post. Future posts will expand on these topics and give detailed steps and pointers.

If you are looking for more information about backups for Microsoft Dynamics GP, contact the RSM team today. We can be reached at erp@rsmus.com or by phone at 855.437.7202. If you found this information useful, consider a subscription to our Dynamics Community News publication.

By: Christina Stanley – California Microsoft Dynamics GP partner

RSM Staff