Peter van Arkel 5808800981 feat: link backup runs to snapshot records
Add a nullable SnapshotRecord foreign key to BackupRun and populate it
when run_pobsync_backup records a completed or failed snapshot. Keep the
existing snapshot_path for audit compatibility while making run-to-snapshot
navigation explicit in the database and admin.
2026-05-19 11:13:06 +02:00

pobsync

pobsync is a pull-based backup service. It runs on a central backup server and pulls data from remote machines via rsync over SSH.

The refactor direction is SQL-first:

  • Django is the management layer and source of truth.
  • SQLite is the default database; MariaDB is optional.
  • Backups still use the existing rsync snapshot engine internally.
  • Scheduling is handled by a Django/Docker scheduler process, not host cron.
  • Legacy YAML import/export exists only for migration and inspection.

Requirements

On the backup server or in the container:

  • Python 3.11+
  • rsync
  • ssh
  • SSH key-based access from the backup server to remotes

Local Development

python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install -e .
mkdir -p var
python3 manage.py migrate
python3 manage.py createsuperuser
python3 manage.py runserver

The admin is available at:

SQL-First Setup

Create global config:

pobsync configure-global --backup-root /mnt/backups/pobsync

Create a host config:

pobsync configure-host <host> --address <host-or-ip>

Run a backup:

pobsync backup <host> --prune

Create or update a schedule:

pobsync schedule <host> --cron "15 2 * * *" --prune

Run the scheduler:

pobsync scheduler --loop --interval 60

Plan or apply retention manually:

pobsync retention <host>
pobsync retention <host> --apply --yes --max-delete 10

Discover snapshots already present on disk:

pobsync discover-snapshots --host <host>

The pobsync executable is a thin wrapper around Django management commands. Direct Django access is also available:

pobsync django check
python3 manage.py run_pobsync_backup <host> --prune

Migration Helpers

Import existing legacy YAML configs:

python3 manage.py import_pobsync_configs --prefix /opt/pobsync

Export SQL config to legacy runtime YAML for inspection or one-off compatibility:

python3 manage.py export_pobsync_configs --prefix /opt/pobsync

These commands are migration helpers, not the normal operating model.

Docker With SQLite

docker compose up --build web

This starts Django on:

Run the scheduler alongside the web admin:

docker compose up --build web scheduler

The container persists /opt/pobsync and the SQLite database in Docker volumes.

Docker With MariaDB

docker compose --profile mariadb up --build web-mariadb

With the scheduler:

docker compose --profile mariadb up --build web-mariadb scheduler-mariadb

SQLite remains the default because it is enough for a single backup server and keeps deployment simple.

Current Architecture

The public command surface is Django-first. The old YAML/cron CLI has been retired from the pobsync entrypoint.

The remaining internal engine code still contains reusable backup primitives:

  • snapshot naming and metadata
  • rsync command construction and execution
  • retention planning and pruning
  • host locking

Next refactor targets:

  • Record discovered snapshots into SnapshotRecord.
  • Surface SnapshotRecord data through API/admin views instead of filesystem inspection.
  • Move more snapshot lifecycle details into typed domain objects.
  • Replace remaining dictionary-shaped config at engine boundaries.
  • Remove legacy YAML import/export once production migration no longer needs it.
Description
Rsync-based backup solution.
Readme 3.3 MiB
pobsync 1.2.0 Latest
2026-05-28 22:19:23 +02:00
Languages
Python 77.9%
HTML 19.6%
Shell 2.4%
Dockerfile 0.1%