Update logging and transaction logging enable the operating system to automatically track and record updates to items and files. Updates can be immediately written to backup medium as they are made. Update and transaction logging can be done on a system-wide basis, or either can be specified for selected files. No changes to any existing application programs need to be made.
In case of a system failure, update logging provides an up-to-the-minute backup of all files on the system, since all updates are captured in a recoverable format at the time the updates are made. If the entire database file system is specified for logging, the need for a nightly filesave or incremental save is less acute, since the transaction logging backup medium serves as the day’s backup. Daily filesaves are still recommended in order to cut down on recovery time and offline storage requirements.
All updates to a file are recorded, not just the final results. This means that accidental data loss due to operator or programming error, incorrect editing, etc., can be reversed by simply restoring such data to the state it was in before the unwanted change.
Update and transaction logging thus provide an automatic audit trail for any situation that requires the maintenance of complete audit histories.
The update logger records all of these updates:
Creation of new items
All changes made to any item
Deletion of items
Creation of new files or accounts
Deletion of files or accounts
Clearing of files
The update logger creates and queues update transactions, which contain enough information to allow the updates to be recreated or reprocessed with the transaction restoration processor. After the update transactions are queued, the transaction logger dequeues them and releases the unused resources back to the system in much the same way as the Spooler does.
|
NOTE |
The update logger does not record file updates caused by account-restores, nor does it record spooler print jobs. |
See Also