ArangoDB v3.8 reached End of Life (EOL) and is no longer supported.

This documentation is outdated. Please see the most recent version at docs.arangodb.com

HTTP Interface for Hot Backup and Restore

This is an introduction to ArangoDB’s HTTP interface for hot backup and restore.

Hot Backup is only available in the Enterprise Edition.

Hot Backups

Hot backups are near instantaneous consistent snapshots of an entire ArangoDB service. This includes all databases, collections, indexes, view definitions and users at any given time.

For creations a label may be specified, which if omitted is replaced with a generated UUID. This label is then combined with a timestamp to generate an identifier for the created hot backup. Subsequently, all other APIs operate on these identifiers.

The below APIs exclusively handle POST actions.

Make sure to understand all aspects of hot backups, most of all the requirements and limitations, before using the API.

Create backup

creates a local backup

POST /_admin/backup/create

Request Body

  • label (string, optional): The label for this backup. The label is used together with a timestamp string create a unique backup identifier, <timestamp>_<label>. If no label is specified, the empty string is assumed and a default UUID is created for this part of the ID.

  • timeout (number, optional): The time in seconds that the operation tries to get a consistent snapshot. The default is 120 seconds.

  • allowInconsistent (boolean, optional): If this flag is set to true and no global transaction lock can be acquired within the given timeout, a possibly inconsistent backup is taken. The default for this flag is false and in this case a timeout results in an HTTP 408 error.

  • force (boolean, optional): If this flag is set to true and no global transaction lock can be acquired within the given timeout, all running transactions are forcefully aborted to ensure that a consistent backup can be created. This does not include JavaScript transactions. It waits for the transactions to be aborted at most timeout seconds. Thus using force the request timeout is doubled. To abort transactions is almost certainly not what you want for your application. In the presence of intermediate commits it can even destroy the atomicity of your transactions. Use at your own risk, and only if you need a consistent backup at all costs. The default and recommended value is false. If both allowInconsistent and force are set to true, then the latter takes precedence and transactions are aborted. This is only available in the cluster.

Creates a consistent backup “as soon as possible”, very much like a snapshot in time, with a given label. The ambiguity in the phrase “as soon as possible” refers to the next window during which a global write lock across all databases can be obtained in order to guarantee consistency. Note that the backup at first resides on the same machine and hard drive as the original data. Make sure to upload it to a remote site for an actual backup.

Responses

HTTP 201: If all is well, code 201 is returned.

HTTP 400: If the create command is invoked with bad parameters or any HTTP method other than POST, then an HTTP 400 is returned. The specifics are detailed in the returned error document.

HTTP 408: If the operation cannot obtain a global transaction lock within the timeout, then an HTTP 408 is returned.

Examples

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/create <<EOF
{ 
  "label" : "foo" 
}
EOF

HTTP/1.1 201 Created
content-type: application/json
connection: Keep-Alive
content-length: 184
server: ArangoDB
x-content-type-options: nosniff
Show response body

The result body contains besides the above discussed error codes the result object, if code is equal to 201, which holds the unique identifier of this hot backup as the string attibute id, the full size in bytes as sizeInBytes, the number of idividual files as nrFiles and the number of database servers as nrDBServers. Single server deployments list potentially misleadingly nrDBServers: 1. Furthermore, the body contains a datetime time stamp and the flag potentiallyInconsistent, which indicates that the backup could inconsistent. This only happens if allowInconsistent has happened.

Restore backup

restores from a local backup

POST /_admin/backup/restore

Request Body

  • id (string, required): The id of the backup to restore from.

Restores a consistent backup from a snapshot in time, with a given id. The backup snapshot must reside on the ArangoDB service locally.

Responses

HTTP 200: Is returned if the backup could be restored. Note that there is an inevitable discrepancy between the single server and the cluster. In a single server, the request returns successfully, but the restore is only executed afterwards. In the cluster, the request only returns when the restore operation has been completed successfully. The cluster behaviour is obviously the desired one, but in a single instance, one cannot keep a connection open across a restart.

HTTP 400: If the restore command is invoked with bad parameters or any HTTP method other than POST, then an HTTP 400 is returned. The specifics are detailed in the returned error document.

