Creating a Dynamics GP Backup Plan

There are few things as uninteresting—or as important—as dependable computer backups. They are uninteresting because few users in corporate computing environments are ever aware that backups are even taking place, but they are vitally important when a system experiences a catastrophic data-loss incident. Backups are one of the cornerstones of computing, and Dynamics GP should be part of your organization’s backup strategy.

What does a good backup strategy for Dynamics GP look like? The starting point for developing a strategy should be your organization’s written IT and data policies, which usually encompass data retention, disaster recovery requirements and business continuity planning. It’s very important to be in compliance with any written policies currently in place, so be sure to review those.

If your organization doesn’t have a written policy governing how to back up your data, it’s advisable to develop one that includes Dynamics GP and any other systems that affect your financial data. The details of developing a full backup policy exceed the scope of this article, but we will attempt to cover the most critical areas. Also, future articles will provide technical details of configuring SQL Server database backups.

A little technical background about Dynamics GP is necessary in planning your backup. The first components of the application are the SQL Server databases, which include GP system database, DYNAMICS and additional company databases, which are named on creation. If you are unsure which databases are GP databases, you can get this information in SQL in the SY01500 table of the DYNAMICS database. You also can find this in GP in the company ID field of the company setup window.

Be aware other databases should be backed up depending on your Dynamics GP configuration. These could include the Management Reporter database, SQL Server Reporting Services databases and SharePoint databases if Business Portal is being used.

Keep in mind SQL Server database files can’t be copied to backup device with SQL Server running; they need to be backed up using the appropriate SQL commands. An SQL Server maintenance task can be used to create the backup jobs on the appropriate schedule with the proper parameters, or a commercial enterprise backup product can be used.

The other Dynamics GP items that should be backed up are components stored in the file system, not the databases. These are typically—but not always—located on a network share and are common to all users. They include modified forms and reports dictionaries, Integration Manager databases, the FRx SYSDATA folder, Word templates and modified Excel refreshable spreadsheets used with Dynamics GP. Note:  Plan to migrate to Management Reporter if you’re still using FRx.

Now that you know what to back up, you need to determine when, where, who, etc. Let’s examine these facets of a backup strategy individually:

When:  Plan a backup schedule that doesn’t interfere with business operations but is frequent enough to recover most of your work, if necessary. Most businesses back up data nightly, meaning they will lose no more than a day’s worth of work, but that isn’t sufficient for some types of businesses. In addition to sophisticated high-availability features, SQL Server also provides advanced recovery options that can help reduce data loss and business downtime. Make sure you understand the effect of lost data and productivity when you develop your backup strategy and incorporate the features that best meet your needs.

Where:  Ideally, backups should ultimately be stored in a location other than the building or campus where the Dynamics GP server is located. It’s common for backup media to be taken to a secure vault provided by a data storage vendor. When you consider the range of events that could take a server out of commission, don’t forget about natural disasters, fires and theft. Most events that compromise a server also will affect backup tapes.

Who:  Identify the individuals responsible for backups. Their tasks should include reviewing backup logs to make sure backups are successful and regularly restoring backups to a test environment. A backup plan isn’t complete unless it includes testing the restore function periodically.

Contact us for more information on establishing a backup plan.