Restoring and undo

A restore replaces the whole wiki with a backup: every page, comment, attachment and account goes back to how it was when the backup was taken. It is the one thing on the Backups tab that uses a backup rather than making one, so Tesria asks you to be sure, keeps what it replaces, and lets you undo it.

Before you restore

• A bad edit or a deleted page does not need a restore. Put it right from the page’s history, or the space’s trash. A restore also takes back everyone else’s work since the backup.

• Only the owner can restore, unless the owner has given the Restore a backup right to a role. Others do not see the Restore button.

• Tell people. The wiki is read-only while it runs, and people who signed in after the backup was taken have to sign in again.

Restoring a backup

Step 1: Find the backup

Choose Admin, then Backups, and scroll to the Backups list. Each row has Test restore and, in red, Restore. Choose Restore on the one you want.

Step 2: Read what it will do

Tesria says when the backup was taken and what has been written since, which the restore takes back.

Step 3: Confirm

Type the backup’s name where it asks, and your password. Someone who signs in with SSO and has no Tesria password gives a code from their authenticator app instead. Then choose Restore now.

What happens next

1. A backup is taken first, of the wiki as it is now. It cannot be skipped, and nothing is restored if it fails.

2. The wiki becomes read-only for everyone. Reading works; saving waits, and open editors are closed so they cannot write old pages back.

3. The backup is restored beside the live wiki and checked. A backup from a newer version of Tesria is refused.

4. The restored copy takes the live wiki’s place, in a moment. The wiki it replaces is kept, not deleted.

5. Tesria restarts, and your page comes back by itself.

While it runs, the Backups tab shows A restore is in progress with Stop the restore, which works until step 4. Afterwards, the restore is recorded in the audit log and raised as a critical alert for every administrator.

To a moment in time

A physical backup’s row restores to any second it covers: its Restore also asks for the time to roll forward to, between the earliest and latest it can reach. Use it when you know when things went wrong, for example to just before a mass deletion. It keeps no copy of what it replaces; its undo is another restore, to the moment the first one began, which the page offers.

Undo

After a restore from a dump, the Backups tab shows The copy kept before the last restore, with two buttons:

• Undo the restore puts the kept copy back, taking a backup of the wiki as it is now first. Type UNDO and your password to confirm.

• Remove the copy deletes it to free the disk. Type REMOVE and your password. After that, the restore cannot be undone.

The kept copy is also removed on its own when the retention policy would remove a backup taken at the time of the restore. While retention is off, it stays until someone removes it.

From the command line

When the wiki itself will not start, the same restore runs on the server, from the Tesria folder. List the dumps first:

docker compose exec backup ls /backups

To see every step without changing anything, add -e RESTORE_DRY_RUN=1:

docker compose exec -e RESTORE_DRY_RUN=1 backup /scripts/restore.sh db-20260920T030000Z.dump

Then run it for real, with the name of the dump you want:

docker compose exec backup /scripts/restore.sh db-20260920T030000Z.dump

It takes the same safety backup first, restores beside the live wiki, and puts back the attachments archived with the dump. Then restart Tesria, and the live editing service after it, so they pick up the restored database:

docker compose restart app
docker compose restart collab

A restore run this way is not recorded as one, so the next daily audit check warns once that the audit log is shorter than before. That is expected: the log went back with everything else.