Examples

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/restore <<EOF
{ 
  "id" : "2023-03-29T16.01.47Z_db157c8e-2cfe-4583-9d56-67af404b993a" 
}
EOF

HTTP/1.1 200 OK
content-type: application/json
connection: Keep-Alive
content-length: 125
server: ArangoDB
x-content-type-options: nosniff
Show response body

The result object returns the id of the fail safe hot backup to return to, if necessary. And the all telling isCluster boolean attribute.

Delete a backup

delete a specific local backup

POST /_admin/backup/delete

Request Body

  • id (string, required): The identifier for this backup.

Delete a specific local backup identified by the given id.

Responses

HTTP 200: If all is well, this code 200 is returned.

HTTP 400: If the delete command is invoked with bad parameters or any HTTP method other than POST, then an HTTP 400 is returned.

HTTP 404: If a backup corresponding to the identifier id cannot be found.

Examples

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/delete <<EOF
{ 
  "id" : "2023-03-29T16.01.15Z_56c6ad70-ffa4-417d-9a7e-b588dbab51d2" 
}
EOF

HTTP/1.1 200 OK
content-type: application/json
connection: Keep-Alive
content-length: 38
server: ArangoDB
x-content-type-options: nosniff
Show response body

List backups

list all local backups

POST /_admin/backup/list

Request Body

  • id (string, optional): The body can either be empty (in which case all available backups are listed), or it can be an object with an attribute id, which is a string. In the latter case the returned list is restricted to the backup with the given id.

Lists all locally found backups.

Responses

HTTP 200: If all is well, code 200 is returned.

HTTP 400: If the list command is invoked with bad parameters, then an HTTP 400 is returned.

HTTP 404: If an id or a list of ids was given and the given ids were not found as identifiers of a backup, an HTTP 404 NOT FOUND is returned.

HTTP 405: If the list command is invoked with any HTTP method other than POST, then an HTTP 405 METHOD NOT ALLOWED is returned.

Examples

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/list <<EOF
{ 
}
EOF

HTTP/1.1 200 OK
content-type: application/json
connection: Keep-Alive
content-length: 1044
server: ArangoDB
x-content-type-options: nosniff
Show response body

The result consists of a list object of hot backups by their id, where id uniquely identifies a specific hot backup, version depicts the version of ArangoDB, which was used to create any individual hot backup and datetime displays the time of creation of the hot backup. Further parameters are the size of the backup in bytes as sizeInBytes, the number of individual data files as nrFiles, the number of db servers at time of creation as nrDBServers, the number of backup parts, which are found on the currently reachable db servers as nrPiecesPresent. If the backup was created allowing inconsistences, it is so denoted as potentiallyInconsistent. The available boolean parameter is tightly connected to the backup to be present and ready to be restored on all db servers. It is true except, when the number of db servers currently reachable does not match to the number of db servers listed in the backup. Should the backup be encrypted the sha256 hashes of the user secrets are published here. This will allow you to use the correct user secret for the encryption-at-rest feature to be able to restore the backup.

Upload a backup to a remote repository

upload a specific local backup

POST /_admin/backup/upload

Request Body

  • id (string, optional): The identifier for this backup. This is required when an upload operation is scheduled. In this case leave out the uploadId attribute.

  • remoteRepository (string, optional): URL of remote repository. This is required when an upload operation is scheduled. In this case leave out the uploadId attribute. Provided repository URLs are normalized and validated as follows: One single colon must appear separating the configuration section name and the path. The URL prefix up to the colon must exist as a key in the config object below. No slashes must appear before the colon. Multiple back to back slashes are collapsed to one, as .. and . are applied accordingly. Local repositories must be absolute paths and must begin with a /. Trailing / are removed.

  • config (object, optional): Configuration of remote repository. This is required when an upload operation is scheduled. In this case leave out the uploadId attribute. See the description of the arangobackup program in the manual for a description of the config object.

  • uploadId (string, optional): Upload ID to specify for which upload operation progress is queried or the upload operation to abort. If you specify this, leave out all the above body parameters.

  • abort (boolean, optional): Set this to true if a running upload operation should be aborted. In this case, the only other body parameter which is needed is uploadId.

