bbchops/transcription
1
0
Fork 0
generated from john/python-template
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

V6.1 continue refining backup: switch to Synology Drive Client for remote backup
Quality Gate / gate (push) Failing after 1m10s
Details

Browse Source
This commit is contained in:
Jim Lancaster
2026-09-01 18:47:03 -05:00
parent 929f8d6de9
commit 75dc946123
8 changed files with 90 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/backup_restore.md
+18 -7
View File
@@ -1,19 +1,21 @@
# Backup and Restore (V6.0 Phase 4)
This guide defines operational backup/restore for clean-slate recovery of the Docker runtime and Synology replication.
This guide defines operational backup/restore for clean-slate recovery of the Docker runtime with host-level backups that Synology Drive can replicate.
## 1. Backup artifacts (clean-slate recovery set)
- Primary local backup location: `./data/backups`
- Primary local backup location: `DATABASE_BACKUP_DIR` (recommended production value: `/backup`)
- Local files created per run:
- `postgres-YYYYMMDD-HHMMSS.dump` (PostgreSQL custom dump via `pg_dump -Fc`)
- `backup-YYYYMMDD-HHMMSS.manifest` (artifact index)
- Synology files created per run (when `SYNOLOGY_BACKUP_DIR` is set):
- Optional Synology files created per run (when `SYNOLOGY_BACKUP_DIR` is set):
- `postgres-YYYYMMDD-HHMMSS.dump` (copied from local)
- `config-YYYYMMDD-HHMMSS.tar.gz` (deployment config snapshot: `.env.production`, `docker-compose.production.yml`, `deploy/cloudflared/config.yml` when present)
- `logs-YYYYMMDD-HHMMSS.tar.gz` (snapshot of `/app/data/logs`)
- `backup-YYYYMMDD-HHMMSS.manifest`
- Synology incremental media mirror (copied only if missing):
- Local app-data mirror (updated each run):
- `data/**`
- Local incremental media mirror (copied only if missing):
- `uploads/homepage.md`
- `uploads/documents/**`
- `uploads/photos/**`
@@ -28,21 +30,30 @@ sh deploy/backup/create_postgres_backup.sh
Environment overrides:
- `BACKUP_DIR` (default `./data/backups`)
- `BACKUP_DIR` (default `DATABASE_BACKUP_DIR`, then `./data/backups`)
- `APP_DATA_BACKUP_DIR` (default `${BACKUP_DIR}/data`)
- `UPLOADS_BACKUP_DIR` (default `${BACKUP_DIR}/uploads`)
- `BACKUP_RETENTION_DAYS` (default `14`)
- `SYNOLOGY_BACKUP_DIR` (if set, dump/config/log/manifest are copied to this mounted path and media is synced incrementally)
- `ENV_FILE` (default `.env.production`)
- `COMPOSE_FILE` (default `docker-compose.production.yml`)
Recommended production setup:
- Mount a host-visible folder into `/backup` for both `app` and `worker` services.
- Set `DATABASE_BACKUP_DIR=/backup` in `.env.production`.
- Leave `SYNOLOGY_BACKUP_DIR` empty when Synology Drive Client handles replication from the host folder.
Example with Synology mount:
```bash
SYNOLOGY_BACKUP_DIR=/mnt/synology-backups sh deploy/backup/create_postgres_backup.sh
```
## 2.1 Persisting Synology mount (LXC)
## 2.1 Optional direct Synology mount (LXC)
The backup copy step depends on a mounted NAS path. Manual `mount` commands are lost after reboot unless persisted.
This section is only needed when using direct container-side Synology copy via `SYNOLOGY_BACKUP_DIR`.
Manual `mount` commands are lost after reboot unless persisted.
Use the template (copy, edit placeholders, then run):