Automated backups
Set it once. Never lose a server again.
VPS Snaps takes provider snapshots, database dumps, Docker volumes, files, and Kubernetes manifests on the schedule you pick — and writes every archive into a bucket you own.
Dashboard
Backup health overview
Servers
12
Backup Jobs
28
Storage Destinations
3
Failed (24h)
0
Recent backup runs (24h)
View allBackup run
4m ago
Backup run
2h ago
Backup run
6h ago
- Backups run daily
- 10k+
- Data protected
- 50TB+
- Uptime SLA
- 99.9%
- Setup time
- <5 min
VPS snapshots
Snapshots that never leave your provider account
A snapshot job calls your provider's own API — a DigitalOcean snapshot, a Hetzner image, an EC2 AMI, a GCE Machine Image. The image is created inside your account and stays restorable from your provider's console whether or not VPS Snaps is still in the picture. All we keep is the snapshot ID and the run that made it.
- DigitalOcean, Linode and Google Cloud connect over OAuth. Hetzner and Vultr take an API token, AWS a scoped IAM key.
- Retention prunes old images after each successful run. On EC2 we also delete the EBS snapshots behind a deregistered AMI — the usual source of storage you keep paying for and forget about.
- Vultr keys are IP-allowlisted by default, so setup shows you the address to allow instead of letting the key fail silently at 2am.
One caveat on Linode
A Linode job captures a single disk. The boot disk is detected automatically and a picker appears if your layout is non-standard — but a second data disk needs its own job, or a file backup alongside it.
Database backups
pg_dump and mysqldump, on a schedule you set
Point a job at any SSH-reachable host and VPS Snaps runs the dump tool already installed there. Output is gzipped on the server and relayed straight into your bucket as it is produced — never staged on the remote disk, never written to disk on our side, and hashed on the way past so the run records a checksum of exactly what landed.
What runs on your server
pg_dump -h 127.0.0.1 -p 5432 -U app acme_prod | gzip- PostgreSQL, MySQL and MariaDB, using the client binaries the host already has — no extension to install, no daemon to run.
- Schedules run hourly, daily, weekly, monthly, or on a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change instead of drifting an hour.
- Passwords and SSH keys are sealed with AES-256-GCM before they reach our database, and are never displayed again after you save them.
Not on the Free plan
Database backups need Standard or higher. The Free and Starter plans cover provider snapshots, file backups, and the Agent — the button below takes you to a plan that can actually run this.
Create backup job
Configure a new automated backup
Backup type
VPS Snapshot
Snapshot a server on a connected provider
Database
PostgreSQL, MySQL, or MariaDB
Docker
Volumes and compose files
File
Any file or directory over SSH
Kubernetes
Namespace manifests and volume snapshots
Job settings
Job name
Schedule
Retention (days)
Time of day
Timezone
File backups
tar over SSH, with the log to prove it ran
Give a job a list of paths and a list of exclude patterns. VPS Snaps runs tar on the server and pipes the archive straight into your bucket. A path that no longer exists is logged as a warning and skipped rather than failing the whole run, so one retired directory doesn't cost you a night's backup.
What runs on your server
tar czf - --exclude="node_modules" /var/www /etc/nginx- Exclude patterns keep node_modules, vendor and cache directories out of the archive and off your storage bill.
- tar's "file changed as we read it" warning is treated as a warning, not a failed backup — a busy log directory won't fail the run.
- Every step is timestamped and kept with the run, alongside the finished size and checksum, so a failure tells you which step broke.
web-01 site files
2h ago · triggered by scheduler
Status
Duration
1m 44s
Size
412 MB
Checksum (MD5)
9f2c4ab1e77d...
Storage path
files/cf7q2b1x/file-backup-cf7q2b1x-2026-09-02T02-00-06-118Z.tar.gz
Run logs
Docker backups
Volumes and compose files, captured together
For each named volume, VPS Snaps starts a throwaway Alpine container that mounts the volume and tars its contents — so the data is read through Docker rather than guessed at from a path on the host. Your compose files ride along in the same archive, with the docker inspect output for the containers you name.
- Each named volume is archived as its own tar.gz inside the run, so you can pull back one volume without unpacking the whole stack.
- Compose files and container inspect output travel with the data — the stack is described, not just its bytes.
- A volume that fails to archive is logged and the run continues with the rest. You get a partial backup and a warning rather than nothing at all.
Not on the Free plan
Docker backups need Standard or higher, same as database backups. The button below takes you to a plan that can run this.
Backup Jobs
Automated backup schedules
postgres-main nightly
Last run 6h ago
web-01 snapshots
Last run 9h ago
api-prod volumes
Last run 4m ago
staging-db weekly
Last run 3d ago
Application detection
Scan a server, get jobs for what's actually on it
VPS Snaps looks under /var/www, /home/*/public_html, the Forge and Cloudways application roots, and a few other usual suspects — for wp-config.php, .env, and Ghost's config.production.json. It identifies WordPress, Laravel, Craft CMS and Ghost, reads the database connection out of the config it finds, and offers to create the paired file and database jobs for you.
- Each detected app becomes two jobs: the document root as a file backup, and its database as a database backup, both pointed at the storage destination you pick.
- Credentials come straight out of the config the app already uses — wp-config.php defines, Laravel's DB_* keys, Craft's CRAFT_DB_* keys (falling back to the unprefixed Craft 3 names), so those jobs are ready to run.
- Sensible excludes come pre-filled per framework: vendor and node_modules for Laravel and Craft, Ghost's own content/logs directory for Ghost.
Where the scan stops
The search goes three directories deep from each root, so an install parked somewhere unusual won't be found — you can still add it by hand.
A Ghost site on SQLite rather than MySQL has no connection block to read, so it gets a file backup and no database job. Anything the scan can't identify at all is still listed with reasonable excludes for you to finish yourself.
Scan server
Looks for WordPress, Laravel, Craft CMS, and Ghost installs in common web-root locations. Database credentials are read automatically where the config format allows it.
Storage destination for created jobs
www/acme-blog
/var/www/acme-blog
File backupDatabase backup (acme_blog)
www/acme-app
/var/www/acme-app
File backupDatabase backup (acme_app)
sites/acme-docs
/home/deploy/sites/acme-docs
File backupDatabase backup (ghost_prod)
Kubernetes
Namespace manifests, plus volume snapshots where the cluster allows
Connect a cluster with its API server URL, CA certificate and a service account token you mint yourself — nothing is installed in-cluster. VPS Snaps exports the workload resources in each namespace you choose — Deployments, StatefulSets, DaemonSets, Services, Ingresses, ConfigMaps, Secrets, PersistentVolumeClaims, Jobs and CronJobs — into one archive in your bucket. Where your storage driver has a matching VolumeSnapshotClass, it also creates a CSI VolumeSnapshot for each PVC and waits for it to become ready.
The honest limits
This is a fixed list of well-known resource kinds, not full API-resource discovery. Custom resources from your operators are not included.
A PVC on a StorageClass with no CSI snapshot support is logged and skipped — its manifest is still backed up, its volume data is not.
Velero is detected and driven only if it is already installed in the velero namespace. VPS Snaps uses Velero, it doesn't install it.
Kubernetes Clusters
Manage cluster connections for Kubernetes backups
prod-eks
https://k8s-prod.internal:6443
Tested 1h ago
staging-k3s
https://10.0.4.12:6443
Tested 3h ago
eu-cluster
https://k8s-eu.internal:6443
Tested 5d ago
The Agent
For the servers you'd never open a port for
Run one Docker container inside your network. It opens an outbound WebSocket to VPS Snaps and waits for work — no inbound firewall rule, no port forward, no public IP, no SSH key handed to a third party. The agent does the backup locally and uploads to your bucket itself, so the data never passes through us at all.
- Works for anything with no route in from the internet: an office NAS, a colo database, a lab box behind CGNAT.
- Each agent has its own token and shows its last-seen time, so a machine that quietly stopped calling home is visible before you need its backups.
What the agent does and doesn't run
The agent handles Database, Docker and File jobs. Provider snapshots and Kubernetes backups go through the provider or cluster API instead, so they never needed an agent in the first place. File jobs run on every plan, including Free — Database and Docker through the agent need Standard or higher, the same as they do over SSH.
Agents
The agent connects out to us, not the other way around
office-nas
agt_7f2c4ab1…
Last seen just now
colo-db-01
agt_3e91d05c…
Last seen 3m ago
lab-runner
agt_b84a1f60…
Your backups land in a bucket you own
VPS Snaps has no storage of its own to sell you. Add an S3-compatible destination with your own credentials, and every archive we create is written there — under your retention policy, your region, and your bill.
Add more than one and point different jobs at different destinations — a hot bucket for nightly dumps, a cheaper cold one for monthly archives. Every destination has a connection test you can run whenever you like, and the list shows when each one last passed, so a rotated key turns up as a failed test rather than as a missing backup.
Add a destinationStorage Destinations
S3-compatible storage for your backups
Primary backups
acme-uploads/db · us-east-1
Tested 2h ago
Offsite copy
acme-offsite · auto
Tested 1d ago
Cold archive
acme-archive/2026 · eu-central-003
Tested 6d ago
Powerful features to give you peace of mind
Rest easy knowing your data and your reputation are safe.
- Bring your own storage
- Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3. You hold the keys and the data.
- Snapshots stay with your provider
- Provider snapshots are created through the provider's own API and never leave your account. We store the snapshot ID, not the image.
- Seven providers, one dashboard
- DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
- Schedules that fit your traffic
- Hourly, daily, weekly, monthly, or a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change.
- Retention that prunes itself
- Set how many days to keep. Older snapshots and archives are cleaned up after each successful run, so storage bills stay flat.
- Step-by-step run logs
- Every run records what it did, in order, with warnings and errors kept in place — so a failure tells you which step broke.
- Complete run history
- Status, duration, byte size, and what triggered each run, kept per job. Proof the backup ran, long after the night it ran.
- Checksummed on upload
- Every archive is hashed as it streams to your bucket and the checksum is stored with the run, so you can verify what landed.
- Run on demand
- Trigger any job by hand before a migration or a risky deploy, without touching its schedule or its retention window.
- Alerts on five channels
- Email plus Slack, Microsoft Teams, Google Chat, and Discord — on success, on failure, and on a job that missed its schedule entirely.
- Encrypted credentials
- SSH keys, database passwords, and storage secrets are sealed with AES-256-GCM before they touch the database.
- Team access with roles
- Invite your team into a shared workspace as owner, admin, or member, so backups outlive whoever set them up.

“VPS Snaps gave us one place to manage backups across DigitalOcean, AWS, and a few standalone servers. We can schedule provider snapshots, database dumps, and file backups without maintaining a bunch of separate scripts, and the run logs make it easy to confirm everything actually completed.”
Back up your first server free, forever.
No credit card, no trial countdown. Connect a provider, pick a schedule, and upgrade only when you outgrow the free plan.
No credit card required. Cancel anytime.