1117 Disaster Recovery with InterBase Bill Todd The Database Group, Inc.

Data Loss Physical loss Theft

Two Questions… How much data can you afford to lose? What disasters do you want to to protect against?

A Range of Answers You can lose one day of changes –Nightly backups are all you need You cannot lose any data, even if your building burns to the ground –You need real time backup to a remote location

Physical Security Most overlooked aspect of data protection Without it anyone can: –Spill coffee on the server –Kick the plug out of the wall –Knock the server off of a table –Take it home –Take the hard drive home –Delete the database

Log Off! Never leave the server unattended with a user logged on Anyone who gets access to the machine can add a new user to the Administrators group and access the server remotely

Attitude Without it every other aspect of your data protection plan will fail sooner or later –The DBA will run to the restroom without logging out –People who are supposed to change their passwords will use predictable ones that are easy to remember –People will write passwords down –People will give passwords over the phone

Reliability Use a dedicated database server –More software running on the DB server = more likely to crash –More software running on the DB server = more people who need access to the server

Access Only the DBA has login rights to the database server Do not share any drives or folders on the database server If you use a non-dedicated server: –Never allow access to the database or server software folders –Make everyone change their password monthly

Access Don’t run apps as SYSDBA Don’t run apps as the database owner Design your app so that you can easily change the account it runs under Anyone who can log in as SYSDBA or the database owner and has access to gbak can steal your data

Backups IBConsole –Uses services API Gbak –Services API –Local backup IBBackupService component –Uses services API

Backups All backups are full backups Backup using services API –Runs entirely on the server –Backup file must be on the server Backup using gbak –Backup across the network –Backup file can be placed anywhere

To Make Backup Fast Use the services API Place the backup file on a different hard drive than the database Disable garbage collection –If you want garbage collection run a sweep after the backup

gbak Command gbak -b -g -v -service localhost:service_mgr -user sysdba -password masterkey p:\employee.gdb p:\emp.gbk

gbak Backup Switches -bBackup the database -gNo garbage collection -vDisplay progress messages -serviceUse services API

Backup From Batch File gbak -b -g -v -service localhost:service_mgr -user sysdba -password masterkey p:\employee.gdb p:\emp.gbk 2> emplog.txt Note that gbak writes to stderr, thus the 2 in front of the redirection operator (>)

Sample Batch off echo Start================== >> emplog.txt gbak -b -g -service localhost:service_mgr -user sysdba -password masterkey p:\employee.gdb p:\emp.gbk 2>> emplog.txt date > emplog.txt time > emplog.txt echo End================== >> emplog.txt echo. >> emplog.txt

Backup Log Start===================================== The current date is: Sat 05/08/2004 Enter the new date: (mm-dd-yy) The current time is: 11:07:37.13 Enter the new time: End=======================================. Start===================================== The current date is: Sat 05/08/2004 Enter the new date: (mm-dd-yy) The current time is: 11:07:40.02 Enter the new time: End=======================================.

Windows Scheduler C:\> at 23:00 /every:m,t,w,th,f,s,su empbak.cmd To schedule the backup on another machine: C:\> at \\testserver 23:00 /every:m,t,w,th,f,s,su empbak.cmd You can also use the Scheduled Tasks applet in Control Panel

Making Backups Reliable Backup output must be reviewed daily Reviewer must sign a log book The reviewer must have a backup The log book must be signed by a manager weekly

Restoring a Backup IBConsole gbak IBRestoreService component Services API

Restoring with IBConsole From the menu choose Database | Maintenance | Backup/Restore | Restore

Database Restore Dialog

Caution Do not overwrite the exiting database –If the restore fails you have nothing –Restore to a different file name. If successful delete the old database and rename the file Does not work with multi-file databases –Copy the database file using O/S copy then restore with overwrite

Restore with gbak gbak -r -p service localhost:service_mgr -user sysdba -password masterkey p:\employee.gbk p:\employee.gdb

Restore with gbak Do not use the –validate option It will slow the restore dramatically It may cause the restore to fail No validation is the default in 7.1 Before 7.1 you cannot disable validation

