Restore Data From Backup Sets

A simple hot copy creates an identical copy of the archive copied, which can be used directly to start a new SM - see here for details.

In all other cases, hot copy backs up into backup sets. A backup set is the directory created when initiating a full hot copy. For more background on backup sets, see Using Backup Sets.

  • To use the data hot copied into backup sets, it must be restored into a new database archive using nuoarchive.

Important Considerations

Be aware of the following:

  • nuoarchive restore is an offline operation.

  • Do not restore into any archive of a running database.

    • Neither the source backup set nor the target archive(s) can be in use by a running database.

  • nuoarchive restore creates a new archive and you can then use this archive:

    1. To start a new SM for the same database the hot copy came from.

    2. To restart an SM on an existing host that has been offline for a long time (to reduce archive synchronization time).

    3. To create a new database (a copy of the original).

  • In the event of lost or corrupted data due to an application or human error:

    • Create a brand new database by restoring to a point-in-time just before the error happened.

    • Then use SQL to copy the lost or corrupted data from the new, restored database back to the original database.

  • Ensure the correct ownership of the restored archive directory and its contents.

    • root user access or sudo elevated permissions access are required to perform this task:

      • Bare metal/VM: Run chown nuodb:nuodb <dir>

      • In a Container: Permissions should be set for you, but if necessary run chown nuodb:root <dir> (note the group is root not nuodb).

      • See also the restore Helm chart which can automate this process under Kubernetes.

  • The journal(s) will be found in a subdirectory of the restored archive. You may wish to move them to a separate directory (typically to their own volume).

    • If so, ensure the same ownership as above for the journal directory and its contents.

    • Use --journal-dir to specify its location when running nuocmd create archive.

  • If using storage groups you will probably need to restore from multiple backup sets in order to restore all storage groups. NuoDB does not track this and you need to know which backup sets, from which SMs, contain which storage groups.

    • One solution is to incorporate the storage group names in the backup set names, for example: testdb-2022-09-21-archive-0-sg1-sg2.

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

Performing a Restore

In the descriptions below, "using a backup" means using one or more backup sets to restore an archive (depending on whether you are using storage groups or not).

The basic steps are:

  1. Restore from a backup to create a new archive, repeat for multiple hosts (multiple SMs) as desired.

  2. On each host:

    1. Optionally copy the journal to its own volume.

    2. Ensure correct ownership of the archive and journal.

    3. Initialize each archive using nuocmd create archive …​ --restored

  3. Start the SM process(es):

    • Explicitly using nuocmd start process (existing database) on each host.

    • Or by using nuocmd create database (new database).

See [worked-examples] below for examples of performing step 1 (the restore).

Restoration Scenarios

Why might you restore from a backup?

Creating a New Database

  1. Use a backup to create a copy of the original database. Restore the archive on the first SM host, then copy it to all the other new SM hosts.

  2. As (1) but restore from backup to a specific point-in-time or to a specific backup-element.

New SM for an Existing Database

To reduce archive SYNC time, restore the archive from latest backup and use this to initialize the SM. The SM need only SYNC changes since the backup was taken.

Restoring a Failed SM

If an SM has failed due to a disk or other hardware error. Once fixed, use the latest backup to restore its archive (essentially the same scenario as the previous case).

Restoring a Database to a Known State

Stop the existing database, restore from the backup and use it to replace the archive and journal on every SM host, then restart the database.

Restoring a Database to a Specific Known State

This can only be done by taking the database offline and replacing its archives and journals. However, if you are careful, it can be done without deleting the database and recreating it. This is typically not a production requirement, but is often needed during development and testing. Possibile scenarios:

  1. Doing a globally consistent restore using locally available backup sets.

  2. Doing a local restore on one host and relying on that host syncing other newly started SMs.

    • All SMs but the first will start with an empty archive and journal, and so must SYNC from the first.

  3. Doing a local restore on one host and copying the archive to seed other SMs (to avoid syncing overhead).

    • Restore on one host to the exact state required and starting the SM on it.

    • Then do a local restore on the other hosts to seed them and allow them to sync with the first SM.

    • Since they all have the exact same archive and journal, syncing will be minimal.

Steps required for a local restore:

  1. Restore an archive to a temporary directory using any of the techniques described in this section.

  2. Shutdown the database and replace all its archives and journals with the restored archive and its journal.

    • How to do this is described under simple hot copy - note the warning in this section.

  3. Restart the database.

As this is most commonly required for development and/or testing, we suggest the following approach for creating the necessary backup:

  1. Create your database and populate it with the desired data.

  2. To take the backup:

    • Stop all clients so no changes to the database can occur.

    • Perform a simple hot copy on any host, multiple hosts if using storage groups.

  3. Retain the backup(s) until needed.