Recommendations for a Backup Policy for Microsoft Dynamics GP

Backups to Microsoft Dynamics GP and related software are a critical part of maintaining a “healthy” system.  As part of a disaster recovery system, they keep your data available for restoration in case of a system failure.  This article provides a set of basic recommendations for backing up pertinent Dynamics GP information.  As every installation is unique, each installation should be reviewed to ensure all critical data is available.   This list covers the basic components in Dynamics GP but it may not be complete for your particular situation.  Each installation should be analyzed to ensure all critical components are included.

 SQL Database Backups

1. Database Backup – The DYNAMICS and production databases should have full backups run on a nightly basis.  Typically, a SQL maintenance plan creates a backup each night and those backups are saved on a network share and included on the nightly “tape” or “external” system backup plan.  Backup software now frequently includes a method of backing up SQL databases.  This method can be done instead of the SQL maintenance plan backups, however, a restore should be tested before making this the primary SQL method.
2. Transaction Log Backup – SQL transaction logs should be backed up throughout the day.  The SQL maintenance plan can be designed to backup the transactions as frequently as desired.  A frequent frequency is to backup the log hourly.  These log backups should be located on a network share and included in the nightly system backup.  The database must be using the FULL Recovery Mode .  If the FULL Recovery Mode is not being used, the transaction logs will not be current.  To check the recovery mode, in SQL Management Studio, right click the database, select Properties and then select the Options page and verify the Recovery Mode = FULL.

Other Dynamics GP related files/databases

1. Modified Reports and Forms dictionaries – The REPORTS.DIC and FORMS.DIC files should be located in a network share and included in the nightly system backup.  If there are modified reports or forms for other modules or third party components, include those  dictionaries as well
2. Integration Manager – The .mdb or .imd file contains the integrations and should be included in the nightly system backup.
3. FRx SYSDATA folder – This folder contains the specification sets and connection information for FRx and should be included in the nightly backup.  The IO_Data folder contains the latest viewable copies of the reports after they have been generated.  Although this folder can be backed up, it is not as critical as the SYSDATA folder since the reports can be re-generated
4. Management Reporter – Management Reporter uses a SQL database to contain its information and the database should be included in the Dynamics backup maintenance plan noted above.
5. Other Customizations – In addition to the FORMS.DIC and REPORTS.DIC files, a package file should be created and saved in a network share.   To create a package file go to Microsoft Dynamics GP > Tools > Customize > Customization Maintenance.  Sort the entries by type, highlight all of the entries, and click Export and name the package file appropriately.  If you have entries of different types, it is best to create a separate package file for each product and type.  (i.e. one package for Dynamics reports, one for Dynamics forms, one for each third party reports dictionary)
6. Crystal Reports or other external reporting software – The reports should be located in folder that is included in the nightly system backup
7. Other Databases

• Business Portal and SharePoint – These programs use SQL databases and should be included in the SQL backup plan and included in the nightly system backup.  These programs also create files in at C:\inetpub\wwwroot\wss\VirtualDirectories\<port number>.  These folders contain information for the IIS virtual Server and should be backed routinely, especially after changes are made to SharePoint sites
• Web Services for Dynamics – This program creates a SQL database and should be included in the SQL backup plan and included in the nightly system backup
• SQL Administrative databases – The SQL admin databases don’t change as often but should be backed up at least weekly in SQL and included in the nightly system backup.  If changes such as creating new databases or adding users to Dynamics or SQL take place, the SQL admin databases should be backed up.

Just designing a backup plan for your Microsoft Dynamics GP system and setting it in motion does not end the backup process.  Keep in mind the following ideas.

1. Check the backup logs routinely.  If any FAILS are noted, determine the cause of the problem.
2. Check the backups by performing a restore of a database.   Backups can be made “successfully” but are not capable of being restored.
3. After a SQL maintenance plan is created, check the performance daily for the first week or two to ensure that it is performing as expected.  Check that the old backups are being deleted after the allotted time usually 4-7 days.  If the old backups are not being deleted, they can quickly fill up a hard drive
4. Verify that the transaction logs are properly truncating.  After a full backup is run, the transaction log should re-start.  If the log doesn’t truncate, the log will continue grow and can fill up a hard drive.
5. Even if the plan seems to work fine, at least once a month, check that old backups are being deleted and the transaction logs are truncated.  Occasionally, the plans stop without notice and you can be stuck without backups or with a full hard drive.
6. Keep SQL up to date with the latest service packs

RSM McGladrey has been implementing Microsoft Dynamics ERP Business Solutions for more than 30 years.  Please contact us for more information on capabilities or how we can help you with Microsoft Dynamics GP implementation. 

By:  Claude Frymark, McGladrey – Microsoft Dynamics GP Specialist