sleuth Backups

sleuth is a multi-user application that contains a huge amount of critical data so regular backups are an essential part of any sleuth installation. Successful backups involve two distinct steps: backing up the data to your chosen backup media (tape, disk, CD etc.) and performing a test restore to verify the backup. A backup can really only be declared successful when it has been successfully verified. It is therefore good practice to test the restoration of a database at regular intervals whenever possible.

What to Backup

The sleuth application has two main components: the client application and the central database. The client application is located on each PC that uses sleuth and is named sleuthappl.mde. It is usually located in "c:\program files\sleuth" and contains no school or incident data. This part of the application does not require any backups as it can easily be reinstalled from the installation CD if necessary.

The central sleuth database is usually named sleuthdata.mdb and contains all sleuth data including incidents, students, staff and administrative set-up information. There is only one copy of this file and when sleuth is installed as a multi-user application this should be located on a network fileserver that is backed up on a regular basis. If your sleuth installation is single user, where the database (sleuthdata.mdb) is located on your local PC, we recommend that you regularly copy this file to a location that is subject to a backup routine.

Backup Issues

• The sleuth database (sleuthdata.mdb) is a Microsoft Access database file. If your backup strategy involves copying the database file (either manually or automated) then it is imperative that the file is not in use when the copy is made. When copying a file that is in use it is entirely possible that the copy process will appear to have been successful but because changes may have been made during the copy the backup file can become corrupt. Verifying the backup copy is correct is therefore good practice.
• It is possible that the sleuth database (sleuthdata.mdb) will be skipped during an automated backup if the file is in use. The file should be successfully backed up if the backup occurs outside normal working hours and all users have logged out. If the file is skipped during the backup, the backup log should reflect this, so it is worth checking this.
• It is common practise to keep a number of previous backups, rather than to overwrite each backup with the next. An example would be the use of a set of five backup tapes labelled Monday to Friday. This would ensure that at any given time a number of backups are available, in case of problems with the backup process such as tape failure.

Test Restores

Test restorations must be performed with great care - obviously you don't want to accidentally overwrite your live database with a previous backup! The restore should ideally be performed on a standalone machine where there is no danger of anyone accidentally connecting to the restored data, but any area well away from the live database location will be fine. Once the database file has been restored you should rename the file to reflect that it has been restored (e.g. sleuthdataRESTORED.mdb) and connect to it using sleuth to ensure that it functions as expected.

To connect to a restored database run sleuth, but do not log in. From the Login screen, select 'Help-About' from the menu and press the 'Relink to Database' button, which will prompt for the location of the database. Navigate to the location of the restored database and select the restored file. If connection is successful, log in and check that it functions as expected. If the machine you use to test the restore is usually connected to the live database be sure to relink to the live database following the same procedure. The 'Help-About' screen shows the location of the connected database so you can check that you are connected to the appropriate database.

^{about us | sleuth | services | news | support} \ _{forum | backups | documentation downloads}