Database Backup and recovery CSD305 Advanced Databases

Agenda Why recover? Simple backup strategy Why we need a better strategy Static checkpoints The Log file Rolling back a transaction Rolling back multiple transactions Journals and the Archiver process Rolling forward Summary CSD305 Advanced Databases

Why recover? Transaction level problems System level problem program failure user abandons processing client becomes disconnected System level problem database server failure power failure Really nasty problems physical disk damage database inconsistencies that aren’t detected immediately CSD305 Advanced Databases

Simple backup strategy backup process find quiet point in database activity close down the database copy the database files to another device preferably to a medium you can store in a fire safe restart the database in case of failure copy the database files back restart the database server cycle your backup media to keep multiple backup versions CSD305 Advanced Databases

Why we need a better strategy we can only recover to the last backup database don’t always have quiet points we’re relying on the OS file system for security database system is an integrated collection of data (files aren’t) A better strategy will allow the DBMS to co-ordinate backup and recovery allow backups to be taken at any time recover from any individual transactions which fail recover to any moment in time CSD305 Advanced Databases

Static checkpoints A checkpoint is a static snapshot of your database It’s controlled by database server processes It will wait for transactions to complete to establish a quiet point Multiple versions are catered for Checkpoint files should be stored on a different device from database files ROLLFORWARDDB will restore the database to the last checkpoint state CSD305 Advanced Databases

The Log File a log file is used to record the effects of update transactions a single system-wide file controlled by the run-time DBMS the file contains a collection of before-images and after-images that can be used to aid recovery the log file is periodically inspected by an archiver process that: removes records relating to committed transactions transfers after-images to journal file if required CSD305 Advanced Databases

Log file example CSD305 Advanced Databases

Rolling back a transaction If a program fails or a user aborts a transaction: the before-images in the log file are used to “undo” the effects of the transaction inserted records are deleted updates are undone deleted records are reinstated CSD305 Advanced Databases

Rolling back multiple transactions In the case of a system failure (e.g. powercut) where no damage has been done to persistent data: the log file is used to “undo” all uncommitted transactions CSD305 Advanced Databases

Journals and the Archiver process The Archiver process removes completed transactions from the log file If journaling is switched on for a database a journal file will be created for the database log entries will be copied to the journal before deletion from the log file CSD305 Advanced Databases

Rolling forward With journals in place the database can be recovered to its last consistent state ROLLFORWARDDB recovers the database by: restoring the database from the last checkpoint applying the journal records to the database CSD305 Advanced Databases

Summary Database systems provide sophisticated facilities to enable recovery from failure These facilities require careful management within a well-planned recovery strategy Systems differ in their recovery requirements. The Database Administrator must decide: how often to take checkpoints whether journaling is required what devices are used for recovery where media are stored and when they are re-used how often databases are checked for internal consistency and much more ... CSD305 Advanced Databases