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
     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]


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more