Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

PreviousNextUp[Front page] [Index]

Sample Backup Plan

In this example, we examine a situation where the system is secured not only against local, limited hardware failure, such as single malfunctioning hard disk, but also against total loss of the active database machine including its database.

   Machine A:                                Machine B:
     Disk 1:            <--------------->      Live backup:
       certifier.db                              transaction.log
       transaction.log                        
     Disk 2:            <--------------->      Full backup:
       mirror.log                                certifier.db

On the main, active machine (A) we have the database server running as a part of full SSH Tectia Certifier installation. It has two separate disks (1 and 2) and it uses transaction log mirror. Spare machine (B) continuously runs live backup process which maintains almost up-to-date transaction log copy on that machine. Machine B also runs remote full backups periodically in which the database file (certifier.db) is copied to the remote machine and all three transactions logs are also truncated. Machine B does not contain a running SSH Tectia Certifier installation, although it can contain a pre-installed system to help in the recovery process. Only thing it requires is a working dbbackup application for the backup process.

Full backup frequency mainly affects transaction log sizes. In an installation with relatively low usage a full backup once per week (or even once per month) is enough. However if transactions logs grow too large a more frequent backups are necessary.

In this configuration the following failure cases are handled:

  • Case 1: Disk 2 on machine A fails
    • Just restart the database and it will automatically copy the main transaction.log to mirror.log before starting.
  • Case 2: Disk 1 on machine A fails
    1. Copy certifier.db from most recent backup to machine A.
    2. Apply the mirror.log to certifier.db.
    3. Restart the system.
  • Case 3: Machine A is totally destroyed (in a fire for example)
    1. Copy certifier.db from the most recent backup to new machine A.
    2. Apply the transaction.log from live backup to certifier.db.
    3. Restart the system.

Note that in case 3 some committed transactions can be lost. In cases 1 and 2 the recovery is always complete.

No special backup processes are needed on machine A. In machine B the full backup can be arranged with either of backup scripts in Section Setting up Backup Procedure which can be run a cron jobs. Connection strings must be customized to include the address of the database server as is done in live backup script.

Live backup can be started with script in Section Remote Live Backup but some care must be taken to ensure that if the database is ever shut down, either deliberately or by some real failure, the live backup process must be restarted. One way is to add another script which will monitor the live backup process and restart it automatically. In such case, some additional care must be taken to ensure that the old transaction log is not overwritten.


PreviousNextUp[Front page] [Index]

===AUTO_SCHEMA_MARKUP===