Upload a specific local backup to a remote repository, or query progress on a previously scheduled upload operation, or abort a running upload operation.

Responses

HTTP 200: If all is well, code 200 is returned if progress is inquired or the operation is aborted.

HTTP 202: If all is well, code 202 is returned if a new operation is scheduled.

HTTP 400: If the upload command is invoced with bad parameters or any HTTP method other than POST, then an HTTP 400 is returned.

HTTP 401: If the authentication to the rempote repository fails, then an HTTP 400 is returned.

HTTP 404: If a backup corresponding to the identifier id cannot be found, or if there is no known upload operation with the given uploadId.

Examples

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/upload <<EOF
{ 
  "id" : "2023-03-29T16.01.57Z_31d6b79c-ca2b-4e2c-ab2e-f2726b5ec595", 
  "remoteRepository" : "local://tmp/backups", 
  "config" : { 
    "local" : { 
      "type" : "local" 
    } 
  } 
}
EOF

HTTP/1.1 202 Accepted
content-type: application/json
connection: Keep-Alive
content-length: 56
server: ArangoDB
x-content-type-options: nosniff
Show response body

The result object of the body holds the uploadId string attribute which can be used to follow the upload process.

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/upload <<EOF
{ 
  "uploadId" : "66794" 
}
EOF

HTTP/1.1 200 OK
content-type: application/json
connection: Keep-Alive
content-length: 222
server: ArangoDB
x-content-type-options: nosniff
Show response body

Download a backup from a remote repository

download a specific local backup

POST /_admin/backup/download

Request Body

  • id (string, optional): The identifier for this backup. This is required when a download operation is scheduled. In this case leave out the downloadId attribute.

  • remoteRepository (string, required): URL of remote repository. This is required when a download operation is scheduled. In this case leave out the downloadId attribute. Provided repository URLs are normalized and validated as follows: One single colon must appear separating the configuration section name and the path. The URL prefix up to the colon must exist as a key in the config object below. No slashes must appear before the colon. Multiple back to back slashes are collapsed to one, as .. and . are applied accordingly. Local repositories must be absolute paths and must begin with a /. Trailing / are removed.

  • config (object, required): Configuration of remote repository. This is required when a download operation is scheduled. In this case leave out the downloadId attribute. See the description of the arangobackup program in the manual for a description of the config object.

  • downloadId (string, optional): Download ID to specify for which download operation progress is queried, or the download operation to abort. If you specify this, leave out all the above body parameters.

  • abort (boolean, optional): Set this to true if a running download operation should be aborted. In this case, the only other body parameter which is needed is downloadId.

Download a specific local backup from a remote repository, or query progress on a previously scheduled download operation, or abort a running download operation.

Responses

HTTP 200: If all is well, code 200 is returned if progress is inquired or the operation is aborted.

HTTP 202: If all is well, code 202 is returned if a new operation is scheduled.

HTTP 400: If the download command is invoked with bad parameters or any HTTP method other than POST, then an HTTP 400 is returned.

HTTP 401: If the authentication to the rempote repository fails, then an HTTP 401 is returned.

HTTP 404: If a backup corresponding to the identifier id cannot be found, or if there is no known download operation with the given downloadId.

Examples

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/download <<EOF
{ 
  "id" : "2023-03-29T16.01.31Z_f9d28674-6d7a-4110-996f-c8db3aade1c7", 
  "remoteRepository" : "local://tmp/backups", 
  "config" : { 
    "local" : { 
      "type" : "local" 
    } 
  } 
}
EOF

HTTP/1.1 202 Accepted
content-type: application/json
connection: Keep-Alive
content-length: 58
server: ArangoDB
x-content-type-options: nosniff
Show response body

The result object of the body holds the downloadId string attribute which can be used to follow the download process.

shell> curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_admin/backup/download <<EOF
{ 
  "downloadId" : "66755" 
}
EOF

HTTP/1.1 200 OK
content-type: application/json
connection: Keep-Alive
content-length: 224
server: ArangoDB
x-content-type-options: nosniff
Show response body
❮  User Management

© ArangoDB - Graph and Beyond