# ard-007: backup bucket and service on the CRDT sync server

Satisfied by: task-022, task-023

## Problem

Schist's persisted data must be recoverable (req-067).

It has already been decided that Schist will persist data in IndexedDB on the
Web GUI (ard-005), in SQLite on the desktop GUI (ard-001) and in SQLite on the
CRDT sync server (ard-006).

## Decision

Schist must have a backup bucket on separate storage media to the CRDT sync
server and the users' machines. Schist must have a backup service running on the
same machine as the CRDT sync server, which regularly makes backups and stores
them in the bucket.

## Discussion

In order for data to be recoverable, there must be backups. There are no
alternatives to this.

The backups could be stored on the same media, but this is less secure than
storing it on separate media.

You could back-up the Web GUI, the desktop GUI and the CRDT sync server.
However, once the CRDT sync server is working, all the other components can rely
on the CRDT sync server's back-ups, and in the meantime, the user can be
responsible for making the data on their own machines secure, for example, by
backing up their entire hard drive. It's generally not done for user apps to be
responsible for their own backups of local data for this reason.

Therefore, we will have a bucket on its own media, backing up only the CRDT sync
server. In order for the backups to get stored there, we must have some service
making the backups. And in order for the service to have easy access to the
SQLite file which it is backing up, it makes sense for the service to run on the
same machine as the SQLite file, and therefore the same machine as the CRDT sync
server.

HTTPS is an acceptable communications protocol. No alternatives were considered.

## Consequences

There must be a documented process for recovering the server machine from a
backup after a failure: otherwise, the backups will be of no use in meeting the
need for the data to be recoverable (req-067).