Utility to restore backups

Bug #362001 reported by Jon Tai
2
Affects Status Importance Assigned to Milestone
OpenVista/GT.M Integration
Fix Released
High
Jon Tai

Bug Description

We need a utility, ovrestore, that will restore a backup produced by ovbackup. After restoring the database files and routines, ovrestore should compile all the routines and optionally apply journal entries.

Here's a mockup of the usage:

$ ovrestore -h
Usage: ovrestore [-y] [-j JOURNAL_DIRECTORY | -k] [-f] INSTANCE_NAME BACKUP_FILE
   or ovrestore -h

  -y overwrite routines, database files, and journals without asking for
      confirmation
  -j after restoring the backup, apply journals from JOURNAL_DIRECTORY
  -k only restore the routines and database files; do not remove journals
      and do not re-enable journaling on the new database file
  -f if any processes are accessing the database, kill those processes
      instead of aborting the restore
  -h display this help text

Jon Tai (jontai)
Changed in openvista-gtm-integration:
importance: Undecided → High
milestone: none → phase-1
status: New → In Progress
assignee: nobody → jontai
Revision history for this message
Jon Tai (jontai) wrote :

Ready for mainline

Changed in openvista-gtm-integration:
status: In Progress → Fix Committed
Revision history for this message
Jon Tai (jontai) wrote :

So as it turns out, you can restore an instance's backup to another instance, i.e., you can load a backup of production into the training instance, but journal files appear to have the path of the database file embedded inside them, so you can't apply production's journals into the training instance. (At least, not easily...) This means we can get rid of a lot of fancy logic trying to detect and handle this case. And -j doesn't need an argument anymore.

Also, since old journal files are timestamped, the default behavior does not need to be "remove existing journals". We just need to shut off journaling and move the current journal file out of the way.

Here's the final usage, as of rev 81, when I proposed merging this into mainline:

Usage: ovrestore [-y] [-q] [-j] [-f] INSTANCE_NAME BACKUP_FILE
   or ovrestore -h

  -y do not ask for confirmation
  -q quiet; suppress status messages
  -j after restoring the backup, apply journal entries
  -f force; kill any processes accessing the database before restore
  -h display this help text

Revision history for this message
Jon Tai (jontai) wrote :

Here's an example of "disaster recovery":

[jon@avgtmint02 ~]$ sudo ovinstanceadd test
[jon@avgtmint02 ~]$ openvista test

TEST>S ^JON=""

TEST>S ^JON(0)="This should be in the backup"

TEST>h
[jon@avgtmint02 ~]$ ovbackup -q test
[jon@avgtmint02 ~]$ openvista test

TEST>S ^JON(1)="This should only be in the journals"

TEST>h
[jon@avgtmint02 ~]$ sudo rm /opt/openvista/test/globals/default.dat
[jon@avgtmint02 ~]$ openvista test

TEST>ZWR ^JON
%GTM-E-DBFILERR, Error with database file /opt/openvista/test/globals/default.dat
%SYSTEM-E-ENO2, No such file or directory

TEST>h
[jon@avgtmint02 ~]$ sudo ovrestore -j test /opt/openvista/test/backups/test-20090416-220704.tar.bz2
Routines and database files in 'test' will be OVERWRITTEN with
the versions in '/opt/openvista/test/backups/test-20090416-220704.tar.bz2'

Are you sure you want to restore this backup to 'test' (yes/no)? yes

Apr 16 22:07:57 - Starting restore of /opt/openvista/test/backups/test-20090416-220704.tar.bz2 to test
Apr 16 22:07:57 - Extracting contents of backup file
Apr 16 22:07:57 - Attempting to acquire exclusive access to database
Apr 16 22:07:57 - Restoring routines
Apr 16 22:07:57 - Restoring database files
Apr 16 22:07:57 - Applying journal entries
Apr 16 22:07:57 - Enabling journaling on new database
Apr 16 22:07:57 - Finished restoring /opt/openvista/test/backups/test-20090416-220704.tar.bz2 to test
[jon@avgtmint02 ~]$ openvista test

TEST>ZWR ^JON
^JON=""
^JON(0)="This should be in the backup"
^JON(1)="This should only be in the journals"

TEST>h

Jon Tai (jontai)
Changed in openvista-gtm-integration:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.