Do You Have Confidence in Your Backups?

Do You Have Confidence in Your Backups?

Everyone knows that backups are important, but too often they aren’t taken seriously until after a disaster occurs. It’s important to consider your backup strategy. By this we mean, to know what options are available to you, to choose a backup strategy based on what data loss you would accept, to know that it is running and to do test restores.

Currently, most NAV users are using a SQL database rather than the proprietary database format and in our experience most users of the latter run manual backups through the client. As this is a manual process, it is open to user error, either in the form of not backing up the correct data or failing to back it up at all!

By running SQL backups you can benefit from the fact that they are automated, as well as the following other advantages:

Log Files

In my experience one of the biggest advantages to SQL backups over NAV backups is the ability to restore to a specific point in time, often the second before disaster struck. SQL achieves this by keeping a log file. This is a record of all changes to the database since the last full backup which can be reapplied to a restored database. However, this is only available if you use the full database recovery model. The simple database recovery model is not a good choice for a NAV database. If you are having trouble with log files growing too big, fix your backup strategy, don’t just turn on the simple recovery model.

Drive Failure

The log files should always be on a separate disk to your database file. This means should the database files be lost to a drive failure you can restore the database to the state it was in at that moment.

Accidental Data Deletion

Sometimes users modify or delete large batches of data, but only realise what they’ve done after the event. The log file allows you to restore the database to a point before the mistake was made.

Log Backups

In the worst case scenario, you could lose both the data files and the log files. You can prepare for this eventuality by running log backups during the day, for example every hour. As they are only recording changes over a small period, log files are a lot smaller than the data files, so SQL can back them up whilst you work with no noticeable drop in performance.

Notification of Backup Success or Failure

It’s all very well automating backups, but it’s important to know they are still happening and failures are not going unnoticed. With SQL it’s easy to setup email notifications of a backup success or failure.

Test Restores

Having a file that appears to be a backup is a good start, but without knowing you can restore it there’s still some way to go. Without doing test restores there is a risk that your backup could be corrupt or could be the wrong file. Loosing many months of data is not a good way to find out you’ve been backing up your test database for the last few years…

Conclusion

With SQL server available as an option to all NAV users, there is no reason to be risking even a day’s worth of data when you could be running a SQL database. If

you are running a proprietary database and would like to take advantage of SQL server, or
are using SQL server but are not sure your data is as safe as it could be,
let us know and we can carry out a review of your current server installation and backup strategy and advise you how you could save yourself a lot of work should the unthinkable happen.

David Curd

Before joining Dynamics Consultants, David worked in a support role for a company that supplies back office and point-of-sale (POS) software to retailers. Dave’s role in the company is resolve more difficult customer issues and oversee infrastructure work.