HP 3000 Manuals

Silhouette Reference Manual

System Backup 

Silhouette allows backups of the entire database to be done on the
secondary system rather than on the primary system.  The primary system
continues updating its database while the secondary database is being
backed up.  Figure 3-3 shows the path the backup request takes when
preparing for a backup.


          Figure 3-3.  Preparing for Backup 

To begin a backup, the Silhouette Operator on the primary system issues a
backup request using the Silhouette Manager Program (MP):

     :RUN SILMP.PUB.SYS 
     >STATUS config 
     >BACKUP 

The MP is responsible for all command processing and is the only process
that allows the user to communicate with the Communication Process (CP).
This design isolates the CP from such tasks as waiting for terminal
input, recognizing commands, issuing error messages or providing help
displays and allows it to concentrate on data transport.

When a >BACKUP command is issued, the MP informs the CP which informs the
Secondary Communication Process (SP) which informs the Recovery Process
(RP). The RP acknowledges the backup request by changing its internal
backup marker from No to Pending.  The Silhouette Operator can then ask
for a status report via the MP process.  Using the same path, the message
travels to the RP on the secondary system and the Yes state returns via
the SP and CP to the MP as part of a status report.  The backup normally
cannot start immediately for reasons of transaction integrity in the
duplicate database.

Database transactions can be either single or multiple:

 *  Single transactions are complete in themselves.  Deleting a record
    from a dataset is an example of a single transaction since only one
    modification is made to the database.

 *  Multiple transactions involve several modifications to the database
    and cannot be interrupted without leaving the database in an
    inconsistent state.  Adding a sales record and updating a total sales
    counter is a multiple transaction since two modifications are made to
    the database.

If the database is backed up during a multiple transaction (for example,
after the sales record is updated, but before the total sales counter is
increased), then the backup database would be inconsistent with itself.
To avoid this problem, multiple transactions are indicated in the logfile
with BEGIN and END markers.  The RP process on the secondary system waits
until it finds a quiet period in the stream of records it is receiving
from the CP on the primary.  A quiet period means that all pending
multiple transactions have completed.  Figure 3-4 illustrates the
difference between a busy period and a quiet period.
________________________________________
|                                      |
|     .                                |
|     .                                |
|     .                                |
|     BEGIN1                           |
|     .  ADD1                          |
|     .  DEL1                          |
|     .    BEGIN2                      |
|     .    .  ADD2                     |
|     .    .  UPD2                     |
|     .  DEL1        <---  Busy Period |
|     .    .  DEL2                     |
|     .    END2                        |
|     .  ADD1                          |
|     END1                             |
|     DEL            <---  Quiet Period|
|     UPD                              |
|     .                                |
|     .                                |
|     .                                |
|                                      |
________________________________________

          Figure 3-4.  Multiple Transaction Markers 

If the RP allowed a backup during a busy period, then both multiple
transactions would be incomplete and the resulting backup database
inconsistent.  A backup taken during a quiet period would result in a
consistent backup since at this point all multiple transactions have
completed.  When the RP finds a quiet period, it changes its internal
marker from Yes to Now and releases the duplicate database and logfile
for backup.

When backup begins, the CP on the primary is notified that the RP will
not accept new records.  The CP monitors the accumulation of new records
in the logfile and, if necessary, requests they be stored to tape.

The CP resumes sending records when the Silhouette Operator issues a
>RESUME command which informs the CP that the backup is completed.  The
duplicate database on the secondary system is updated again by the RP and
all outstanding records in the primary logfile are processed against the
secondary logfile and database until they are synchronized with the
primary.  This update process occurs automatically at the Silhouette
system's normal high speed.  Depending on how long it takes to do the
backup, the Silhouette transport mechanism can have the secondary back in
step within minutes.

Backups, to be useful, must be performed at least once during each
logging cycle on the primary system.

MPE/iX 5.0 Documentation