Several times a year we get a call from a user in full-on panic mode because a hard drive on their town’s server has crashed and no one seems to be able to locate a recent backup of their system’s data.  While we generally configure automated backups on the server when we install, without routine maintenance it’s difficult to ensure that these will remain a viable resource in the event a restore is needed.  Scripted tasks can stop working if someone changes passwords, directories can get moved or renamed, old tapes can fail — there are any number of reasons why the backups you think you have may not actually exist when you need them.  Fortunately, regardless of the Avitar application(s) you use, there is a simple process by which you the user can ensure you always have a recent system backup in the event of a catastrophic failure on the server.  It is impossible to overstate the value of you the user taking control of your own backup procedures by following these simple steps.

First a little background….  In most municipalities the system data resides on a central server and the application (be it Assessing, Tax Collect, Clerk, Building Permit, and/or Utility Billing) is installed locally on your workstation.  Due to the nature of the SQL Server database platform which maintains your application data, system data files are often in use by the database platform even when no one is logged in to the program.  Which means many basic backup methods are unable to backup system data as if they were a simple word processing file or spreadsheet.

We overcome this problem by configuring the Avitar DBUtils application, in conjunction with basic Windows scheduled tasks on your server, to periodically spit out scheduled backups to another location on the server.  Which then allows most backup methods to backup the backup file, so to speak, as opposed to the data files themselves.  Problem solved.  So then what’s the issue?  Over time, changes made on the server can render these methods ineffective.  For example, if the password for the user under which the scheduled task runs is changed, the scheduled task will no longer run.  Or if the directory to which the scheduled backup was pointed is deleted or renamed or not included in the nightly backup the scheduled task will be of no use. The result is that the user is left believing the system’s data is being backed up when in fact it is not.  And you’ll never know until you need it.

Fortunately, we provide another method within each application whereby the user can generate a backup from the server and copy it to the local workstation.  From there it can either remain on the local workstation or be copied to an external drive, either of which can be used in the event of a hard drive crash on the server.

If none of this makes sense to you, here’s what you need to understand: unless you’re periodically making your own backup there’s a possibility you may find yourself redoing work.  After a recent hard drive crash one tax collector had no recourse but to re-enter a month’s worth of transactions.

To avoid this, we recommend that you take just a few minutes out of your day or week (depending on how frequently you add or update data) to create a backup of your database.  To do so, make sure you’re logged in to the program and navigate to File | Backup Database. Select the browse button (“…”) and choose the local Backup Destination. Once you have made the selection, click Backup Data.

If the menu item is not enabled, or the backup process fails, it indicates that the backup settings have not been configured correctly for your system. You can find more information on how to configure backups here.  Or call us for assistance.  It’s a simple thing to do that, regardless of the backups that may or may not be getting created on your server, can provide an invaluable safety net in the event of a catastrophic failure on your server.