A well-designed database application is of no use if data and the application are not available 100% of the time. Data loss and corruption are not common in most systems, but occasional occurrences are unavoidable. Some of the events that can cause data loss include the following:

Because events such as these can happen anywhere, at any time, you should take the time now to plan how to handle a possible future data loss. Your plan should include a policy regarding the intervals at which you check the integrity of your database.

Another situation that may arise is when power failures or processing interruptions occur while data is being processed and/or committed. In these cases, ZimServer is perfectly capable of resolving the situation the next time it is restarted by applying previously unresolved commits to the database by means of the recorded modifications made to the database in a common transaction file. If transactions could not successfully end for any reason, these transaction records are ignored.

Among other practices, there are two common actions to be taken to guarantee data security:

Using ZimBackup and ZimServer to Make Online Backups

Zim:X provides the ability to perform online data commits in backup databases as soon as data is committed by ZimServer in the active databases. The backup databases can reside anywhere in the world, typically in different machines and/or different physical locations in relation to the active databases. Both ZimServer and ZimBackup need to be properly configured but this process takes only a few minutes to be performed.

a) Stop ZimServer

If ZimServer is currently running, stop it gracefully by means of the “-k” option. This guarantees that the databases under its control are in a valid state.

b) Stop ZimBackup

Make sure that Zimbackup is not running by stopping with the means of the “-k” option. This guarantees that the databases under its control are in a valid state.

c) Copy all databases involved in the backup operation

Make a copy of all databases under ZimServer control, the one that just has been stopped. This copy will not only save all databases but also create a replicate of the databases to be involved in the backup operation. In essence, the backup will start with the current valid state of the databases.

d) Change the server database configuration file “zimdb.zim”

Assuming that there are two Zim databases being serviced by ZimServer but only one needs to be backed up, you just need to add the keyword “backup” after the proper entry (in this case, only MyBase will be backed up):

10;MyBase;c:/mybase/;backup;
20;Example;c:/otherexample;

e) Change the server configuration file “zimconfig.srv”

The following lines in this configuration file should be changed:

audit path <a file directory>
backup path <another file directory>
backup port number <a port number, usually 6001>
backup server name <an ip address>

The audit path option tells where ZimServer should place the uncommitted data files. For safety reasons, it should point to some hardware different from the current serviced databases in order to preserve the commits in case of any failures. If not provided, it defaults to the current Zim installation.

The backup path option tells where ZimServer should place a compressed format of all committed data files ready to be sent to ZimBackup. For safety reasons, it should point to some hardware different from the current serviced databases and from the place pointed by the audit path so that the backed-up databases would preserve their integrity.

The backup port number and the backup server name are the TCP/IP identification where ZimBackup is operating to perform the backups.

f) Change the backup database configuration file “zimbk.zim”

In the environment where ZimBackup is going to run, change the “zimbk.zim” to provide the databases that are going to be backed up. Using the example above, only one reference to a database needed to be provided:

10;MyBase;c:\mybackupbase;

g) Change the backup configuration file “zimconfig.bkp”

In the environment where ZimBackup is going to run, change the following lines:

destination directory <temporary file directory>
backup port number <a port number, usually 6001>

The destination directory is a temporary location in the backup server environment to hold the backup files to be applied to the backup databases. After the corresponding application, these files are erased.

The backup port number is the same TCP/IP port used by ZimServer to “talk” to ZimBackup.

h) Copy the databases from the server to the backup place

Copy the databases that were saved in Step C to their proper places as described in “zimbk.zim”. In the above example, you should copy the contents saved from “c:/mybase” to “C:/MyBackupBase”.

i) Start ZimServer

All set, you can now start ZimServer.

j) Start ZimBackup

All set, you can now start ZimBackup. In fact, starting ZimServer before or after ZimBackup does not make a difference because when it’s time to back up data, one server waits for the other.

General guidelines to keep a database running can comprise:

• Using Zim 9 Backup Server, implement safe procedures to backup databases and to restore databases if they become unavailable;
• How to maintain the integrity of your database.