HTTP Interface for Hot Backup and Restore

Introduced in: v3.5.1

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

A JSON object with these properties is required:

  • label: 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: The time in seconds that the operation tries to get a consistent snapshot. The default is 120 seconds.

  • allowInconsistent: 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.

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.

Return codes

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

  • 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.

  • 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 Created
content-type: application/json; charset=utf-8
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

A JSON object with these properties is required:

  • id: 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.

Return codes

  • 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.

  • 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" : "2019-11-07T16.04.09Z_2a65660e-dd5f-4883-a0a2-aeb66233b3be" 
}
EOF

HTTP/1.1 OK
content-type: application/json; charset=utf-8
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

A JSON object with these properties is required:

  • id: The identifier for this backup.

Delete a specific local backup identified by the given id.

Return codes

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

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

  • 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" : "2019-11-07T16.03.34Z_04eafd78-0fc2-49b7-b6a6-0ccb9f12b891" 
}
EOF

HTTP/1.1 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

Show response body

List backups

list all local backups

POST /_admin/backup/list

A JSON object with these properties is required:

  • id: 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.

Return codes

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

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

  • 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.

  • 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 OK
content-type: application/json; charset=utf-8
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.

Upload a backup to a remote repository

upload a specific local backup

POST /_admin/backup/upload

A JSON object with these properties is required:

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

  • remoteRepository: URL of remote reporsitory. 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 configurtion 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: 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: 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: 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.

Return codes

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

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

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

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

  • 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" : "2019-11-07T16.04.16Z_0769ec51-d007-4b1a-b9ac-1aed0a57ca9e", 
  "remoteRepository" : "local://tmp/backups", 
  "config" : { 
    "local" : { 
      "type" : "local" 
    } 
  } 
}
EOF

HTTP/1.1 Accepted
content-type: application/json; charset=utf-8
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" : "69099" 
}
EOF

HTTP/1.1 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

Show response body

Download a backup from a remote repository

download a specific local backup

POST /_admin/backup/download

A JSON object with these properties is required:

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

  • remoteRepository: URL of remote reporsitory. 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 configurtion 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: 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: 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: 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.

Return codes

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

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

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

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

  • 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" : "2019-11-07T16.03.51Z_7890424d-d939-4caf-a28a-00663856a018", 
  "remoteRepository" : "local://tmp/backups", 
  "config" : { 
    "local" : { 
      "type" : "local" 
    } 
  } 
}
EOF

HTTP/1.1 Accepted
content-type: application/json; charset=utf-8
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" : "69050" 
}
EOF

HTTP/1.1 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

Show response body