Search for answers or browse our knowledge base.
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:
|User error||Individual records, or even entire files, can be erased by accident or with malicious intent|
|Hardware failure||Data can be lost if a disk suddenly becomes unreadable for some reason.|
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:
|Copy your databases at regular intervals||At specific times (usually overnight), your system is shut down (unavailable to users) and a physical copy of the databases is made. Data is guaranteed to be safe within a 24-hour span only. Data updates during this interval are probably going to be lost. The application system’s ability to come back online may vary from minutes to hours depending on the size of the database.|
|Online backup||Data is constantly backed up as soon as there is a commit to the data. Data loss is up to only a few seconds, if such, the application system may come back online as soon as users are routed to the backup computer.|
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.
If you have any “areas.zim” files, you will have to copy the corresponding files addressed by this configuration file to the proper database path.
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):
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:
The database number (10, in this case) and the database name (MyBase) MUST be the same as used in “zimdb.zim” for ZimServer. However, the destination directory does not need to be the same.
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”.
Although Windows and Linux may be incompatible in many ways, it is perfectly possible to have ZimServer running on Windows and ZimBackup running on Linux (or vice-versa) because ZimBackup does not deal with the data within the database. However, before using the backed-up database, you will need to copy it to the original machine.
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.
If you run any Zim statements changing data under the setting
SET CHECKPOINT OFF
all data changed in this way will NOT be backed up because this setting tells ZimServer to operate in single-user mode, that is, there are no transactions involved and there are no transactions to be committed.
This setting is used to add data offline in bulk to avoid memory limitations which significantly increases the speed of the operation. However, in case of any failures, the database involved may be rendered corrupt and an off-line backup should be used to recover the database.
General guidelines to keep a database running can comprise: