Restore from a Single Backup Set - Examples

In these examples, three separate locations are assumed:

/volumes/archives for database archive storage.
/volumes/backups for backup storage.
/volumes/journals for database journal storage.

Restore a Single SM

Suppose one SM in a database has been offline during a planned (or unplanned) outage. If the archive is extremely out of date it may be faster to restore a recent backup than to wait for the SM to sync when it starts.

If the archive and/or journal have been lost, perhaps due to disk failure, synching a new, empty, archive will be required. This places a load on the other SMs and can be slow. Restoring the archive first from the most recent backup is usually quicker.

The simplest restore assumes you take periodic incremental and/or journal backups:

rm -rf /volumes/archives/test
# On SM host, remove out-of-date archive

nuoarchive restore --restore-dir /volumes/archives/test /volumes/backups/BackupSets/2022-04-18
# Replace from the backup

rm -rf /volumes/journal
# By default the journal is a subdirectory of the archive.
# Otherwise, you need to replace the old journal too.

mv /volumes/archives/test/journal /volumes/journal/test

sudo chown -R nuodb:nuodb /volumes/archives/test

sudo chown -R nuodb:nuodb /volumes/journal/test

nuocmd start process --db-name test --type SM --archive-id 0 --this-server
# Restart the SM

In this example we are restoring the SM for archive with id=0 of database test.
- If you aren’t sure of the archive id, check using nuocmd show archives.
The restore will restore the archive to the state as at the most recent incremental or journal backup in the backup set.

Restore to Specific Backup Elements

When using incremental (or journal) backups, you can restore to a specific element using element IDs.

In this example assume there are two hosts, host1 and host2, corresponding to the Admin Processes (servers) with ids nuoadmin-1 and nuoadmin-2 repectively. The domain looks like this:

nuocmd show domain
server version: 6.0-1-fc6a857de9, server license: Enterprise
server time: 2023-09-08T06:22:06.165012, client token: f37640883d151b9a034970300ceb37ae46fecbad
Servers:
  [nuoadmin-0] host1:48005 [last_ack = 7.57] ACTIVE (LEADER, Leader=nuoadmin-0, log=199574/154/154) Connected *
  [nuoadmin-1] host2:48005 [last_ack = 7.57] ACTIVE (FOLLOWER, Leader=nuoadmin-0, log=199574/154/154) Connected
Databases:
  test [state = RUNNING]
    [SM] host1:48006 [start_id = 10] [server_id = nuoadmin-0] [pid = 640] [node_id = 1] [last_ack = 10.18] MONITORED:RUNNING
    [TE] host1:48007 [start_id = 12] [server_id = nuoadmin-0] [pid = 357] [node_id = 3] [last_ack =  8.08] MONITORED:RUNNING
    [SM] host2:48006 [start_id = 11] [server_id = nuoadmin-1] [pid = 207] [node_id = 2] [last_ack = 10.18] MONITORED:RUNNING
    [TE] host1:48007 [start_id = 13] [server_id = nuoadmin-1] [pid = 291] [node_id = 4] [last_ack =  9.17] MONITORED:RUNNING

To restore to a specific backup element, do the following:

Identify a backup set to be restored. In this example each SM is backing up to a local /volumes/backups directory on its host. Copying locally is usually faster, but this is not a restriction.
Identify the directory where the backup set is located. In this example, each host is using the backup set /volumes/backups/BackupSets/2022-04-18. We can use either one, the procedure is the same.

Using NuoDB Archive's --report-backups command, generate a summary of your chosen backup set. For example:

nuoarchive restore --report-backups /volumes/backups/BackupSets/2022-04-18

<BackupSet id="16df36f3-afb1-bf45-5e87-a6b6d3e44fdf" database="test" databaseId="efa117e7-8b5c-5449-14ab-80f77e81334b" collectionId="fb7f28df-
405f-488e-b7e4-7307e373be7f" archiveId="9e1a097b-e310-2f4a-38ab-f04f4eaeb1c8">
 <BackupElements>
   <BackupElement id="63bdb6de-5382-459a-8397-c786f16817d4" type="incremental" startDate="2022-04-18 14:20:45" endDate="2022-04-18 14:20:46"/>
   <BackupElement id="4d7338fe-f3c9-4041-aaa1-77ba730807f5" type="journal" startDate="2022-04-18 14:20:37" endDate="2022-04-18 14:20:39"/>
   <BackupElement id="9be268f4-4b11-4913-b7af-cc27bd970d0e" type="incremental" startDate="2022-04-18 14:20:30" endDate="2022-04-18 14:20:31"/>
   <BackupElement id="fb7f28df-405f-488e-b7e4-7307e373be7f" type="full" startDate="2022-04-18 14:20:24" endDate="2022-04-18 14:20:24"/
 </BackupElements>
