Product documentation

Operate with clarity.

Architecture, policy design, storage, endpoint workflow, recovery, security, and the operational practices that make backups dependable.

Architecture

The web service provides the interface, API, enrollment endpoints, and scheduler. PostgreSQL stores durable configuration and job state. A separate worker claims queued jobs using database locks and performs transfers and retention work.

Browser / Authentik


Web + scheduler ───── PostgreSQL
│ │
├── Proxmox └── policies, jobs, history
├── Endpoints

Background worker ── Google Drive
└──────────── Local volume / SMB

Run one web replica because the scheduler is single-leader. Workers can be scaled horizontally.

Server backup

Enroll multiple Proxmox hosts, discover guests through the API, and create snapshot-mode vzdump archives. SSH/SFTP transfers completed archives to the worker.

  • Use a dedicated, scoped Proxmox API token.
  • Install a dedicated SSH public key and verify the fingerprint out of band.
  • Enable, pause, edit, delete, or run policies from the schedule builder.
  • Restore QEMU backups with an optional target host, VM ID, and name.
Clustered Proxmox root keys are commonly stored in /etc/pve/priv/authorized_keys. Verify the host key with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub.

Endpoint backup

The Windows package installs a service and tray application. The service enrolls using a one-time access key, checks in over outbound HTTPS, inventories drives, compresses selected folders locally, and uploads restartable chunks.

  1. Create an access key in Endpoint settings.
  2. Install the MSI interactively or through GPO.
  3. Approve the device under Endpoint Backup → Discovery.
  4. Browse its drives, choose folders, and create a policy.
msiexec /i SquishyBackupEndpoint-0.2.0-x64.msi /qn ^
SERVERURL="https://backup.example.com" ^
ACCESSKEY="sbak_..."

Storage and retention

Every server and endpoint policy can use Google Drive, local/SMB storage, or both. Cloud and local destinations may share a schedule or run independently—for example, daily NAS copies and a weekly off-site copy.

  • Google OAuth: personal My Drive storage.
  • Shared Drive service account: Google Workspace Shared Drives.
  • Filesystem: a Docker-visible persistent path.
  • SMB 2/3: direct Windows or NAS share access.

Limit retention by copy count, age, or both for each destination.

Notifications and status

Configure global defaults and override them per policy. Send successful, failed, missed, or all events through SMTP, Microsoft Graph/Azure App email, webhook POST, Discord, or MQTT. MQTT discovery exposes backup state to Home Assistant.

Recovery

  • Confirm archive presence and size at each destination.
  • Test restores using a non-production VM ID.
  • Boot and validate the guest or inspect endpoint archive contents.
  • Record recovery time and manual dependencies.
  • Repeat after major platform and storage changes.
The current Proxmox path uses qmrestore for QEMU guests. LXC recovery needs the separate pct restore workflow.

Security

  • Use HTTPS for the interface and endpoint connections.
  • Never commit .env, OAuth secrets, service-account files, or SSH keys.
  • Preserve and protect the credential-encryption key.
  • Restrict Proxmox tokens and SMB accounts to minimum access.
  • Keep a tested local administrator for SSO recovery.
  • Update images regularly and test recovery.

Licence and permitted use

SquishyBackup is source available: the code can be inspected, used, and modified for personal, educational, evaluation, and internal non-commercial purposes. Selling, relicensing, or offering SquishyBackup as a paid hosted product is prohibited without a separate commercial agreement.

Why not simply “open source”? A no-resale or non-commercial restriction does not meet the formal Open Source Definition. “Source available, non-commercial” states the permission accurately.

The intended model is based on the PolyForm Noncommercial License 1.0.0. The repository licence file is the authoritative grant.