5 Easy Maintenance Tips

SQL BackupMake SQL backups of every database on your SQL server! You can do full backups only or full backups with transaction log backups depending on your needs.

You need to backup Dynamics databse, Company(s) database(s) and Model database

File BackupWhile most people know to make SQL backups with Dynamics-GP there are also multiple files that need to be backed up along with the SQL backups. Those files include but not limited to:

• Any file in the folder that ends in: dic, set, or config. And considering that the GP folder with all subfolders is not that big it would be even better to back up the entire folder and subfolders.
• While you are in that folder also open the Dynamics.Set and the DynUtils.set and look for any files that you did not get in the above list.
• Also in that folder is a folder named . You need to get all of that folder as well.
• Inside the folder is a file named Dex.Ini. This file lists the locations of other files that you will need to backup. While there is quite a lot in this file look for the following items and backup the folders that are listed; OLEPath, OLEPathHR, Word Macro File, Letters Directory, ReportDictionaryPath, FormDictionaryPath.
• And do not forget to go through the manuals of any add-on products to get information on what needs to be backed up for them. For example FRx has a SysData folder that needs to be backed up.

Schedule Your BackupsSchedule your backups both SQL and FILES depending on your needs. Keep in mind that the more often you backup the less information you lose should something happen. The main thing is that it should automatically occur at some interval without someone having to remember to make a backup. It’s not proper to say that more backups are better. If a database is big, for example 200 or 800 or even 2000 mgs (and even larger) that would be a disaster for performance. The strategy is to have full backups and incremental backups with transaction logs

Monitor Your Backup JobsWhile it sounds silly, you should monitor your jobs to make sure that everything is happening as it should. While you can set up your SQL server to notify you if the job fails, you still need to check the job periodically. There are cases where a job can "hang" and because it technically has not failed you do not receive a notification from SQL, yet the job is not running as you expected and nothing is being backed up. This is also a good time to check how long the jobs take to see if you need to adjust the schedule for performance or availability reasons.

Test Your BackupsAnother thing that people sometimes forget is to periodically test their backups. Is the SQL backup file actually a good backup? For you SQL Backups, restoring the backups to another server is usually a good test. If you have another copy of Dynamics-GP on another server for testing purposes this is a good place for you to place you file backups to test if you have good file backups.


Compliments of GPUG