Offsite copies

An offsite copy is a copy of your backups somewhere other than the computer Tesria runs on, so that losing that computer, to a dead disk, a fire or a theft, does not lose the wiki. It is the most important thing to add after installing, because it is the one thing Tesria cannot do without you.

The three kinds

Use any of them, or all three together. What goes where:

flowchart LR
  subgraph server["Encrypted here, before it leaves"]
    bkv[("Dumps and attachment archives")]
    pgb["Database changes and full copies"]
  end
  bkv -->|"after every backup"| cloud["Cloud storage"]
  pgb -->|"continuously"| cloud
  bkv -->|"after every backup"| nas["A network drive"]
  bkv -->|"when someone chooses Copy now"| usb["A removable drive"]

Everything is encrypted on this computer before it leaves, so none of the three can read what it holds. Only cloud storage receives the database’s changes as they happen, which is what lets it restore to any moment; the network and removable drives hold the daily dumps and the attachments.

• Cloud storage. Any storage that speaks the S3 protocol; Backblaze B2 is the documented choice. Copied to after every backup, and database changes stream there continuously in between. It holds everything, including restoring to any moment. The best single choice.

• A network drive. A shared folder on a NAS on your network. Copied to after every backup. It holds the dumps and the attachments.

• A removable drive. A USB disk you plug in, copy to, and take away. Copied to only when someone chooses Copy now. It holds the dumps and the attachments.

Every copy is encrypted on the server before it leaves, each with its own passphrase. The settings go in .env rather than on the admin page, so that the keys never enter the database and never travel inside a backup. The Backups tab shows fingerprints of them instead of the keys.

Cloud storage

Step 1: Make a bucket and a key

At your storage provider, create a bucket (a named storage area) and an access key allowed to use it. The provider shows the key’s ID and secret once; copy both.

Step 2: Add the settings to .env

For Backblaze B2, with your own bucket, region and key. Make the passphrase with openssl rand -hex 32:

OFFSITE_CLOUD_TYPE=b2
OFFSITE_CLOUD_ENDPOINT=s3.us-west-000.backblazeb2.com
OFFSITE_CLOUD_BUCKET=tesria-backups
OFFSITE_CLOUD_REGION=us-west-000
OFFSITE_CLOUD_PATH=/tesria
OFFSITE_CLOUD_URI_STYLE=host
OFFSITE_CLOUD_KEY=your-key-id
OFFSITE_CLOUD_SECRET=your-key-secret
OFFSITE_CLOUD_PASSPHRASE=a-new-long-random-passphrase

For other providers, OFFSITE_CLOUD_TYPE is s3. Every setting is in the Configuration reference.

Step 3: Restart the services

docker compose up -d

Step 4: Test it

On the Backups tab, a Cloud card appears under Storage targets. Choose Test connection on it. See Testing a target and the cloud budget.

A network drive

Step 1: Connect the share to the server

Tesria never connects to a network share itself; the computer it runs on does, and handles the password and reconnecting.

• On a Mac, connect to the share in Finder. It then appears under /Volumes. The first time Tesria uses it, Docker Desktop asks to allow access to the folder: allow it, or the backup hangs until you do.

• On Linux, add the share to /etc/fstab with the options _netdev,nofail, so a missing share does not hold up starting the computer.

Step 2: Add the settings to .env

OFFSITE_NAS_PATH=/Volumes/my-nas/tesria-backups
OFFSITE_NAS_PASSPHRASE=a-new-long-random-passphrase

Then run docker compose up -d.

Step 3: Mark the share as Tesria’s

docker compose exec backup /scripts/claim-target.sh nas

This leaves a small marker file on the share, and Tesria only copies to a folder that has it. Here is why: when a share is not connected, its folder is still there on the server’s own disk, empty. Without the marker, backups would quietly fill the server’s disk instead of reaching the NAS. If the command warns that the folder is empty, the share is probably not connected.

A removable drive

Step 1: Add the settings to .env

OFFSITE_REMOVABLE_PATH=/Volumes/my-backup-drive
OFFSITE_REMOVABLE_PASSPHRASE=a-new-long-random-passphrase

Plug the drive in, then run docker compose up -d.

Step 2: Mark the drive as Tesria’s, once

docker compose exec backup /scripts/claim-target.sh removable

Step 3: Copy to it

Whenever the drive is plugged in, choose Copy now on its card under Storage targets. When the card says it is safe to remove, every byte is on the drive.

The computer may still refuse to eject the drive, because the backup service is using it. To eject it cleanly, stop the service, eject, and start it again:

docker compose stop backup
# eject the drive
docker compose up -d backup

• Format the drive as exFAT, not FAT32, which cannot hold files over 4 GB.

• A removable drive alone is not an offsite backup. Between the times someone plugs it in, there is no copy anywhere else, and the Backups tab says so.