oibot/Tobserver
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add backup for bictoin-pulse db

Browse source
This commit is contained in:
Tobias Ostner 2026-07-30 12:45:29 +07:00
parent 5753bf9e33
commit 532a8ed613
5 changed files with 179 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

78
docs/bitcoin-pulse-postgresql.md
View file

@ -19,9 +19,9 @@
change after testing backups, startup, and application compatibility.
The named volume belongs to the rootless Podman account and survives container
removal, service recreation, and NixOS generation changes. Backup and restore
portability is handled separately by BIT-23; do not copy Podman's private
storage directly.
removal, service recreation, and NixOS generation changes. Backup portability
is provided by the logical Restic backup described below; do not copy Podman's
private storage directly.
## Human-managed secrets
@ -41,8 +41,76 @@ Nix expression, command argument, shell history, log, or pull-request text. The
agent change intentionally declares only the secret paths; it does not modify
or decrypt `secrets/tobserver.yaml`.
`sops-nix` materializes each credential as a restricted runtime file. Before
container startup, the service stages private copies owned by PostgreSQL's uid
## Logical off-server backups
`modules/bitcoin-pulse.nix` declares the daily
`restic-backups-bitcoin-pulse.service` and its systemd timer. The job:
1. Requires the PostgreSQL container service to be available.
2. Creates a consistent custom-format `pg_dump` through the loopback database
port using the administrator password as a systemd credential.
3. Uploads the dump to the separate Restic repository
`b2:tobcloud-backup:bitcoin-pulse`.
4. Removes the local staging dump whether the upload succeeds or fails.
5. Retains 7 daily, 4 weekly, and 12 monthly snapshots.
The timer starts the job daily between 03:00 and 03:30 Europe/Berlin time. It is
persistent, so systemd starts a missed job after the next boot. A failed dump,
upload, or prune operation makes the unit fail and leaves details in the system
journal. A run that exceeds six hours is stopped and marked failed so it cannot
block future timer runs indefinitely. Alert delivery and automated restore
testing are intentionally outside this deployment scope.
### Backup credentials
The existing `tobcloud-backup` bucket and its Backblaze application key are
shared with the Nextcloud backup. Before deploying, confirm that the key is not
restricted only to the `nextcloud/` prefix and can also access
`bitcoin-pulse/`. For the native B2 backend, it needs `listBuckets`,
`listFiles`, `readFiles`, `writeFiles`, and `deleteFiles` because Restic must
find the bucket and retention must remove expired repository files.
Generate a separate, strong Restic repository password and retain it in the
approved password manager. Losing this password makes every backup in the
repository unusable.
Use `sops secrets/tobserver.yaml` from an authorized workstation to add:
```yaml
restic:
bitcoin-pulse-password: <new Restic repository password>
backblaze:
tobcloud-backup-env: |
B2_ACCOUNT_ID=<shared application key ID>
B2_ACCOUNT_KEY=<shared application key>
```
Rename the existing `backblaze/nextcloud-env` SOPS entry to
`backblaze/tobcloud-backup-env`; do not keep a second plaintext copy of the same
credential. Commit only the encrypted result. The NixOS configuration will not
activate successfully until the renamed Backblaze key and the new Restic
password exist.
### Initial backup verification
After adding the credentials and deploying the reviewed NixOS generation, run
the first backup manually rather than waiting for the timer:
```console
sudo systemctl start restic-backups-bitcoin-pulse.service
sudo systemctl status restic-backups-bitcoin-pulse.service
sudo journalctl -u restic-backups-bitcoin-pulse.service -b --no-pager
sudo restic-bitcoin-pulse snapshots
systemctl list-timers restic-backups-bitcoin-pulse.timer
```
The service must exit successfully, `snapshots` must show the new off-server
snapshot, and `/var/backup/bitcoin-pulse` must not retain a dump after the job.
The journal must not contain any credential value.
For PostgreSQL, `sops-nix` materializes each credential as a restricted runtime
file. Before container startup, the service stages private copies owned by
PostgreSQL's uid
inside the rootless user namespace. The copies are mounted read-only and are
removed from the host runtime directory after PostgreSQL reports healthy and
again when the unit stops. The application and migration SOPS files remain