The questions we’d ask before trusting anyone with our backups.

We open an SSH session to your server and run, for PostgreSQL, pg_dump -h <host> -p <port> -U <user> <database> | gzip. The compressed stream is never written to disk on your server and never written to disk on ours — it goes straight into a multipart upload to your bucket as it is produced, hashed on the way past. MySQL and MariaDB use the equivalent mysqldump pipeline, and the object lands as <database>-<timestamp>.sql.gz. MongoDB is the one that differs: mongodump --archive --gzip compresses and frames the stream itself rather than being piped through gzip, so the object is <database>-<timestamp>.archive.gz and it goes back in with mongorestore rather than a SQL client — from the dashboard like the others, or by hand.

pg_dump takes an ACCESS SHARE lock: reads and writes carry on normally, and only schema changes block. mysqldump runs with MySQL's default options, which take a read lock across the tables in the database being dumped for the duration of the dump — so schedule MySQL jobs for a quiet hour rather than your traffic peak.

Yes, indirectly. Set the job's database host and port to the managed endpoint and attach it to any SSH server allowed to reach that endpoint. The dump runs from that box, which means it needs the matching pg_dump or mysqldump client installed and the managed database's firewall has to permit its address. We connect to your server; your server connects to your database.

A single tar.gz containing one archive per named volume you selected — each produced by a throwaway alpine container that mounts the volume — plus a copy of every compose file path you listed and docker inspect output for the containers you named. Volumes are staged in /tmp/vpssnaps-<run-id> on the server first, so you need roughly the compressed size of those volumes free in /tmp. The staging directory is removed when the run finishes.

That volume is recorded as a warning and the run continues with the rest. It is deliberate — one unreadable volume should not cost you the other nine — but it does mean a run can finish successfully with a volume missing from the archive. The run log names every volume it archived, so check it if that distinction matters to you.

It is skipped, logged as a warning, and the run carries on. Only if none of the configured paths exist does the run fail outright. Exclude patterns are passed through to tar --exclude verbatim, and tar strips the leading slash, so an archive of /var/www extracts as var/www — it will not overwrite the root of wherever you unpack it.

If Velero is already installed in the cluster, we detect it and drive it, and your Velero configuration decides what happens. If it is not, we authenticate with a service account token, export the manifests for the namespaces you chose to your bucket, and request a CSI VolumeSnapshot for each persistent volume. Volumes whose storage driver has no CSI snapshot support are skipped and logged rather than silently dropped. We do not install Velero for you.

Daily on Free and Starter, every 12 hours on Standard, and as often as every 5 minutes on Pro and Agency. The schedule form offers manual, every 5 minutes, hourly, every 12 hours, daily, weekly, and monthly, with a time of day and an IANA timezone for the last three — so a 2am job runs at 2am where you are, not at 2am UTC.

Yes. Any job can be run on demand from the dashboard — before a migration, before a risky deploy, before you touch the database — without disturbing its schedule or its retention window.

For a database or file run, from the dashboard: open the run, choose the server to restore onto, and confirm. Everything else is still by hand, from your own storage, with standard tools — a Docker volume: docker run --rm -v myvolume:/target -v /path/to/backup:/backup alpine tar xzf /backup/myvolume.tar.gz -C /target. A provider snapshot: restore it from your provider's console, where it already lives. And any archive at all can be restored by hand if you would rather not go through us: gunzip -c mydb-2026-08-31T02-00-00Z.sql.gz | psql mydb. The help centre carries the exact commands for each backup type.

For database and file backups, yes. Open a successful run, pick the server to restore onto, and it downloads the archive, checks it against the checksum recorded when the backup was taken, backs up whatever it is about to overwrite, and only then applies it — and it refuses to go ahead if that safety backup fails. There is also a check-only mode that downloads and verifies without changing anything, which is the honest way to answer 'would this actually restore?'. Two limits worth knowing: Docker and Kubernetes runs cannot be restored from the dashboard yet, and a provider snapshot is rebuilt from your provider's console, where it already lives. One thing to be clear about rather than surprised by: a database restore replaces the tables the backup contains, so a table created after the backup survives it — you get the backup's contents back, not a byte-exact reset. Every artefact also stays an ordinary .sql.gz, .tar.gz or provider snapshot, so the manual path still works whether or not VPS Snaps is online, reachable, or still in business.

We record the byte size and an MD5 checksum computed as the archive streamed into your bucket, alongside the full run log, so you can verify that what landed is what left. We do not test-restore it for you. Restoring into a scratch database or a throwaway container once a quarter is the only thing that genuinely proves a backup — a backup you have never restored is a hypothesis.

Nothing happens to them, because they were never ours. Provider snapshots sit in your provider account; archives sit in your bucket. Cancelling stops us scheduling new runs and takes away the dashboard. Everything already written stays exactly where it is, in a format you can open without us.

For provider snapshots and Agent jobs, no: the snapshot is created inside your provider account, and the Agent uploads to your bucket itself. For SSH database, Docker, and file jobs, partly — the dump or archive is piped from your server through our worker process and into your bucket. It is a stream held in memory, bounded to a few tens of megabytes at a time regardless of backup size, never written to disk on our side and never retained. We would rather state that than imply an air gap that is not there.

Provider API tokens, SSH private keys, database passwords, storage access keys, and TOTP secrets are encrypted with AES-256-GCM before they reach the database — each with its own random 96-bit IV and an authentication tag. They are decrypted only inside a running job. Nothing is written to logs, and nothing is displayed back to you after the first save.

A host, a port, a username, and either a private key or a password. The account needs to be able to run whatever that job runs — pg_dump, mysqldump, mongodump, tar, or docker — and read the paths you pointed it at. There is no requirement for root, and no requirement for us to be able to reach anything other than that one host on that one port.

Yes, with the Agent. Instead of us dialling in, you run a small Docker container on the machine and it opens an outbound WebSocket to us and waits for instructions. No inbound port, no public IP, no firewall exception. The Agent runs Database, Docker, and File jobs — not provider snapshots or Kubernetes — and uploads straight from your machine to your bucket, so the data never transits our infrastructure at all.

Yes. TOTP from any authenticator app, with single-use backup codes for recovery. The TOTP secret is stored encrypted and the backup codes are stored as bcrypt hashes.

You should, and the help centre has the policy. It grants s3:PutObject, s3:GetObject, s3:DeleteObject, and s3:ListBucket on one bucket and nothing else. DeleteObject is there only for the "test connection" check, which writes a small probe object and removes it again — the backup path itself never deletes from your bucket.

One thing: SSH host keys are not pinned. Connections authenticate with your key or password and those credentials are encrypted at rest, but we do not currently verify that the server's host key is the same one we saw last time. If host-key pinning is part of your threat model, it is not covered today.