mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 05:26:47 +00:00
Maurice
e62dceb4bb
The scheduled backup archived travel.db directly. The archiver reads its entries during finalize(), so a WAL checkpoint writing pages back mid-stream tore the copy — and the -wal that would make it recoverable isn't in the zip. The manual path was moved to VACUUM INTO for exactly this reason; the scheduler never followed. It calls the same createBackup() now, which also gets it the encryption key and plugin data it was missing, so a scheduled backup is finally restorable onto another install. The pre-rotation copy in migrate-encryption.ts had the same problem: a plain file copy of a live WAL database, and it is the operator's only rollback if a key rotation goes wrong. Auto-backups now exclude the re-derivable photo caches, matching manual ones.
91 lines
4.2 KiB
Markdown
91 lines
4.2 KiB
Markdown
# Backups
|
||
|
||
TREK stores all data in a single SQLite database (`travel.db`) plus an `uploads/` directory of attachments, cover photos, and avatars. The Backup panel lets you create, download, restore, and schedule backups of both.
|
||
|
||
## Where to find it
|
||
|
||
**Admin Panel → Backup** tab.
|
||
|
||
|
||
|
||
## What a backup contains
|
||
|
||
A backup is a ZIP archive with these entries:
|
||
|
||
| Entry | Contents |
|
||
|---|---|
|
||
| `travel.db` | The full SQLite database |
|
||
| `uploads/` | All uploaded attachments, covers, and avatars |
|
||
| `plugins-data/` | Each installed plugin's own database + files (present only if plugins are installed) |
|
||
| `plugins-code/` | The installed plugin code, so a restore is self-contained (dev-linked plugins are skipped) |
|
||
|
||
**Also included:** the at-rest encryption key, unless you supply it through the `ENCRYPTION_KEY` environment variable — in that case the file is not the source of truth and is left out. Bundling it is what makes a backup restorable onto a different install, and it makes the ZIP as sensitive as the key itself: store and transfer it accordingly. See [Encryption-Key-Rotation](Encryption-Key-Rotation).
|
||
|
||
## Manual backup
|
||
|
||
Click **Create Backup** in the Backup tab. The server creates the ZIP and makes it available for download. Up to 3 manual backups can be created per hour per IP address (rate-limit window: 1 hour).
|
||
|
||
You can also download or delete any existing backup from the list.
|
||
|
||
## Restoring a backup
|
||
|
||
You can restore from:
|
||
|
||
- **A stored backup** — click **Restore** next to any backup in the list.
|
||
- **An uploaded ZIP** — click **Upload & Restore** and select a backup file from your computer (maximum upload size: 500 MB by default, configurable with the `BACKUP_UPLOAD_LIMIT_MB` environment variable — see [Environment-Variables](Environment-Variables)).
|
||
|
||
Before restoring, TREK runs integrity checks on the uploaded database:
|
||
|
||
1. **SQLite `PRAGMA integrity_check`** — verifies the database file is not corrupt.
|
||
2. **Required tables present** — confirms the file contains `users`, `trips`, `trip_members`, `places`, and `days`. Files missing any of these are rejected as not being a valid TREK backup.
|
||
|
||
> **Warning:** Restoring replaces all current data. Back up your current state first if you want to keep it.
|
||
|
||
> **Plugins & restart:** `travel.db` and `uploads/` are swapped in immediately. Plugin data and code are **staged** and applied on the **next server restart** — the running plugins hold their databases open, so they can't be swapped live (the same reason the bundled encryption key only takes effect on restart). Restart the server after restoring an instance that uses plugins.
|
||
|
||
## Auto-backup
|
||
|
||
Enable scheduled backups in the **Auto-Backup** section of the Backup tab.
|
||
|
||
**Interval** options:
|
||
|
||
- Hourly
|
||
- Daily
|
||
- Weekly
|
||
- Monthly
|
||
|
||
**Retention** (`Keep last … days`) — enter a number of days. Backups older than that many days are pruned after each auto-backup run. Set to **0** to keep all backups indefinitely (no pruning).
|
||
|
||
**Schedule** options (depend on interval):
|
||
|
||
- **Hour** — time of day for daily, weekly, and monthly backups (0–23).
|
||
- **Day of week** — Sunday through Saturday (for weekly backups).
|
||
- **Day of month** — 1–28 (for monthly backups). Day 29–31 is excluded to avoid months with fewer days.
|
||
|
||
Auto-backup files are named `auto-backup-<timestamp>.zip` (manual backups use `backup-<timestamp>.zip`).
|
||
|
||
After each auto-backup run, **auto-backup files** older than `keep_days` are pruned. Manual backups are never pruned — delete those yourself when you no longer need them. Set `keep_days` to `0` to disable pruning entirely.
|
||
|
||
## Before updating TREK
|
||
|
||
Always create a manual backup before updating. See [Updating](Updating).
|
||
|
||
## Audit log
|
||
|
||
The following actions are recorded in the [Audit-Log](Audit-Log):
|
||
|
||
| Action key | When |
|
||
|---|---|
|
||
| `backup.create` | Manual backup created |
|
||
| `backup.restore` | Restore from stored backup |
|
||
| `backup.upload_restore` | Restore from uploaded ZIP |
|
||
| `backup.delete` | Backup deleted |
|
||
| `backup.auto_settings` | Auto-backup settings saved |
|
||
|
||
## See also
|
||
|
||
- [Encryption-Key-Rotation](Encryption-Key-Rotation)
|
||
- [Admin-Panel-Overview](Admin-Panel-Overview)
|
||
- [Security-Hardening](Security-Hardening)
|
||
- [Updating](Updating)
|