iBase backup policies
It is important to establish a backup policy that covers all the elements of an iBase installation.
|Folders and databases
|This folder contains, for
|All Users application data area
This folder contains, for example:
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:
|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.
- 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.
|Type of data
| For each iBase SQL Server database you must decide on your backup regime based on how you
populate the main database:
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.
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.
|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.
|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 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
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.