Management Interface: restore

This command restores a backup from another Enterprise server.

Typical Usage

Danger

Using this command will permanently delete all data on your current server and replace it with the contents of the backup. Be extra sure you mean to do this as that data cannot be recovered.

Running ./manage_server restore --file </path/to/bn_enterprise_backup.tar> will restore the contents of that backup to your current server (and any connected services, like WARP, if the backup has data for them as well). The server must be already started and running in order to perform the restore.

Warning

We strongly recommend restarting the Enterprise server after restoring from a backup. While we do run database migrations directly after the restore, it's not always possible to guarantee the state of each service is as-expected.

Note

If you are using the bundled object store (SeaweedFS), restores can fail (usually with a Broken pipe and a traceback containing a message about an error in the UploadPart operation) if it runs out of writable volumes. Check the object-store logs for No writable volumes and increase ENTERPRISE_OBJECT_STORE_VOLUME_SIZE and/or ENTERPRISE_OBJECT_STORE_MAX_VOLUMES in config.env before retrying.

Additional Considerations

An older backup can be restored to a newer Enterprise server. Once the backup has been loaded, database migrations will be applied to bring the older database up to the newer version.

Danger

A backup from a newer Enterprise server cannot be restored to an older version of the Enterprise server.

Warning

Backup format version 0 files (from v1.0.43 or earlier) are no longer supported as of v2.0 of the Enterprise server. Contact support if you need assistance restoring from one of these older backups.

Command Help

Restore Enterprise server data from archive (requires server to be running)

Usage: manage_server restore [OPTIONS]

Options:
  -f, --file <file>                      [default: bn_enterprise_backup.tar]
      --swarm[=<STACK_NAME>]             Operate in docker swarm mode [env: ENTERPRISE_STACK_NAME=]
      --registry-host <HOSTNAME>         Hostname of custom registry [env: ENTERPRISE_REGISTRY_HOST=registry.internal.v35.us] [default: registry.enterprise.binary.ninja]
  -y, --yes                              Assume 'yes' for all restore confirmations [aliases: --force, --force-yes]
      --no-wait                          Skip readiness checks inside the backend container before restore
      --registry-username <USER>         Username for custom registry [env: ENTERPRISE_REGISTRY_USERNAME=]
      --registry-password <PASSWORD>     Password for custom registry [env: ENTERPRISE_REGISTRY_PASSWORD=]
      --wait-timeout <wait-timeout>      Timeout in seconds for readiness checks inside the backend container [default: 60]
      --docker-host <HOST>               Overrides the default Docker/Podman Unix socket [env: DOCKER_HOST=]
      --container-engine <ENGINE>        Container engine to use for deployments (docker or podman) [env: ENTERPRISE_CONTAINER_ENGINE=docker] [default: docker] [possible values: docker, podman]
  -l, --license-file <license-file>      Path to Binary Ninja license file [env: ENTERPRISE_SERVER_LICENSE_FILE=] [default: license.dat]
  -b, --license-bundle <license-bundle>  Local path to Enterprise client floating license bundle [env: ENTERPRISE_SERVER_LICENSE_BUNDLE_FILE=] [default: license-bundle.b64]
      --uid <uid>                        User ID used for data and tasks (defaults to current User ID) [env: ENTERPRISE_SERVER_UID=]
      --gid <gid>                        Group ID used for data and tasks (defaults to current Group ID) [env: ENTERPRISE_SERVER_GID=]
  -h, --help                             Print help

Database Options:
      --db-name <NAME>           Name of database to use [env: ENTERPRISE_DATABASE_NAME=] [default: binaryninja_enterprise]
      --db-host <HOSTNAME>       Name of host to use when connecting to database [env: ENTERPRISE_DATABASE_HOST=] [default: database]
      --db-port <PORT>           The port to use when connecting to database [env: ENTERPRISE_DATABASE_PORT=] [default: 5432]
      --db-user <USERNAME>       The user to use when connecting to database [env: ENTERPRISE_DATABASE_USER=] [default: binaryninja_enterprise]
      --db-password-file <FILE>  Path to file containing password to authenticate with the database [env: ENTERPRISE_DATABASE_PASSWORD_FILE=] [default: ./secrets/db_password]

Key-Value Store Options:
      --redis-url <URL>  URL to use when connecting to message broker [env: ENTERPRISE_KV_STORE_URL=] [default: redis://redis:6379]

Object Store Options:
      --object-store-bucket-name <BUCKET>    Object store bucket name (must be between 3 and 63 characters, only using lowercase letters, numbers, dot, and hyphen) [env: ENTERPRISE_OBJECT_STORE_BUCKET_NAME=] [default: binaryninja-enterprise]
      --object-store-endpoint-url <URL>      Object store endpoint URL [env: ENTERPRISE_OBJECT_STORE_URL=] [default: https://object-store:8333]
      --object-store-access-key-file <FILE>  Path to file containing the access key ID to use when authenticating with the object store [env: ENTERPRISE_OBJECT_STORE_ACCESS_KEY_FILE=] [default: ./secrets/object_store_access_key_id]
      --object-store-secret-key-file <FILE>  Path to file containing the secret access key to use when authenticating with the object store [env: ENTERPRISE_OBJECT_STORE_SECRET_KEY_FILE=] [default: ./secrets/object_store_secret_access_key]

Note

Please remember that the user running this command must have permissions to run docker commands for it to complete successfully.