Your browser does not allow storing cookies. We recommend enabling them.

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]


 

 
What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.



    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH



    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now