Are You Sure Your Data Is Being Backed Up?

Are The Backups Successfully Running?

Are You Backing Up The Right Files?

Can You Actually Restore From Those Backups?

You have your Dynamics GP environment all installed and running and you’ve set up some backup jobs, or installed a tape backup system, and you’ve been going to bed at night confident that should some disaster occur, you would be able to recover your Financial Systems data from a recent backup.

Most client’s Dynamics GP environments that I’ve worked on have proper regular Financial Systems Data backups in place – but have never had to rely on those backups.  And one day, due to some unfortunate event (power outage, fire etc.) they may reach for their backup device or tape to recover their data only to discover the tape is empty – or – the backup file is incorrect, unusable or corrupt – or they haven’t backed up some critical files.  Or they discover their server’s hard drives have all of a sudden run out of capacity and their Dynamics GP System starts to freeze up – because the backup system wasn’t configured correctly and has used up all the available hard drive space.

I was called in once to a client site to assist with a data restore after a mishap they had. I asked if they had current backups of their Dynamics GP data; to which they confidently and proudly replied they take SQL backups every day, and then use an additional Tape Backup Scheme to back up the SQL Backups – and cycle them once a week and once a month – and store the backups offsite for safe keeping.   We retrieved the backup device from the previous night’s backup only to discover that the backup data set on the tape was from several months prior.  We then retrieved tape after tape going back several months and each had the same old backup set on it from months ago.

Unfortunately, for this client, something had gone wrong with their backup process several months back and their backup tapes were simply backing up the same old SQL backup set every day (it turned out their SQL Agent had stopped running and never restarted – so there was only one old set of SQL Database backups from the last time the SQL Agent had successfully run).  In the end, we were able to restore an older backup set; and unfortunately re-enter a few months’ worth of entries – this was costly and time consuming for the client and extremely risk prone (as it was difficult to dig up all the past two months’ worth of transactions that had to be re-entered).   I had a different client whose backup sets were running every night and copying to the external tape – but the backup set was empty.

Had these clients reviewed their backups regularly, or checked occasionally to see the backup jobs were running (even once a week) – or perhaps tried a TEST restore occasionally, they would have discovered these issues sooner and been able to rectify and restore a consistent and updated backup set, and would have avoided the stress and cost of their unfortunate circumstances.

If you want to sleep at night, confident knowing you can recover your Financial Systems successfully from some systems or environmental mishap, my recommendations are to make sure at least:

• You have the Recovery Method (a SQL Backup Option) set correctly on your Dynamics GP databases (DYNAMICS and each COMPANY database) and your Management Reporter and DataMart databases.  Generally the recovery method is set to SIMPLE – in this way, SQL expects that you are backing up your databases at least once a day.
  
  If you decide that you want to be able to restore your data to a specific instance in time (not just the previous nights’ backup) – you will want to set the Recovery Method on your Databases to FULL – and then you must ensure you Back Up your Database Logs (otherwise they will grow uncontrolled until they consume all available hard drive space).
• Use the SQL Agent to run SQL Jobs and SQL Maintenance Plans to have your databases backed up at least once daily – a Full Backup once daily (Recovery Method = SIMPLE) will allow you to restore to the previous night’s backup); and keep 3 to 5 days’ worth of these backup sets online (on your server’s hard drive depending on how much capacity you have).
  
  Or depending on the criticality of your data, implement not only Full DB Backups – several times during the day – but LOG Backups as well (Recovery Method = FULL, so you can restore to an actual instance in time and not just from the previous night’s backup).
• In addition to having SQL create *.bak Database backup sets, employ a Tape Backup scheme to backup these *.bak sets to the Tape (or other portable device) – and have a cycle of these tapes (daily, weekly, monthly) – to store offsite.  You may even employ some form of ‘Backup to the Cloud’ method.  No matter what you use, at least have some form of secondary backup and don’t just rely on the backup sets that SQL stores on the server’s hard drives.
• You will want to ensure that not only do you back up the *.bak files, but you include other important GP Application files as you would see in the \\SERVER\Dyndata folder for your installation – these would include Modified Reports dictionaries or Management Reporter Building Block Groups.
  
  I would add that you occasionally do an export of your Management Report Building Block Group(s) to *.tdbx files – and save these in the DYNDATA folder on the Server’s hard drive; as well as occasionally creating an Exported package file of your modified Reports and Forms (if applicable).
• Occasionally review that your system has successfully run the previous day’s backups – you can look at the History of the SQL Maintenance Plan or SQL Agent Job in SQL Server Management Studio on the server; and also look on the server’s hard drive where the backup sets are being written to and see that there is a current dated set from the previous night.  You will also want to ensure that the SQL Agent Service is running – you can check this in SQL Server Management Studio or in Services on the server.
• As part of your DRP procedures, schedule a regular Test Restore (quarterly or annually depending on the criticality of your data) to restore a database and some flat files (older modified reports dictionary, or Excel spreadsheet).  This will ensure at least to a point that what you are backing up on a regular basis is being backed up correctly, you can restore from these backups and that the data in the restore set is intact and valid.
• If your recovery is significant due to a full disaster, it is useful to have all your source software media and correct versions available as well (and you have documented any specific settings, versions or configurations) – in the event you not only need to restore your data but need to re-install your client applications (Dynamics GP, Management Reporter, Custom Code, Add-On Applications etc.) and back office applications (SQL Server, Operating Systems, etc.)

In summary, be sure that:

• You review your environment and systems to make sure you are taking regular Database and File backups of all the correct data and software, modified files and settings – and these backups are correctly configured.
• These are in turn being backed up to some additional device and cycled off-site.
• You occasionally check to see that the backup systems are actively running and successful.
• You occasionally try a Test Restore.
• You have access to all source media and software builds if a re-install is required.

In this way you will remain confident that in the event of a systems mishap, you can recover in a timely fashion and restore functionality with the least amount of cost, stress and downtime.