In recent client interactions, a recurring theme has been the lack of proper backups for Dynamics GP systems, encompassing databases, modified dictionaries, and customizations. This issue is so pervasive that verifying backup integrity has become a standard initial step in my client engagements. Regrettably, backup problems are commonplace, ranging from dysfunctional jobs to obstacles hindering data recovery when needed.

While certain backup methods can be intricate, Dynamics GP backups needn’t be. Simplicity is key, especially during data loss or system outages, as complexity can escalate the possibility of human and technical errors.

This discussion aims to cover the fundamentals of Dynamics GP backups and offer insights based on my observations. Your contributions regarding details, helpful suggestions, and cautionary tales of backup failures are highly encouraged.

Essential Components of a Dynamics GP Backup Strategy:

1. SQL Server Database Backups: This includes backing up the Dynamics database along with all production company databases. The Dynamics database is crucial as it houses Business Portal data, custom SmartLists, Analytical Accounting setups, and user access and security configurations.

2. Dynamics GP Application Backups: Prioritize backing up modified forms and reports dictionaries, Dynamics.set file, VBA files, and files within the AddIns and Data folders. Backing up the entire Dynamics GP application directory offers a simple, efficient, and reliable approach. Shared dictionaries in separate locations should also be backed up.

3. SQL Server Security Settings Backup: A backup of SQL logins and users is invaluable, especially in scenarios necessitating migration to a new SQL server. Scripting these security settings enables swift recreation of SQL logins, proving particularly beneficial for systems with numerous GP users.

Backup Frequency and Methods:

1. SQL Server Databases: Ideally, employ the Full recovery model for Dynamics and production GP company databases to enable point-in-time recovery. This model usually involves nightly full backups and transaction log backups every 1-2 hours during business hours, minimizing potential data loss. Simpler approaches like nightly full backups without transaction logs or the Simple recovery model with nightly backups are also viable options. The SQL Server Maintenance Plan Wizard simplifies the scheduling of database and transaction log backups. When using this wizard, ensure the creation and activation of a schedule. Avoid appending backups to a single file, as this results in unwieldy file sizes. Utilizing separate directories for each database enhances organization and searchability. Backups should be stored on a different physical disk than the database files to safeguard against data drive failures. Nightly standard SQL Server backups to disk are highly recommended, retaining 3-5 days of backups for easy accessibility. These backups can then be transferred to tape or archive disks for long-term storage. Maintaining several months of monthly backups provides a safety net for recovering older data. Direct backup of SQL databases to tape using backup software is discouraged, as it can complicate urgent recoveries. Given the affordability of disk space, maintaining accessible SQL backup files on disk is paramount.

2. Dynamics GP Application: Utilizing WinZip or WinRAR to compress the entire Dynamics GP application directory into a single file, employing a descriptive naming convention, offers a practical approach. This compressed file, typically under 500MB, facilitates selective file restores or complete GP install restorations. The frequency of this backup can be lower, ideally after customizations, module additions, upgrades, or on a monthly schedule.

3. SQL Security Settings: Dynamics KB Article 878449 outlines the use of the “Capture_Logins.sql” script for backing up SQL Server logins and passwords. This backup aids in server restorations, migrations, or setting up new test environments. Having these logins readily available significantly streamlines recovery processes. Similar to Dynamics GP application backups, this step can be performed less frequently, as long as the majority of users are included in the script.

Backup Archiving and Recovery Plan Testing:

Implementing on-site and off-site archiving strategies is crucial. Rotating external drives containing backups to a secure off-site location provides a simple yet effective solution. Online backup services offer a cost-effective and convenient option for specific data types. Exercise caution with Dynamics GP Human Resources or Payroll module backups, ensuring compliance with data privacy laws and considering encryption for off-site storage.

Testing your backup plan through a recovery plan is paramount. While often neglected, it’s a relatively simple practice that should be conducted periodically.

Testing Your Backups:

1. Install a new SQL Server instance on a Windows server.
2. Install Dynamics GP on the machine.
3. Restore your GP application directory from your backup.
4. Restore your most recent GP database backups.
5. Execute the generated SQLLOGINS.sql script.
6. Configure a DSN pointing to the SQL Server instance.
7. Launch GP, log in as both ‘sa’ and a regular user, and verify data integrity and user access.

Subsequent tests should be faster as you’ll only need to repeat steps 3 to 7. By adhering to these backup and recovery practices, you’ll be well ahead of the curve in safeguarding your Dynamics GP environment.