Offsite Destinations

Offsite destinations are remote restic repositories (or parents of per-site repos) used for scheduled and manual backups away from the web server disk.

Destination types

Type Notes
S3-compatible AWS, Wasabi, DigitalOcean Spaces, MinIO, etc. Access key, secret, endpoint (host or IP; blank for AWS), region, bucket, optional prefix. Invalid endpoints are rejected on save. Connection tests time out (~20s) so a bad host cannot hang the dashboard.
Backblaze B2 Key ID, application key, bucket, optional prefix.
SFTP / SSH Restic SFTP backend. Key authentication only — password-only SSH is not supported by restic SFTP.

Repository prefix

Optional parent path in the bucket or on the SFTP server. Each site gets its own restic repo under:

{prefix}/{site-slug}

Example: reaver/my-blog. Connection tests use the parent path only.

SFTP / SSH destinations

Restic’s SFTP backend authenticates with an SSH private key only. Reaver helps you get a key onto the remote host safely, then stores the key encrypted for later jobs.

Long-term storage: after you save the destination, the backup private key (auto-generated or pasted) is encrypted in dashboard config. On each backup it is written to a short-lived temp file for restic.

Fill these first

  • SSH host / port / user — where restic will connect
  • Remote path (parent) — e.g. /backups/reaver
  • SSH private key — leave blank to auto-generate, or paste PEM if you manage keys yourself
  • Key passphrase — only if the private key is encrypted

Option A — Generate & Deploy Key (automatic)

Recommended when you can log into the remote host once with a password or an existing login key.

  1. Set host, port, user, and remote path.
  2. Leave the main private key field blank.
  3. Under Auto Key Setup, provide one way to log in for the install step:
    • SSH password (used only to install the new public key), or
    • Existing private key for deploy only (when password login is disabled)
  4. Click Generate & Deploy Key.
  5. Save Destination, then Test.

Reaver creates an ED25519 key pair and appends the public key to the remote user’s ~/.ssh/authorized_keys (does not wipe existing keys). One-time login uses SSH_ASKPASS with a short-lived secret — nothing stuffed onto the process command line.

Option B — Generate Key Only (manual install)

Use when another admin or panel must add the public key:

  1. Fill host, port, user, path.
  2. Generate Key Only.
  3. Install the displayed public key on the remote host under ~/.ssh/authorized_keys.
  4. Save destination and Test.

Until the public key is installed, Test and backups will fail authentication — expected.

Option C — Your own private key

Paste an existing OpenSSH/PEM private key, ensure the matching public key is already authorized, set passphrase if needed, Save and Test.

After the key is in place

  • Always Save Destination after generating or pasting a key.
  • Test before attaching schedules.
  • Point schedules or primary repos at this destination.
  • Do not treat the one-time SSH password as the ongoing backup credential.

Day-to-day operations

  • Test — connectivity before schedules (dashboard tests time out ~20s so a bad host cannot hang the UI)
  • Enable / Disable — disabled destinations are not used for new work
  • Edit / Delete — delete does not by itself wipe remote restic data; use Settings → Repo maintenance when you intentionally destroy storage

After saving a destination, attach it to schedules and/or set it as a site primary (Settings → Primary repos or Dashboard site cards).

Encryption note

Client-side restic encryption is optional (off by default). When enabled, restic encrypts repository data with its password model; when off, rely on provider server-side encryption (SSE) and/or disk encryption on self-hosted SSH targets. Credential material in the dashboard is always encrypted at rest. Prefer providers with SSE where available.

Agent-side timeouts (backups and restores)

When an agent runs a backup or restore against a destination, it uses its own connect timeouts and retries. That is separate from the dashboard Test button:

  • SSH destinations get OpenSSH ConnectTimeout (default 30s) plus server-alive options so a rebooting host does not leave the job hung forever.
  • Connect/probe failures retry a couple of times, then fail the job with an explicit destination error (failed-backup email will say the destination could not be reached).
  • Long backup/restore transfers use a much higher wall-clock limit (default 4 hours).

Override on each agent host in data/agent.env:

Variable Default Purpose
REAVER_SSH_CONNECT_TIMEOUT 30 SSH connect timeout (seconds)
REAVER_DEST_CONNECT_TIMEOUT 60 Probe process timeout (seconds)
REAVER_DEST_CONNECT_RETRIES 2 (extra retries) Retries after first connect failure
REAVER_DEST_BACKUP_TIMEOUT 14400 Backup/restore wall-clock limit (seconds)

Full table and examples: Agents → Environment variables.
Jobs view: Backup Jobs → Destination timeouts.