Database Backup Policy – EPrints and DSpace

We have 2 types of Database backup services. By default, we will backup the database at local daily and keep the latest records and remove the old records.

Plus, we will setup the configuration of master-slave configuration for the database, the main database will be synchronized to the slave database. If the master database encounter problem, the slave database will be configured as master database to replace the previous one and continue to provide service. It provides near real-time synchronization.

You also can choose the database cluster methodology. We will create a cluster of databases and it will sync the data each and other in real-timeno data will be lost. However more database servers will be adopted. It will be the HA for databases.

Database Master-Slave Replication technique

After adopting this technique, the master database of Koha will be synchronized to slave database (at another server). The purpose of using this policy is to achieve the zero data loss for Koha application, to ensure the business continuity of the library services. The Recovery Time Objective (RTO) to restore the database is 8 hours and the Recovery Point Objective (RPO) is less than 5 minutes as the slave database is synchronized in real-time.

Database Cluster (Master-master)

We will setup the database cluster by a group of database servers. A database load balancer will be used to connect to the database of the system. The business is still continue to provide service even though one of the database servers is down. Bear in mind terms and conditions must be applied.


Usage target for synchronous in Koha DB include: –

Data security — as data is replicated to the slave, and the slave can pause the replication process, it is possible to run backup services on the slave without corrupting the corresponding master data.

Analytics — live data can be created on the master, while the analysis of the information can take place on the slave without affecting the performance of the master.

Long-distance data distribution — if a branch office would like to work with a copy of Koha main data, we can use replication to create a local copy of the data for their use without requiring permanent access to the master.


Let’s examine a few examples on how we can use such replication and take advantage of it: –

Backups: to use replication as a backup solution, replicate data from the master to a slave, and then back up the data slave. The slave can be paused and shut down without affecting the running operation of the master, so we can produce an effective snapshot of “live” data that would otherwise require the master to be shut down.

Failover alleviating: We will set up a master and a slave. A monitoring script is written to monitor the master performance to check whether it is up. If master is failed, then we could switch the slave to master and recover the “old master” as slave, to switch both roles; then the library service could continue and has zero data loss.

Please contact to us if you need any assistance on this service,