Skip to main content
The restore command retrieves files from an Arius repository in Azure Blob Storage and reconstructs them locally. It operates in two distinct modes: pointer synchronization (default) and full binary download.

Usage

arius restore [<Targets>...]
  --accountname <name>
  --accountkey  <key>
  --passphrase  <passphrase>
  --container   <container>
  [--root       <directory>]
  [--download]
  [--include-pointers]

Parameters

Positional

Targets
string[]
default:"./"
One or more directories or files to restore. Accepts relative or absolute paths. Defaults to the current directory, which restores everything under LocalRoot.
  • If a directory is provided, all pointer files within it (recursively) are restored.
  • If a file path is provided, only that specific file is restored.

Options

--accountname
string
required
Azure Storage Account name. Short flag: -n. If not provided as a flag, falls back to the ARIUS_ACCOUNT_NAME environment variable.
--accountkey
string
required
Azure Storage Account key. Short flag: -k. If not provided as a flag, falls back to the ARIUS_ACCOUNT_KEY environment variable.
--container
string
required
Azure Blob Storage container name. Short flag: -c.
--passphrase
string
required
Passphrase used to decrypt blobs. Must match the passphrase used during archival. Short flag: -p.
--root
string
default:"current directory"
Root directory for the restore operation. Short flag: -r. Pointer files are resolved relative to this directory. Defaults to the current working directory.
--download
boolean
default:"false"
Download and restore the actual binary content of files. Without this flag, only pointer file synchronization is performed — no binary data is downloaded.If a file is stored in the Azure Archive tier, the first run with --download triggers rehydration. The actual download completes only after rehydration finishes (typically around 15 hours). Run the command again after that window to complete the download.
--include-pointers
boolean
default:"false"
When --download is used, also create the corresponding .pointer.arius files alongside the restored binaries.

Complete example

Synchronize pointer files only (no binary download):
arius restore \
  --accountname mystorageaccount \
  --accountkey  "base64encodedkey==" \
  --passphrase  "my secret phrase" \
  --container   arius-backups
Download binary files for a specific subdirectory:
arius restore /data/photos/2023 \
  --accountname mystorageaccount \
  --accountkey  "base64encodedkey==" \
  --passphrase  "my secret phrase" \
  --container   arius-backups \
  --download
Using environment variables for credentials:
export ARIUS_ACCOUNT_NAME=mystorageaccount
export ARIUS_ACCOUNT_KEY=base64encodedkey==

arius restore \
  --passphrase "my secret phrase" \
  --container  arius-backups \
  --download

Archive tier rehydration

Files stored in the Azure Archive tier are offline and cannot be downloaded directly. The restore process for these files is two steps:
Two-step restore for Archive tier blobs:
  1. Run arius restore --download. Arius detects that the blobs are in Archive tier and initiates rehydration for each file. No binary data is downloaded yet.
  2. Wait approximately 15 hours for Azure to complete rehydration.
  3. Run arius restore --download again. Arius downloads the now-online blobs and writes them to disk.
The progress output will indicate how many files are still rehydrating after the first run.

Pointer synchronization

Running restore without --download performs a pointer-only synchronization between the remote repository state and the local filesystem:
  • Pointer files (.pointer.arius) that exist in the repository but are missing locally are created.
  • Pointer files that exist locally but are no longer present in the repository are removed.
  • No binary file data is transferred.
This is useful for keeping a local directory in sync with the repository structure without consuming bandwidth or storage.

Restore result output

After a successful run, Arius prints a summary of the operation:
MetricDescription
ChunksDownloadedNumber of binary chunks downloaded from Azure.
BytesDownloadedTotal bytes downloaded from Azure.
BytesWrittenToDiskTotal bytes written to local disk after decryption and decompression.
TotalTargetFilesTotal number of files targeted by the restore.
FilesWrittenToDiskNumber of files successfully written to disk.
VerifiedFilesAlreadyExistingNumber of files that were already present locally and verified correct.
RehydratingList of files still rehydrating from Archive tier (not downloaded in this run).
WarningsList of non-fatal warning messages generated during the run.

Build docs developers (and LLMs) love