Restoring Data From Backup Sets

In order to access the data hot copied into backup sets, it must be restored into a database archive.

An Incremental Hot Copy is a hot copy with atoms omitted. Additionally, the atoms have not been modified since written to the previous backup elements.

Note: Before an Incremental Hot Copy operation can be performed, a new full Hot Copy backup using a Backup Set must be completed. Existing 3.0-x Hot Copy Archives (without a Backup Set) cannot be used as a reference for an Incremental Hot Copy.

The result of the Full Hot Copy operation is a new Backup Set directory from which Incremental and Journal Hot Copy operations can store the data.

The control folder located in the Backup Set directory must be accessible by the Hot Copy command to perform an Incremental or Journal backup. The entire full backup image does not need to be accessible by Hot Copy command for the Incremental Hot Copy command to be executed.

Only one backup can run at a time. Hence, you cannot execute an Incremental backup command while a Full or another Incremental Hot Copy is being executed.

As part of the Hot Copy command, you must manually specify the Storage Manager(s) (SM) to be backed up.

While not enforced, it is recommended that incremental backups be made against the same SMs used for the Full backup.

For more information on backup sets and journals, see: Backup Using Backup Sets

Restoring to Specific Transactions

When using incremental backups, you can restore to a specific transaction using timestamps. To restore to a specific transaction, do the following:

  1. Identify the backup set folder.
    This is the folder to be specified when you invoke the hot copy command.
  2. Using NuoDB Check (nuoarchive), find available transactions. For example:
  3. nuoarchive restore --report-timestamps --start-time "2017-12-10T00:00" --end-time "2017-12-10T23:59" 
    /var/opt/nuodb/production-archives/BackupSets/12-10-2017 --format simple

    The output of the --report-timestamps appears as follows (timestamps to the left and transaction IDs to the right):

    2017-12-10T19:12:37 3970
    2017-12-10T19:12:45 4738
  4. Restore a new copy for backup and journaling from the backup set by invoking the ID. In this example we are restoring to the 2017-12-10T19:12:37 timestamp.
  5. nuoarchive restore --restore-snapshot 3970 --restore-dir /var/opt/nuodb/production-archives/testrestore
     /var/opt/nuodb/production-archives/BackupSets/12-10-2017
  6. Start a new SM from the restored directory:
  7. start process sm database testrestore host localhost archive /var/opt/nuodb/production-archives/testrest 
    initialize false <options>
  8. Start new TE to integrate with the SM:
  9. start process te database testrestorehost localhost options '--dba-user dba --dba-password dba'

Note: nuoarchive restore is an offline operation. Do not restore to the transaction on a running database. Neither the source nor the target archives can be in use by a running database. nuoarchive restore creates a new archive and you can then specify this archive when starting a SM or a SSM.

Restoring Entire Backup Set

A Backup Set is a directory created when initiating a full hot copy. For more background on Backup Sets, see Backup using Backup Sets. When restoring the database from multiple Backup Sets to a globally consistent state, XML-based summaries are used as "stand-ins" for Backup Sets located on remote hosts. Global information available in these XML files enables NuoDB Archive to determine the latest common backup element to be used for Restore Entire Backup.

To restore an entire Backup Set do the following:

  1. Choose a backup collection to restore.
  2. Identify the directory where each Backup Set in the backup collection is located. For example, each Backup Set may be located in a directory on the host where that Backup Set is hot copied.
  3. Generate summaries of each Backup Set using NuoDB Archive Utility's (nuoarchive) --report-backups command. Each summary should be stored in a file. For example:
  4. ssh host1
    nuoarchive restore --report-backups /var/opt/nuodb/production-archives/BackupSets/23-07-2018 > /tmp/sm1-backupset.xml
    
    ssh host2
    nuoarchive restore --report-backups /var/opt/nuodb/production-archives/BackupSets/23-07-2018 > /tmp/sm2-backupset.xml 
  5. Copy summaries to every host involved in the restore so that every summary is available on every host. For example, use scp to copy the summary generated on host1 to host2, and vice versa.
  6. scp host1:/tmp/sm1-backupset.xml host2:/tmp/
    scp host2:/tmp/sm2-backupset.xml host1:/tmp/
    
  7. Restore a consistent copy of the archive from eachackup Set by combining the summaries with each Backup Set. In the following example, we will restore the Backup Set on each host to produce a consistent copy of the database consisting of two restored archives on two hosts (host1:/var/opt/nuodb/production-archives/testrestore and host2:/var/opt/nuodb/production-archives/testrestore).
  8. ssh host1
    nuoarchive restore --restore-dir /var/opt/nuodb/production-archives/testrestore /var/opt/nuodb/production-archives/BackupSets/23-07-2018 /tmp/sm2-backupset.xml 
     
    ssh host2
    nuoarchive restore --restore-dir /var/opt/nuodb/production-archives/testrestore /var/opt/nuodb/production-archives/BackupSets/23-07-2018 /tmp/sm1-backupset.xml 
    
  9. Start a new database, with Storage Managers (SMs) serving the restored archives. For example, to start a database named testrestore with two SMs serving the restored archives from step 5:
  10. ssh host1
    start process sm database testrestore host localhost archive /var/opt/nuodb/production-archives/testrestore initialize false [options]
    
    ssh host2
    start process sm database testrestore host localhost archive /var/opt/nuodb/production-archives/testrestore initialize false [options]

    For more information on options (see bold in above code block) available, see Database Options.

    Note: To replace a running database with a restored database, first shut down the running database completely. Then start up a new database with the same name that has SMs serving restored archives. You must shut down the running first, or else the restored archives will be overwritten by archive synchronization.

    For more information on archiving, see NuoDB Archive.