Armanino Blog
Article

Backup routine

November 07, 2008

It's amazing how many times I get calls from people that have a catastrophe with their GP system but have no backup. Yesterday I finished up a call with a user that had an LDF file (GP log file) magically disappear. The log file itself was a second log file that is used to speed up transaction log performance since their database is about 25 GBS.

"Didn't seem like that big of an issue just to have a log file deleted" said the user. With the disappearance of this log file users had not been able to get into GP for 3 days. The backups that should have been run nightly had not been done since late September. The drive that the backups were scheduled to was a removable drive that was removed and not replaced in September. No backups were able to be done and the log file had grown to 27 GBS which used up all the space on the data drive and kicked SQL into single user mode. After several calls and attempts at restoring the MDF file from early November we ended up having to restore back to September 28th. They lost an entire months work because no backup were being done.

Here are some suggestions to creating a successful backup routine to avoid situations like this:

  1. Make checking to see if backups are being done a weekly (at least) job requirement for the IT department in your company. As IT people come in and out of the company, make this a department responsibility so you don't have the unfortunate/frequent occurrence of new people saying "the person responsible left and no one was checking backups".
  2. Have the accounting department also check to make sure backups are being done. Surely with two departments checking this will be monitored sufficiently. Place a shortcut on the accounting persons desktop so they can verify they see a BAK file in the backup folder on the server.
  3. Place all modified reports files on the server so these files can be backed up nightly as well.
  4. Make sure all files are being backed up that could cause you loss of data. For example - The actual .BAK file generated with SQL jobs for both the dynamics and company database. Reports.dic , Forms.dic and any other modified dic file for 3rd party apps. FRx Sysdata folder, integration manager IM.MDB file etc, etc. Ask for recommendations from a consultant that knows your system.
  5. Make sure backups are stored at a different location than the actual data. Main idea is to not store backups in a place where you will loose both backup and data if a server goes down. Often suggested to take/store backups off site.
  6. Restore backup to test company periodically to test backups are being created successfully. Also gives you a playground to test things on with recent data.
  7. If you are a user think about saving a backup of the reports.dic file, FRx tdb file (export of FRx reports), im.mdb file etc. on your local workstation after you make changes to reports. This will hopefully be another help in the event of lossed data.
  8. If something happens to your GP system (eg. server crashes) contact help immediately. Don't touch a thing and don't wait 3 days before requesting help.

Any other suggestion?

Stay In Touch

Sign up to stay up-to-date with the latest accounting regulations, best practices, industry news and technology insights to run your business.

Resources
Related News & Insights
IPO Prep & SOX Compliance: Instacart & Armanino Share Hard-Earned Knowledge
Webinar
Know your compliance requirements today to avoid obstacles tomorrow.

December 16, 2021 | 11:00 AM - 12:00 PM PT
General Contractor Trends to Consider in 2022 Webinar
Webinar
Hear from experts how you can better manage your subcontracts — and more.

December 16, 2021 | 10:00 AM - 11:00 AM PT
Why COP26 Matters for Your Business Webinar
Webinar
Get informed of COP26 developments and how you can act now.

December 15, 2021 | 10:30 AM - 11:00 AM PT