How backups work

Two backup services run beside Tesria. Each keeps its own kind of copy, for a different kind of trouble, and both report to the Backups tab under Admin.

flowchart LR
  subgraph server["The computer Tesria runs on"]
    app["Tesria"] --> db[("Database")]
    app --> files["Attachments"]
    db -->|"every change, as it happens"| pgb["pgbackrest service"]
    pgb -->|"full copy weekly, changes daily"| pgv[("pgbackrest volume, encrypted")]
    db -->|"daily dump"| bk["backup service"]
    files -->|"daily archive"| bk
    bk --> bkv[("backups volume")]
  end
  pgb -.->|"reports"| tab["Backups tab"]
  bk -.->|"reports"| tab
  bkv -.->|"copied after each backup"| off["Offsite copies"]
  pgb -.->|"streams to the cloud"| off

Read it from the left: Tesria writes to its database and its attachments. The pgbackrest service records every change to the database as it happens and keeps full copies; the backup service takes a daily dump of the database and an archive of the attachments. Both report to the Backups tab, and both can send copies away from this computer, which the dotted lines show (see Offsite copies).

How far back each copy can take you

Not every copy can bring back the same thing. The difference that matters most is how much recent work you could lose: a copy that records every change can put the wiki back as it was a minute before something went wrong, while a daily copy can only put it back as it was at the last daily backup, up to a day earlier.

• On this computer, the continuous backups (the pgbackrest service): the database to any second you choose. Attachments come from the daily archive.

• On this computer, the daily backups (the backup service): the database and the attachments as they were at the last daily backup.

• Cloud storage: both of the above. It is the only offsite copy that receives every database change as it happens, so it can restore to any second, even if this computer is gone.

• A network drive: the daily backups only. After losing this computer, you get the wiki back as it was at the last daily backup, and anything written since is lost.

• A removable drive: the daily backups, as of the last time someone chose Copy now. Often the oldest copy of all.

Which should you use?

• Cloud storage, if you can use only one. It loses the least work, and it survives a fire, flood or theft that takes this computer, and anything else in the building, with it.

• A network drive as well, if you have one. Restoring from it is faster than downloading from the cloud, it costs nothing more, and it stays in your hands. Turn on the drive’s own snapshots, so the copies survive even if this computer is broken into. On its own, remember what it cannot do: it may be up to a day behind, and it sits in the same building.

• A removable drive for a copy you take somewhere else, such as home, if you have no cloud storage. It is only as recent as the last time someone copied to it.

How to set each one up is in Offsite copies.

Database dumps and uploads

The backup service. Once every 24 hours (BACKUP_INTERVAL_HOURS), it takes a dump of the database, a complete copy in one file, and an archive of every attachment, both at the same moment.

• What it gets back: the wiki as it was when that copy was taken.

• Where: the backups volume, as db-<time>.dump and uploads-<time>.tar.gz.

• Good for: going back to a known day, moving Tesria to a new machine, and offsite copies. A dump can be read on any computer.

Physical backups and point-in-time recovery

The pgbackrest service. It takes a full copy of the database’s files once a week (BACKUP_FULL_EVERY_DAYS) and a smaller one holding only the changes on the other days, and in between it records every change the database makes, as it happens.

• What it gets back: the database as it was at any moment you choose, to the second.

• Where: the pgbackrest volume, always encrypted with BACKUP_ENCRYPTION_KEY.

• Good for: undoing something that happened at a known time, such as a mass deletion at 2:32 this afternoon.

It holds the database only. Attachments come from the dumps and uploads backups.

The Backups tab

• A card for each service: whether it is healthy, when it last worked and next runs, how far back you can restore, the disk space left, and when a restore was last tested.

• Back up now asks both services for a backup. Each picks the request up within a minute.

• Test restore restores a backup somewhere temporary and checks it, without touching the wiki. A backup that has never been restored has not been proved to work.

• Disk space shows what the wiki, its backups and everything else take on this computer.

• Storage targets lists the offsite copies. See Offsite copies.

• Retention policy decides how long backups are kept. See Retention.

• Backups lists every backup kept, each with Test restore and, for the owner, Restore. See Restoring and undo.

• Recent runs lists what the services did, each with its Log.

What each person may do on the tab depends on their role: see Backups (administration).

When something goes wrong

A backup that fails, a service that stops checking in, a failed restore test or a disk running low raises an alert for every administrator: in the bell, under Admin, Security, and by email once email is set up. A failed backup is tried again after 15 minutes, then at longer and longer gaps up to six hours, rather than waiting a whole day.

From the command line

Everything the tab does can also be done on the server, from the Tesria folder, which helps when the wiki itself will not start: