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 scheduler service, 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
• systemd for the recommended production deployment

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:

• http://127.0.0.1:8000/
• http://127.0.0.1:8000/admin/

Staff-only JSON endpoints are available at:

• http://127.0.0.1:8000/api/
• http://127.0.0.1:8000/api/status/

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.

Production With Systemd

The recommended production deployment is native systemd services on the backup server. This avoids Docker friction around SSH, filesystems, large backup mounts, and host-level service logs.

Recommended layout:

/opt/pobsync/app          # git checkout
/opt/pobsync/venv         # Python virtualenv
/etc/pobsync/pobsync.env  # settings and secrets
/var/lib/pobsync          # SQLite database, state, runtime SSH key files, static files
/backups                  # backup storage, or set POBSYNC_BACKUP_ROOT to another absolute path

Install OS packages first:

apt install python3 python3-venv rsync openssh-client

Clone or update the app at /opt/pobsync/app, then run:

cd /opt/pobsync/app
sudo scripts/install-systemd

The installer creates:

• pobsync-web.service for Gunicorn on 127.0.0.1:8010
• pobsync-worker.service for queued backup runs
• pobsync-scheduler.service for SQL-backed schedules
• /etc/pobsync/pobsync.env if it does not exist

Edit /etc/pobsync/pobsync.env before exposing the service:

POBSYNC_DJANGO_ALLOWED_HOSTS=backup.example.com,localhost,127.0.0.1
POBSYNC_DJANGO_CSRF_TRUSTED_ORIGINS=https://backup.example.com
POBSYNC_BACKUP_ROOT=/backups
POBSYNC_WEB_BIND=127.0.0.1:8010

Restart after changes:

sudo systemctl restart pobsync-web pobsync-worker pobsync-scheduler

Check service state and logs:

systemctl status pobsync-web pobsync-worker pobsync-scheduler
journalctl -u pobsync-worker -f

Update an existing native install:

cd /opt/pobsync/app
git pull
sudo scripts/install-systemd

Use an existing reverse proxy by forwarding to http://127.0.0.1:8010. To install a simple nginx site file as a starting point:

sudo scripts/install-systemd --with-nginx --server-name backup.example.com

Docker With SQLite

Docker Compose is still useful for local development and disposable test installs. Native systemd is preferred for production backup servers.

docker compose up --build web

This starts Django on:

• http://127.0.0.1:8010/
• http://127.0.0.1:8010/admin/
• http://127.0.0.1:8010/api/
• http://127.0.0.1:8010/api/status/

Run the scheduler alongside the web admin:

docker compose up --build web scheduler worker

The web service runs Django through Gunicorn and serves static files with WhiteNoise. The container persists /opt/pobsync and the SQLite database in Docker volumes. Backup data is always available at /backups inside the containers. By default this uses ./backups on the host. Override the host-side mount with POBSYNC_BACKUP_ROOT:

POBSYNC_BACKUP_ROOT=/mnt/backups/pobsync docker compose up --build web scheduler worker

The Django setup UI keeps the backup root fixed at /backups; only the Docker mount decides which host directory that points to.

Django-Managed SSH Keys

SSH keys can be managed from the Django UI at /ssh-credentials/. Add a private key there, optionally paste known_hosts entries, and select the credential either as the global default or as a per-host override.

When a backup starts, the worker writes the selected key to $POBSYNC_HOME/state/ssh-credentials/<id>/identity with 0600 permissions and injects IdentityFile into the rsync SSH command. If known_hosts is configured, the worker also writes a matching known_hosts file and injects UserKnownHostsFile.

Docker With MariaDB

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

With the scheduler:

docker compose --profile mariadb up --build web-mariadb scheduler-mariadb worker-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. Discovered snapshots are stored in SnapshotRecord, including the base snapshot metadata and a nullable SQL link to the base record when it is known. The Django retention command plans from SnapshotRecord instead of rediscovering snapshots from the filesystem. Post-backup pruning from Django also uses the SQL retention service after the completed snapshot is recorded. Staff-only JSON endpoints expose service status, hosts, snapshots, and backup runs for lightweight inspection. Staff-only dashboard views expose the same operational state through Django templates. Host pages include a safe snapshot discovery action that records existing snapshots into SQL. Host pages also include a read-only SQL retention plan view before any destructive pruning action. Schedules can be created or updated from host pages using the same SQL-backed scheduler model. Host config can be edited from host pages while keeping host identity stable.

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:

• 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.