Product documentation

Operate with clarity.

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

Architecture

The web service provides the interface, APIs, 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
        ├── n8n APIs
        ▼
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, inventories drives, compresses selected folders locally, and uploads restartable chunks over outbound HTTPS.

  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_..."

n8n workflow backup

SquishyBackup connects to the public API on each self-hosted n8n instance. API keys are encrypted at rest. The workflow browser can create a policy for one workflow or a dynamic policy for all active workflows.

Policy behavior

  • An individual policy exports the selected workflow on each run.
  • The all-active policy lists workflows again at execution time and exports every item whose active flag is true.
  • Newly activated workflows are included automatically; deactivated workflows are skipped.
  • Every workflow has a separate JSON recovery point and retention is calculated per workflow.
  • Cloud and local destinations can run together or on independent schedules.

Restore behavior

A restore creates a new inactive workflow on the selected enrolled n8n instance. You can provide a new workflow name. The destination must already provide compatible node types and credentials.

Workflow definitions only. n8n's workflow API does not export credential secrets. Recovery points also exclude execution history, database content, community-node installation packages, and binary data. Maintain a separate n8n database and configuration backup for full disaster recovery.

Storage and retention

Every server, endpoint, and n8n 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. All-active n8n retention applies those limits independently to each workflow.

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 recovery-point presence and size at each destination.
  • Test VM restores using a non-production VM ID.
  • Restore n8n definitions to a test instance and validate credentials and nodes.
  • Inspect endpoint archive contents.
  • Record recovery time and manual dependencies.
The current Proxmox path uses qmrestore for QEMU guests. LXC recovery needs the separate pct restore workflow.

Security

  • Use HTTPS for the interface, endpoints, and n8n connections.
  • Never commit .env, OAuth secrets, service-account files, API keys, or SSH keys.
  • Preserve and protect the credential-encryption key.
  • Restrict Proxmox tokens, n8n API keys, 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 under the PolyForm Noncommercial License 1.0.0. Personal, educational, research, charitable, public-sector, and other noncommercial uses are permitted. Commercial use, resale, paid hosting, and commercial redistribution require separate permission.

Why not simply “open source”? A noncommercial restriction does not meet the formal Open Source Definition. “Source available, noncommercial” states the permission accurately.

The repository LICENSE file is the authoritative grant.