O/S Backups Backup the gbak backup file, not the database file –File may not be backup up if in use –File may be corrupt if backed up If you must backup the database file with an O/S backup or copy program stop the IB server service first

Forced Writes Always run with forced writes on unless performance is unacceptable If you must run with forced writes off use a dedicated server with a UPS and a stable operating system Be aware that a server crash may corrupt the database because everything in the write cache will be lost

Backup Strategies Backup at least once per day Store backup files on a different machine Store backup files off site Review backup output after every backup

Checking for Corruption Use gfix gfix -validate -full -no_update -user sysdba -password masterkey employee.gdb

Repairing Database with gfix gfix -validate -full -user sysdba - password masterkey employee.gdb -validate checks database structure -full validates records –Takes longer –More thorough

Database Still Corrupt Records could not be repaired Use –mend then backup & restore gfix -validate -full -mend -user sysdba -password masterkey employee.gdb

Repairing with IBConsole IBConsole does not offer all of the options available with gfix Choose Database | Maintenance | Validate from the menu

Database Validation Dialog

Hard Drive Failure Maintain a live copy of the database on another drive –InterBase Shadowing –Operating system disk shadowing –RAID drive array

InterBase Shadowing Maintains two copies of the database simultaneously on two drives Drive configuration –Drive 1 = operating system –Drive 2 = the database –Drive 3 = the shadow Alternative drive configuration –Drive 1 = O/S & database –Drive 2 = the shadow

InterBase Shadowing + Provides fast recovery if database drive fails - Shadow must be on a local drive - Software failure will corrupt shadow - No point-in-time recovery

InterBase Shadowing Create with CREATE SHADOW Activate shadow with gfix gfix -activate employee.shd -user sysdba -password masterkey

RAID Redundant Array of Inexpensive Disks 10 types Only four are readily available

RAID 0 Provides improved performance but no fault tolerance Of no value in protecting your data

RAID 1 Mirroring Provides 100% data redundancy Reboot is required if a drive fails

RAID 5 Striping plus Error Correction Code (ECC) Fast reads, fast writes and fault tolerance Supports hot swappable disks

RAID 10 RAID 1 + RAID 0 Combines striping for high performance with mirroring for fault tolerance Best combination of performance and fault tolerance for databases

Replication + Backup database can be on another machine on your network, even in another location - Replicated DB is behind the master - Imposes additional load on server - Replicator may fall behind if load is heavy - A network failure will stop replication

Recovery Logging Record all changes since last full backup in a separate file To recover the database: –Restore from last full backup –Apply changes in recovery log + Provides point-in-time recovery InterBase does not provide recovery logging

Implementing Recovery Logging Logging must be under transaction control It is impossible to write to an external file under transaction control You must log to a database table Logging to a table within the database defeats the purpose of logging since the log will be lost with the database

A Hybrid Approach Log to the database using triggers to write to the log table Copy the logged information to an external file as soon as possible after the transaction commits

A Hybrid Approach Use IB database for external file –Logger can use two phase commit transaction to insert info into log database and delete from log table –Log database can be on another machine

Triggering Log Copying Use an after insert trigger on the log table to post an event to the log client –+ Very little delay between change and logging –- High load on a busy database Trigger logging at a preset interval –+ Lower load on server –- Log will be further behind database

Log Table Structure One log table for each database table –Same structure as data table –Generated primary key –Column to indicate insert, update or delete - Great care required to process log data in an order that does not violate referential integrity

Log Table Structure All changes for all tables recorded in two log tables Log Master Structure –Sequence_Number –Table_Name –Action (insert, update, delete) –Where_Clause

Log Table Structure Log Detail Structure –Detail_Number –Sequence_Number (foreign key) –Column_Name –Type_Code Integer number of column containing value –Value columns One column for each data type

Two Table Log Log master gets one row for each insert, update or delete Log detail table gets one row for each non-null column in each insert or update This approach solves the RI sequencing problem This structure was first suggested by Dalton Calford in his paper “Some Solutions to Old Problems”

Recovering Using the Log Edit the log tables if necessary Restore from last full backup Run recovery program –Generate SQL statements from log –Execute statements

Questions?

Thank You Please fill out the speaker evaluation You can contact me further at …