Ketura stores all of its information in a database. It is essential that this database is backed-up regularly, to ensure that you will be able to recover your data in the event of, for example, a hard disk failure or the inadvertent deletion of important information.
Araxis therefore recommends that you back up your system to another machine (preferably at a different physical site) at least once every day. It is usually most convenient if backups occur at night (when the system is not being heavily used), although they can be performed at any time.
To backup your Ketura database:
-
Create a backup snapshot of the current Ketura database to a file on the server’s hard disk. Ketura has a built-in mechanism to create such backups (accessible from the global System tab). For more information, see the help for the Manage Database Page.
-
Copy that database backup file to removable media, or via your network to a remote location. You can do this as you would for any other file on your computer system. It is important that you backup to removable media or a remote location (and not, for example, to a second, internal, hard disk) as some backups should regularly be stored off-site in case of theft, fire, or other damage to the server computer. Araxis suggests that you store a backup off-site every day. At a minimum, you should store a backup off-site at least once a week.
Backing up directly to a shared network volume
It is possible to have Ketura create its database backup snapshots on a shared volume on the local network, rather than to the local drive of the Ketura server itself. This protects against certain failures (for example, that of a hard disk in the server machine), but does not protect against disasters that affect both the Ketura server and the server providing the network volume. Off-site backups are therefore still required.
On Windows, the Ketura server runs as the ‘Local System’ user. It is not therefore able to use any network drive-letter mappings
that you create under a normal user account. Thus, if you wish Ketura to create its backup snapshots to a network volume,
specify the backup directory in Ketura using a UNC path (e.g. \\myserver\sharename\somedirectory) rather than as a mapped drive letter (i.e. not F:\somedirectory). For this to work, the network share on the server must give the ‘Local System’ user on the Ketura server machine the ability
to read and write to the share. The easiest way to do this is to grant read and write access to the share for everyone, but
that is not ideal unless the local network is secure.
Verifying your Ketura back-ups
Daily checks
Assuming you are using the in-built backup mechanism to backup your Ketura database, you should:
-
Check the Ketura Audit Trail (accessible from the global System tab) for Database Backup Successful and Database Backup Failed events. If you find a Database Backup Failed, you should investigate the cause of the problem. One way to do this is to initiate a backup manually, and see whether Ketura reports any errors to you. The most likely reason for a backup failure is a hard disk with insufficient free space.
-
Verify that the most recent backup file is present in the expected location.
Weekly checks
Because the data that you store in Ketura is so important, it is strongly suggested that you regularly take steps to verify the backups that you make. The easiest way to do this is temporarily to install Ketura on a second machine, restore your latest Ketura database backup, then manually browse the restored system to ensure that everything appears as you would expect.
About the Ketura backup file format
To ensure that the data stored in Ketura is readily accessible, the Ketura backup file format is simply a standard Zip file. This contains a number of xml files (representing the tables in Ketura’s database) and .dat files (one for each issue attachment).
If your Ketura system uses a Microsoft SQL Server database
You can continue to use Ketura’s built-in backup mechanism, even if you are using Microsoft SQL Server as your database management
system. However, this might be quite inefficient, particularly if the SQL Server database is located on a different machine
from Ketura. You might therefore wish to use SQL Server’s native backup facilities instead (or, possibly, as well). If you
are not already familiar with how to design a backup and restore strategy and how to manage backups, please see the Microsoft
SQL Server topic Backing Up and Restoring Databases 
for more information.