iBase backup policies

It is important to establish a backup policy that covers all the elements of an iBase installation.

Attention: Backup databases at a time when no users are using the database or services are accessing it, because some iBase operations can take place over a relatively long time and affect multiple database records. Examples of such operations are data imports, batch edit, batch delete, merge, or deletion of entities with many links. If the backup was performed during such an operation, and the database is subsequently restored from the backup, the restore operation restores data on which work was in progress at the time the backup was taken and is potentially in an incomplete state. It is safest if backups are completed while no users are performing operations on the database and no services are running.

Data to back up includes the following folders and databases:
Folders and databases Description
Database folder This folder contains, for example:
  • Security file (ids file) - this is a connection file if the security data is held in an SQL Server database
  • Database file (idb file) - this is a connection file if the data is held in an SQL Server database
  • Log file (idl file) for Microsoft™ Access databases only
  • Word search index (idx file) for Microsoft Access databases only
  • Default Analyst's Notebook template for use with iBase
All Users application data area

This folder contains, for example:

  • Database templates (although the installation can be customized so that workgroup templates are held in a different folder)
  • Icon lists
  • Text Chart templates
Note: Users do not write to this folder but to their own application data area. See Installation and Application Data Folders for details.
SQL Server databases SQL Server databases include, for example:
  • The SQL Server database that contains the entity and link data. The name is based on the name of the idb file in the database folder.
  • The SQL Server database that contains the security data if it is in SQL Server format. The database name is based on the name of the ids file in the database folder appended with _Sec.
Other For Microsoft Access databases, there might be separate folders for archive log files (.idla file).

For SQL Server databases, there might be separate databases that contain archived data. These databases are on a different SQL Server machine.
In addition to your regular backup cycle, there are other occasions when you should also make a backup. Some examples include:
  • Before you upsize a Microsoft Access database (or security file) to SQL Server
  • Before and after you import data using Bulk Import
  • Before you delete the records held in a case
  • Before you convert a database to case control
  • Before you use Update Database Schema
  • Before you synchronize a database subset with an iBase database in Microsoft Access format

Backing up SQL Server databases

SQL Server provides tools for performing the backups and automating them. However, other backup tools can be used if the right files are backed up at suitable intervals.

In an iBase SQL Server database, there are five types of data to back up:
Type of data Description
Main database For each iBase SQL Server database you must decide on your backup regime based on how you populate the main database:
  • Continuous updates

If the iBase database is populated by users that enter data continuously, then backing up the database is in two parts. You must back up the data file in which SQL Server keeps its data, and the file in which it keeps a log of all of the changes that are made to the database. This Transaction Log file can be used by SQL Server to recover changes made between main backups. The Transaction Log itself can be backed up during the working day.

  • Regular bulk updates

If the database is populated by periodically loading a set of data such as daily changes then, you can turn off the Transaction Log mechanism in SQL Server and you need only back up the data file in which SQL Server keeps its data.

Note: Significant data can also be held in database subsets on users' own machines.
Security database The security database stores user information and the group membership information for all the users in the system. Loss of this information can result in an inaccessible database until it is recreated and the user, group and extended access control information is rebuilt. After created, the information within the security database rarely changes, so backups of this database need only be completed when the information changes; for example, when alerting is switched on.
Audit data If the audit information is vital to your organization, for example you are using alerting, then in addition to doing backups of the main database and security database, you must to back up the audit log database and its Transaction Log file.
Connection files Connection files to the SQL Server security and main databases store only the configuration details that are required to log on to, and access the databases on the SQL Server. The loss of either of these files and the absence of a backup involves a complicated recovery process before users are able to gain access to the iBase database once more.
Report templates, database templates, icons These operating system files will either be stored in the same directory as the iBase database connection file or in a subfolder of the All Users application data area. All the files within these folders should be backed up to avoid unexpected behavior from iBase if they are inadvertently lost.
Archived audit data Audit information can be archived using iBase Audit Viewer to a separate SQL Server database on a different server machine (a linked server).
Search 360 indexes A separate database, IBaseIndexDB, contains configuration information used by the service that builds and updates Search 360 indexes. This may be on a separate machine used by iBase administrators. When you back up this database, you should also back up the configuration file, Searching Config.xml, in the All Users application data folder on the local machine, specifically: C:\Documents and Settings\All Users\Application Data\i2\i2 iBase <n>\<language>\Searching
Note: The backup must also include the files holding the search catalogs and indexes used by Full-Text Search. Backup and restoration of these files is separate from SQL Server backup and recovery, but you should coordinate any recovery process of databases and files to ensure synchronization.

For detailed information on backing up SQL Server databases, see the Microsoft SQL Server documentation.

Restoring SQL Server databases and security files

When you back up SQL Server databases, you must always back up the associated connection (.idb) files and, when you restore those databases, you must always restore the corresponding connection files.

This also applies to security (.ids) files which also have connection files if created in SQL Server format.