Backing up SQL Server databases

SQL Server provides tools for performing and automating backups of your iBase databases. You can also use any third-party backup tools that you're familiar with. The important thing is that you back up the right files at suitable intervals.

In an iBase SQL Server database, there are several types of data that you need to back up:

Main database

A main SQL Server database is one that contains iBase entity and link data. Its name is based on the name of the .idb file in the database folder.

For each main database, you must decide on your backup regime depending on how you populate it:

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. SQL Server can use this Transaction Log file 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. You need only to 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 workstations.

Security database

If you have upsized any of your main databases' security files to SQL Server, then each one has a corresponding security database. Its name is based on the name of the .ids file in the database folder, appended with _Sec.

The security database stores user information and 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 creation, the information within the security database rarely changes, so you only need to make backups when changes take place - if you switch alerting on, for example.

Audit data

If audit information is vital to your organization - if you are using alerting, for example - then in addition to backing up the main database and the security database, you must also back up the audit log database and its Transaction Log file.

You can use iBase Audit Viewer to archive audit information to a separate SQL Server database on a different ("linked") server.

Connection files

Connection files to main and security iBase databases in SQL Server store only the configuration details for logging into and accessing the databases. The loss of either of these files and the absence of a backup can involve complicated recovery process before users are able to gain access to the iBase database again.

Report templates, database templates, icons

iBase stores its template and icon files in the Program Files\i2 iBase <n>\Resources folder. You should back up all these files to avoid unexpected behavior from iBase if they are inadvertently lost.

Search 360 indexes

A separate SQL Server database, IBaseIndexDB, contains configuration information for the service that builds and updates Search 360 indexes. This database might be on a separate server.

When you back up this database, you should also back up the configuration file, Searching Config.xml, in the data folder on the local machine - specifically, C:\ProgramData\i2\i2 iBase\<language>.

Note: The backup must also include the files that hold the search catalogs and indexes that Full-Text Search uses. Backing up and restoring 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.