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 passes through ours. The server uploads it straight to your bucket in parts as it is produced, with short-lived links we sign for it, hashing it on the way out. 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.

The run fails, and the error names every volume that could not be archived. It used to be recorded as a warning with the run finishing successfully — a green badge over a backup missing a volume, which is the one outcome a backup must never have. Now a successful run always contains every volume you asked for.

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, a short-lived Job reads the manifests for the namespaces you chose inside the cluster and uploads them straight to your bucket — or, where the cluster does not let us run one, our worker reads them over the API with your service account token — and we 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.

From the dashboard, for database, file and Docker runs, Kubernetes runs taken with Velero, and WordPress sites through the plugin: open the run, choose where to restore it, and confirm. A run taken by the agent restores back onto the machine the agent runs on. A detected application — its files and its database — restores in one step from the Recovery page. The exception is a provider snapshot, which you restore 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.

Yes. Open a successful run and pick where to restore it — any server in your workspace, not only the one it came from. 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. A check-only mode downloads and verifies without changing anything.

Restoring onto a new server that doesn't have the files yet is one checkbox: with nothing there to back up first, the restore only creates files. It stops before writing anything if a file it would write already exists, and never overwrites one. Two limits worth knowing: a Kubernetes run restores only if it was taken with Velero, 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.

Yes, for an application VPS Snaps has detected — WordPress, Laravel, Craft CMS, Ghost or Nextcloud. Pick the new server and it checks both servers first, creates the site's database and user there, takes a fresh backup of the database and then the files, restores them onto the new server — never overwriting a file already there — and counts what arrived against what left. The old server is only ever read, so if anything fails, the live site is exactly as it was. What stays yours: the web server configuration, DNS, the HTTPS certificate, cron and background workers, and anything the old site records after its backup starts, so pause a busy site first. It's included on the Standard, Pro and Agency plans, and the Switching Providers page walks through all of it.

You build a replacement. Save a recovery plan on the server's page, and Recover now creates a new server on your DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account: from the server's newest snapshot there if it has one, which is the whole machine, or otherwise a fresh Ubuntu server with the database engines and Docker installed, each database created with the same name, user and password as before, and the newest backups restored onto it.

A recovery from backups brings back the server's software too. Each database, file or Docker backup over SSH records what the server runs — the packages its admin installed, its web server, PHP and TLS configuration, cron and its own services — with the configuration stored in your own storage, and the recovery installs and starts the same. Repositories it had added (a PPA, NodeSource, Docker's) are added back, moved to the new server's Ubuntu release. A repository that no longer answers, or a PHP version that has moved on, is listed for you; a snapshot has everything. Its data is exactly as old as the backups it was built from, and the page says how old before you press anything.

If the provider the server runs on is down, rebuild it somewhere else. Choose a second cloud in the plan and it's one button, Recover to that cloud; or open the server's Rebuild elsewhere page, which every outage alert links to, and build on a cloud you've connected, one you connect there and then, or any Ubuntu 22.04 or 24.04 server you can reach as root at any host. That is always from backups, since a snapshot only comes back at the provider that took it, and the provider that's down is never asked anything. Traffic then moves by DNS: on Cloudflare, or the summary lists the records to change. A checklist on the server says beforehand whether its backups are kept with a company other than the one running it.