</BackupSet>

Note that the backups are listed most recent first.

Restore from the backup set using the desired backup element ID . The following example demonstrates restoring of the backup set to the first incremental backup element - the element with id 9be268f4-4b11-4913-b7af-cc27bd970d0e.
```
nuoarchive restore --backup-element-id 9be268f4-4b11-4913-b7af-cc27bd970d0e \
       --restore-dir /volumes/archives/test2 \
       /volumes/backups/BackupSets/2022-04-18
```

Ensure correct ownership:

sudo chown -R nuodb:nuodb /volumes/archives/test2

Optionally, move the journal to its own volume. If you do this:
- Check to make sure ownership is still correct.
- Use --journal-dir when invoking nuocmd create archive.
Start a new database, with a new SM serving the restored archive. For example, start a database named test2 using the restored archives from step 5 running on a new host host3 (server id nuoadmin2):
```
nuocmd create archive --db-name test2 --restored --archive-path /volumes/archives/test2 --server-id nuoadmin-2
```
```
nuocmd create database --db-name test2 --dba-user ... --dba-password ... --te-server-ids nuoadmin-2
```
After database test2 is running, the DBA user and password will be whatever they were in the original database we restored from.

Now the domain looks like this:

nuocmd show domain

server version: 6.0-1-fc6a857de9, server license: Enterprise
server time: 2023-09-08T06:22:06.165012, client token: f37640883d151b9a034970300ceb37ae46fecbad
Servers:
  [nuoadmin-0] host1:48005 [last_ack = 4.16] ACTIVE (LEADER, Leader=nuoadmin-0, log=199574/163/163) Connected *
  [nuoadmin-1] host2:48005 [last_ack = 4.16] ACTIVE (FOLLOWER, Leader=nuoadmin-0, log=199574/163/163) Connected
Databases:
  test [state = RUNNING]
    [SM] host1:48006 [start_id = 10] [server_id = nuoadmin-0] [pid = 640] [node_id = 1] [last_ack = 10.18] MONITORED:RUNNING
    [TE] host1:48007 [start_id = 12] [server_id = nuoadmin-0] [pid = 357] [node_id = 3] [last_ack =  8.08] MONITORED:RUNNING
    [SM] host2:48006 [start_id = 11] [server_id = nuoadmin-1] [pid = 207] [node_id = 2] [last_ack =  9.84] MONITORED:RUNNING
    [TE] host1:48007 [start_id = 13] [server_id = nuoadmin-1] [pid = 291] [node_id = 4] [last_ack =  9.17] MONITORED:RUNNING
  test2 [state = RUNNING]
    [SM] host1:48006 [start_id = 0] [server_id = nuoadmin-0] [pid = 827] [node_id = 1] [last_ack =  9.92] MONITORED:RUNNING
    [TE] host1:48007 [start_id = 1] [server_id = nuoadmin-0] [pid = 831] [node_id = 2] [last_ack =  9.21] MONITORED:RUNNING

Restore to Specific Transactions

When using journal backups, you can restore to a specific transaction using timestamps, a point-in-time restore. In this example, assume we are running on a host with server id nuoadmin-1.

Identify the backup set folder. This was the folder specified when invoking the hot copy command. In this example, the backup set folder is /volumes/backups/BackupSets/2022-04-18.

Using NuoDB Archive (nuoarchive), find available transactions. For example:

nuoarchive restore --report-timestamps --format simple \
       --start-time "2022-04-18T19:00" --end-time "2022-04-18T19:59" \
       /volumes/backups/BackupSets/2022-04-18

2022-04-18T19:12:37  3970
2022-04-18T19:12:45  4738

In the output above, timestamps are to the left and transaction IDs to the right.

Restore a new copy from the backup set by using its ID. In this example we are restoring to the 2022-04-18T19:12:37 timestamp using ID 3970.
```
nuoarchive restore --restore-snapshot 3970 --restore-dir /volumes/archives/test2 \
    /volumes/backups/BackupSets/2022-04-18
```

Ensure correct ownership

sudo chown -R nuodb:nuodb /volumes/archives/test2

Optionally, move the journal to its own volume. If you do this:
- Check to make sure ownership is still correct.
- Use --journal-dir when invoking nuocmd create archive.

Start a new SM from the restored directory:

nuocmd create archive --db-name test2 --restored --archive-path /volumes/archives/test2 --server-id nuoadmin-1

nuocmd create database --db-name test2 --dba-user <user> --dba-password <password> --te-server-ids nuoadmin-1

After database test2 is running, the DBA user and password will be whatever they were in the original database we restored from at that particular point in time.