For business management solutions email us or call 020 3004 4600

How to create a Dynamics GP Backup

Your Microsoft Dynamics GP system is critical to your organisation. So, what would happen to your business if your Microsoft Dynamics GP system encountered a system failure?

As part of maintaining a ‘healthy’ system, it’s critical that you backup Microsoft Dynamics GP on a regular basis. As part of a disaster recovery plan, business critical information and data is backed up and available for restoration in the event of a system failure. This blog post provides a set of basic recommendations for backing up your Microsoft 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 Microsoft Dynamics GP but it may not be complete for your particular situation.  Each installation should be analysed 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 Microsoft 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. 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.

4. Other Customisations – 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).

5. Jet Reports, Sharperlight, BI360, Power BI or other external reporting software – The reports should be located in a folder that is included in the nightly system backup.

6. Other Databases - In addition:

  • 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.
  • SmartConnect – Backup the SmartConnect database 
  • eRequest – Backup Nolan’s eRequest database which should be on the same SQL server. In addition to this locate where the IIS web site for eRequest and back the files up on a weekly basis.
  • Copies of the original software and note of the file location – Keeping a record of the exact versions of the software that is put in place, together with the application installation files (including any hotfixes and patches applied) will be useful to the System Administrators when performing subsequent installs and help keeping downtime to minimum.

Please note: 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.

If you have any doubts regarding the steps outlined above or have any further questions regarding backups in Dynamics GP, please get in touch with Advantage.