Two options go on top. A warm standby keeps a recovery server built and rebuilt from newer backups, so it is ready at once; it runs, and is billed to your account, all the time. Automatic failover checks the server every minute, and when it hasn't answered for as long as you choose, while our own connection is working — and when a check from inside your account can't reach it either: the warm standby's, or, without one, a small probe machine's, started beside the server for the outage and removed afterwards — moves its reserved IP (a floating IP on Hetzner, an Elastic IP on AWS EC2, a static public IP on Azure, a static external IP on Google Compute Engine, the server's own IP on Linode) to the recovery server — or, with your DNS on Cloudflare, points the records you chose at it, on any of those clouds — after telling you and waiting if you ask it to. Failover moves your traffic to data as old as the last backup, never switches back on its own, and is off again until you re-arm it.

Recovery servers are on the Standard, Pro and Agency plans; the warm standby and automatic failover on Pro and Agency. They need a DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine connection, and failover needs a way to move traffic: the IP your domain points at being one that can move (a reserved, floating, Elastic, static public or static external IP, or on Linode the server's own), or your domain's DNS on a connected Cloudflare account, which works on every one of them. On AWS Lightsail, where no IP moves, automatic failover moves traffic by your DNS on Cloudflare.

Yes, for domains on Cloudflare. Connect your Cloudflare account and make a DNS zone backup job for a domain. On its schedule, every record in the zone is stored in your own storage, with the zone as a BIND file that Cloudflare or any other DNS host can import, so the backup is useful without us.

To restore, preview it first: it lists every record that differs from the zone now — changed, deleted, or added since — and changes nothing. The restore writes back only those records, after taking a safety copy of the zone, and if Cloudflare refuses a change partway, what was written is undone from that copy. Records added since the backup are kept unless you choose to remove them too. A zone has no server of yours to run anything on, so our worker reads it through Cloudflare's API and writes it straight on to your storage, in memory only, never keeping it.

More on DNS backups

Yes, on the paid plans. Add uptime monitors for your web pages (by the status code, and a word that should or shouldn't be on the page), for ports such as a database or SSH, and for scheduled jobs, which call a URL of their own when they finish. A failure is checked again twice, 20 seconds apart, and only the third in a row is an outage, after we've made sure the fault isn't ours. Then one alert goes to your email or the Slack, Teams, Google Chat, Discord or webhook destinations your backup alerts use, and another when it's back.

A monitor linked to a server puts that server's newest backup in its alert, with Recover now beside it when the server has a recovery plan, and a link to rebuild it on another provider. Every monitored https page is also warned about 14 and 3 days before its certificate expires. Starter checks 10 monitors every 5 minutes; Standard, Pro and Agency check 30, 100 and 300 every minute. Checks come from New York, at 165.227.255.101, and there are no text messages or phone calls yet.

More on uptime monitoring

Yes, on the paid plans. A status page lists the monitors you choose under names you choose, at status.vpssnaps.com/your-name, with each one's state and 90 days of uptime, its outages, and the updates and planned-work notices you post. It never shows your addresses, ports or error messages, and carries no analytics or advertising scripts of ours. Starter has one page, Standard three, Pro ten and Agency fifty; on Agency a page can also be on your own domain, such as status.yourcompany.com, with one CNAME record, and without "Powered by VPS Snaps".

Setting up a status page

Turn on test restores for the job. On the schedule you choose, we create a throwaway server on your own DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account, restore the newest backup onto it through the same pipeline a real restore uses, check that the data arrived — the tables or collections in a database created empty, the files under the job's own paths or inside its Docker volumes — and destroy the server. A test that fails alerts you: a backup that completed, looked healthy, and does not restore.

It covers file and Docker volume backups and PostgreSQL, MySQL, MariaDB and MongoDB, it needs a DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine connection (a Railway or Render database is tested inside your own project or workspace instead), and the server is billed to your account for the few minutes it exists. If the test itself can't run — your connection has lapsed, say — that isn't reported as a failed restore. We retry within hours, and if it still can't run after three tries we tell you the backup hasn't been tested, and why.

Separately, every backup is checked as it uploads: the archive must decompress, a tar archive's headers must be intact, a database dump must reach its completion marker, and the object is read back from your bucket to confirm its size — and, where the upload allows it, its checksum. What none of that proves is that your application runs on the restored data: we count what came back, we don't start your app. 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. SSH database, Docker, and file jobs don't either: your server uploads the dump or archive straight to your bucket with short-lived links we sign for it, and only sizes and checksums come back to us. A server that can't — no curl, say, or a bucket that refuses it — has that run streamed through our worker instead, held in memory and never retained, and the run's log says so.

Render databases are dumped by a job in your own Render workspace, and Railway ones in a short-lived service in your own Railway project when Railway is connected with admin access, each uploading from there. Without admin access, or when the platform will not run it, the Railway or Render dump runs on our worker and its log says so. Restores and test restores are downloaded by the server being restored, straight from your storage — for a Railway or Render database, by a job in your own project or workspace — and "Verify now" has your server download and check the backup, or asks your storage whether it is unchanged without downloading it. 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 seven actions on one bucket and nothing else: s3:PutObject, s3:GetObject, s3:DeleteObject, s3:ListBucket, s3:ListBucketMultipartUploads, s3:AbortMultipartUpload and s3:GetBucketObjectLockConfiguration. The last one only reads whether the bucket has Object Lock turned on, so the dashboard can show how long your backups are locked.

DeleteObject is what lets retention expire old archives, what lets the "test connection" check remove the small probe object it writes, and what removes a partial copy a failed backup left, a day later and only once a later backup of that job has succeeded. Every delete is of an object we wrote, by the exact key we recorded — never a listing, never a prefix.

The two multipart actions clean up after an upload that was cut off, which S3 otherwise keeps, billed and hidden from the bucket's file list. Cancelling one removes only its unfinished parts, never a finished backup. We look for them at the keys our own uploads recorded, and in each job's own folder for uploads started more than a day ago. Leave those two out and backups work the same; interrupted uploads just are not cleaned up.

One thing: the first connection to a server is taken on trust. Its SSH host key is pinned then, the way ssh records it in known_hosts, and every later connection must present the same key or it stops before any password is sent or command run, until an owner accepts the new key on the server's page. What we cannot know is whether the key we saw the first time was the right one. If that matters to you, compare the fingerprint on the server's page with what ssh-keygen -lf prints for the server's own host key.