diff options
| author | Owen Jacobson <owen@grimoire.ca> | 2024-10-10 01:01:05 -0400 |
|---|---|---|
| committer | Owen Jacobson <owen@grimoire.ca> | 2024-10-10 01:06:32 -0400 |
| commit | d173bc08f2b699f58c8cca752ff688ad46f33ced (patch) | |
| tree | dd57554f3bf0ba0e8b57a65c31eac55c59feb9f9 /docs | |
| parent | 319721717331bb414f86543a4ea1a115c25329a0 (diff) | |
Automatically delete database backups if automatic restore is successful.
Operational experience with the server has shown that leaving the backup in place is not helpful. The near-automatic choice is to immediately delete it, and the server won't start until it has been deleted. If the backup restore succeeded, then we know the user has a copy of their database, since the sqlite3 online backups API promises to make the target database bitwise-identical to the source database, so there's little chance the user will need a duplicate.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ops.md | 8 |
1 files changed, 6 insertions, 2 deletions
diff --git a/docs/ops.md b/docs/ops.md index 8f21c79..02644c2 100644 --- a/docs/ops.md +++ b/docs/ops.md @@ -2,6 +2,10 @@ ## Upgrades -`hi` will automatically upgrade its database on startup. Before doing so, it will create a backup of your database (at `.hi.backup`, or controlled by `--backup-database-url`). If the migration process succeeds, this backup will be deleted automatically. If the migration process _fails_, however, the backup will be left in place. In addition, `hi` will attempt to restore your existing database from the backup before exiting. +`hi` will automatically upgrade its database on startup. Before doing so, it will create a backup of your database (at `.hi.backup`, or controlled by `--backup-database-url`). If the migration process succeeds, this backup will be deleted automatically. If the migration process _fails_, however, `hi` will attempt to restore your existing database from the backup before exiting. If the restore process also fails, then both the backup database and the suspected-broken database will be left in place. -`hi` will not start if the backup database already exists. To restart `hi` after a failure, move the backup database aside. Once you are satisfied that `hi` has recovered successfully, you can delete it. If you need to restore the database manually, you can also copy it overtop of your database using normal filesystem tools (`cp -a .hi.backup. hi`, for example). +To avoid destroying backups that may still be needed, `hi` will not start if the backup database already exists. **There is no catch-all advice on how to proceed**, but you can try the following: + +* Start the server with **a copy** of the backup database, and determine if any data has been lost. If not, shut it down, replace your main database by copying the backup, and carry on. + +The `hi` database is an ordinary file. While the server is not running, it can be freely copied or renamed without invalidating the data in it. |