MYOB Greentree

HideShow

  • Contents
  • Index
  • Search
 
Display results with all search words

 

Restoring a Database from Backup


If there is a live database failure, you must restore Greentree Desktop from the latest backup.

You can use the jdbutil.exe form to start the restore operation. The only exception to this is in the case if the preferred backup method is a manual offline backup. In this case, the database is restored by replacing the live \system and \bin directories with the backed up \system and \bin directories. You must delete the live \system and \bin directories before replacing them with the back up directories.

The jdbutil.exe form provides two options for restoring from a backup:

  1. Restore and Roll Forward
  2. Restore with No Recovery

Use the Restore and Roll Forward option if the Archival recovery option is in use, otherwise use Restore with No Recovery.

Select Restore with No Recovery on the Restore Database form.

Click OK. The backupinfo file is checked with the backed-up database files before the restoration.

When the restore is activated, each file being restored displays in a running report to the form. The process involves copying backed up system files into the specified directory. You can abort the run anytime by clicking the Cancel button.

Make sure you empty the target directory before restoring the backup.

If the restoration completes successfully, the progress dialog displays this message:

<<Database restore complete>>

Refer to recovery.log for an analysis

Detailed results of the restore operation are written to the file recovery.log, which is created in Greentree Desktop directory.

If any errors are encountered during the restore operation, or you abort during the operation, you can't use the database. To perform the restore operation, the jdbutil.exe form must have exclusive access to the database. Greentree Desktop and all Greentree Desktop services must be shut down before a restore can be initiated.

Following a successful restore operation, always perform a verify checksum operation to ensure database file integrity.

Once the restore operation has successfully completed, the database is available again for use.

How to Restore when Archival Recovery is in Use

A database may be recovered to the end of the last archive transaction log, or it can be recovered to a specific date and time — for example, to reverse the effects of unwanted modifications to data.

To recover the database to an operational state from the backup, all archived log files created since the last backup was performed are required, and the current transaction log (as per the restore process).

The jdbutil.exe form is used to perform an archival recovery. Restoring and recovering the database is a two-step process:

  1. Restore Transaction Logs to restore all the archived transaction logs backed up since the last full backup.
  2. Restore and Roll-Forward to restore the database files from a specified backup location, and perform a roll-forward recovery of the database.

To activate the first step, select the Restore Transaction Logs option from the Operation menu. The database directory is the location to restore your transaction logs to. The from directory is if the transaction log files are backed up.

You can restore one file or a range of files. A range of numbers displays if more than one file is being restored. Greentree Desktop defaults the first and last log numbers using the last backup and time of recovery.

When the restore is activated, each file being restored displays in a running report to the form. The process involves copying the backup files to the nominated database directory. You can abort the run anytime by clicking the Cancel button.

If the restoration completes successfully, the progress dialog displays this message:

<<Transaction log restoration complete>>

Refer to recovery.log for an analysis

Detailed results of the restore operation are written to a recovery.log file which is created in the database directory specified above.

If any errors are encountered during the restore operation, the progress dialog and the recovery.log file indicates this.

Once transaction logs have been restored to the database directory, the second step (Restore and Roll Forward) can be processed. See Roll-Forward Recovery Restrictions before activating a roll-forward recovery, as there are some restrictions relating to this operation.

The database path indicates the path to which your backed up database is going to be restored. The backup directory is specified in the From Backup Location groupbox.

There are two roll-forward recovery options:

  1. Recover transactions to end of last log

    This enables a full recovery up to the most current transaction log. It is the closest you will ever get to simulating the real-time status of the database before the failure.

  2. Recover transactions up to date time

    This enables a recovery up to a specified date and time. Greentree Desktop identifies all transaction logs that are required to meet this specification, and only roll-forward log files with a date/time stamp before the date & time nominated here.

    Note: Recovery to a specific date and time will invalidate any existing later transaction logs. All transactions that follow the last log recovered is lost.

Greentree uses information about the files is retained in the file _control.dat to roll them over. The starting log file number and an internal creation timestamp is retained in the control file, so that the roll-forward recovery always starts from the correct log. If the transaction log is not present, a dialog prompts you to restore the file from backup.

If the log timestamp and required sequencing information are not correct, an error is reported and the recovery operation will not proceed. These checks prevent against operational errors — for example, the loading of incorrect log files. In addition, each successive log is checked that it contains precisely the next required record in sequence (by date, time, and sequence number).

To activate the roll-forward recovery operation, click OK on the form above. The backupinfo file is referenced, and checked with the backed up database files before the recovery.

While the restore operation running, a progress dialog displays to the form that enables you to monitor the progress of the operation. You can abort the recovery anytime by clicking the Cancel button.

When the operation is finished, this message displays:

<Database restore complete>

If the restore was successful, the recovery phase begins. While roll-forward recovery running, a progress dialog displays, which enables you to monitor the progress of the operation. You can abort the roll-forward anytime by clicking the Cancel button.

When the operation is finished, this message displays:

<Database recovery complete>

If any errors are encountered during the restore or roll-forward operation, or you abort during the operation, you can't use the database. To perform the restore and recovery operations, the jdbutil.exe form must have exclusive access to the database. Greentree Desktop and all Greentree Desktop services must be shut down before a restore can be initiated.

Following a successful restore and recovery operation, always perform a verify checksum operation to ensure database file integrity.

Once the restore & recovery operations have successfully completed, the database is available again for use.

Note: The jdbutil.exe restore and recovery operations do not restore the database bin files, only the database files and transaction log files. You must restore the \bin folder using the latest system backup.

Roll-Forward Recovery Restrictions

Roll-forward recovery cannot be performed across these database activities:

  • Database re-organisation (this includes the application of packages)
  • Database file compaction

If either of these activities has occurred on the database, you must take a full database backup after the package application or compaction.

Note: The jdbutil.exe restoration process does not restore the database \bin folder, only Greentree Desktop directory. You must restore the \bin folder using the latest system backup.