When the machine is gone
The server is broken, stolen or will not start, and all you have is an offsite copy. This page takes you from there back to a working wiki on another computer. Read it through once before you start, and keep going step by step: nothing here can make things worse, because the offsite copy is only ever read.
What you need
The passphrase of the copy you have:
OFFSITE_CLOUD_PASSPHRASE,OFFSITE_NAS_PASSPHRASEorOFFSITE_REMOVABLE_PASSPHRASE, from wherever you kept it. Without it the copy cannot be read, and there is no way around that.Access to the copy: the cloud account’s key and secret, or the drive or share itself.
A computer with Docker and room for the wiki. See Prerequisites.
You get back every page, every attachment and every account. You do not get back .env, which is in no backup because it holds the keys: you write a new one.
Step 1: Look at what the copy holds
The copies are standard restic repositories: restic and the passphrase read them on any computer, with no Tesria involved. Docker runs restic for you. For a drive or share, use the path it is at on this computer:
docker run --rm -e RESTIC_PASSWORD=your-passphrase -v /Volumes/your-drive:/t restic/restic -r /t/restic snapshotsFor the cloud copy, with your own endpoint, bucket and path:
docker run --rm -e RESTIC_PASSWORD=your-passphrase -e AWS_ACCESS_KEY_ID=key -e AWS_SECRET_ACCESS_KEY=secret restic/restic -r s3:https://endpoint/bucket/tesria/files snapshotsEach line it lists is a copy, with its date. The newest is the one to restore.
Step 2: Install an empty Tesria
Get Tesria as in Quick start, and write a new .env with new passwords and a new BACKUP_ENCRYPTION_KEY. Keep the same DOMAIN if you want the same address. Then start it:
docker compose up -d --buildWait until docker compose ps shows app as healthy. Do not go through the setup wizard: the restore replaces everything anyway.
Step 3: Take the newest backup out of the copy
This writes it into a folder called restored inside the Tesria folder. For a drive or share:
docker run --rm -e RESTIC_PASSWORD=your-passphrase -v "$PWD/restored:/out" -v /Volumes/your-drive:/t restic/restic -r /t/restic restore latest --target /outFor the cloud copy:
docker run --rm -e RESTIC_PASSWORD=your-passphrase -e AWS_ACCESS_KEY_ID=key -e AWS_SECRET_ACCESS_KEY=secret -v "$PWD/restored:/out" restic/restic -r s3:https://endpoint/bucket/tesria/files restore latest --target /outEither way, restored/backups/ now holds the dumps and their attachment archives.
Step 4: Restore it
Copy them into the new Tesria’s backup service, and list them:
docker compose cp restored/backups/. backup:/backups/
docker compose exec backup ls /backupsRestore the newest dump by its name, then restart Tesria so it picks it up:
docker compose exec backup /scripts/restore.sh db-<time>.dump
docker compose restart app
docker compose restart collabUse the dump’s real name in place of db-<time>.dump. The script also puts back the attachments archived with it.
Step 5: Check it
In this order, because each proves something different:
Sign in with your old account.
Open a page with a picture on it. That proves the attachments came back, not only the database.
Under Admin, Backups, check that both backup services are healthy.
Step 6: Before calling it done
Take a new backup straight away, and check the retention policy, which came back with the wiki.
Set up an offsite copy for the new computer, as in Offsite copies. The copy you restored from belonged to the old one.
A week later, check that the restore drill has run on the new computer. Until it has, nothing has proved the new copies can be restored.
If people used the local certificate, each device trusts the new server again: see Trusting the local certificate.
To a moment in time, from the cloud
The steps above bring the wiki back as it was at its newest nightly backup. The cloud copy can also go back to a chosen minute, because it holds the database’s record of changes. That needs the original BACKUP_ENCRYPTION_KEY as well as the cloud passphrase, and is a job for someone comfortable with PostgreSQL: the steps are in docs/backup-recovery.md in the Tesria folder.
Applies to | Tesria 0.5 and later |
|---|---|
Updated | September 24, 2026 |
Changes | Revised. |