stardog-admin server restore
Description
Restore a Stardog home from a full backup created using the “server backup” command
Usage
stardog-admin [ --krb5 ] [ --krb5-disable-rdns ] [ --server <server url> ] server restore [ {-b | --backupId} <backup id> ] [ {-i | --node-id} <node-id> ] [ {-p | --passwd} <password> ] [ {-P | --ask-password} ] [ --run-as <username> ] [ {-u | --username} <username> ] [ {-v | --verbose} ] [--] <backup location>
Options
Name, shorthand | Description |
---|---|
-b <backup id>, --backupId <backup id> | The backupId which should be used for restore. |
-i <node-id>, --node-id <node-id> | The node-id of the server to be restored from S3. |
--krb5 | Use the Kerberos environment. |
--krb5-disable-rdns | Disable reverse DNS lookup for Kerberos clients. |
-p <password>, --passwd <password> | Password. |
-P, --ask-password | Prompt for password. |
--run-as <username> | User to impersonate when running the command |
--server <server url> | URL of Stardog Server. If this option isn’t specified, it will be read from JVM argument ‘stardog.default.cli.server’. If the JVM arg isn’t set, the default value ‘http://localhost:5820’ is used. If server URL has no explicit port value, the default port value ‘5820’ is used. Example: ‘stardog-admin –server http://12.34.56.78:5820 server stop’ |
-u <username>, --username <username> | User name. |
-v, --verbose | Flag that can cause more detailed information to be printed such as errors and status. Exact output depends upon the command and options used. |
-- | This option can be used to separate command-line options from the list of argument(s). (Useful when an argument might be mistaken for a command-line option) |
<backup location> | The full path on the server to the backup created using the “server backup” command. |
Discussion
Restores all backed up databases into the current home. Note: Stardog server should not be running on that home. The command should be executed on the server side. Note: that STARDOG_HOME target directory should be empty, if this doesn’t exist it will be created automatically
Examples
Restore the server and all the databases from the latest backup:
$ stardog-admin server restore /path/to/backup/dir/on/server
Restore the server and all the databases from a specific backup:
$ stardog-admin server restore -b 3 /path/to/backup/dir/on/server
Restore the server from AWS S3 bucket (note backslash “" before each “&”):
$ stardog-admin server restore s3:///bucket-name/path-in-bucket?region=us-east-1\&AWS_ACCESS_KEY_ID=<your key id>\&AWS_SECRET_ACCESS_KEY=<your key secret> -i <node-id>
Restore a server from AWS S3 bucket (node-id parameter from old directory’s stardog.node-id file):
$ stardog-admin server restore s3:///bucket-name/path-in-bucket?region=us-east-1\&AWS_ACCESS_KEY_ID=<your key id>\&AWS_SECRET_ACCESS_KEY=<your key secret> -i 051d52f1-9b38-48e1-b127-ac82c3b8adaf
Another node-id option is to copy the old stardog.node-id file into the empty directory before executing
a cluster server restore. If populating a different cluster server with data from another, erase the
Examples for S3
Note that S3 server backup requires a special Stardog license, restore does not. Both S3 server backup and restore require ubuntu/debian linux that has libcrypto, libcurl, and libssl installed.
S3 restore requires an additional parameter, node-id. Basic file system based restores do not need the node-id parameter. The node-id is an identifier that is unique to each server. It is stored in the stardog.node-id file within $STARDOG_HOME
. There are two ways to provide the node-id during a restore. One is using the -i
command line parameter shown in the examples below. The second way is to copy the old stardog.node-id file into the empty restore destination prior to executing the restore command.
It is reasonable to use the node-id of an existing cluster server to create/populate a new server. But you must erase the $STARDOG_HOME/stardog.node-id
created by the restore before starting the new server. Stardog will then create a new and unique stardog.node-id for the new server upon first start.
Restore the server and all the databases from the latest backup in an S3 bucket:
$stardog-admin server restore "s3:///mybucket/backup/prefix?region=us-east-1&AWS_ACCESS_KEY_ID=accessKey&AWS_SECRET_ACCESS_KEY=secret" -i <node-id>
The double quotes around the S3 URL prevent the linux command line from interpreting the ampersand, “&”, as process detach command.
Restore the server and all the databases from a specific backup in an S3 bucket:
$stardog-admin server restore -b 2 "s3:///mybucket/backup/prefix?region=us-east-1&AWS_ACCESS_KEY_ID=accessKey&AWS_SECRET_ACCESS_KEY=secret" -i 051d52f1-9b38-48e1-b127-ac82c3b8adaf
The S3 path examples are based upon the following generic S3 URL pattern:
s3:///<bucket name>/<path prefix>?region=<AWS Region>&AWS_ACCESS_KEY_ID=<access key>&AWS_SECRET_ACCESS_KEY=<verySecretKey1>