Your database, dumped and gone by 02:01

Yes. The job has its own database host field, separate from the SSH host. Point the SSH connection at any server you have already added, then set the database host to your managed endpoint — the dump runs on that server and connects outward. Two requirements: the server must be able to reach the endpoint on its port, and the client binary must be installed there, at a version equal to or newer than the database being dumped.

There is no size limit in VPS Snaps. The dump is never staged as a file: pg_dump or mysqldump writes to stdout, gzip compresses it in the pipe, and those bytes are consumed by a multipart upload as fast as they arrive. Peak memory is bounded by the upload's part queue — tens of megabytes — whether the dump is 200 MB or 200 GB. What grows with size is the wall-clock run time, and on Postgres the length of the snapshot the dump holds open.

The database password, the SSH key or password, and your storage access keys are each sealed with AES-256-GCM before they are written to our database. They are decrypted in the worker at the moment a run starts and handed to the dump process. Nothing is written to a file on your server, and a non-interactive SSH command does not land in that user's shell history.

The dump command's exit code and its stderr are captured and stored on the run, so the failure tells you what the database said rather than just that something went wrong. The multipart upload makes a best-effort attempt to abort rather than commit — that catches the common case, though a failure right at the end of a very fast dump can occasionally land a partial object before the abort reaches it, which is why the run is still marked failed either way rather than trusted on exit code alone. Notifications go out on email, Slack, Microsoft Teams, Google Chat and Discord.

No. The retention setting controls how long VPS Snaps keeps run history. The .sql.gz objects themselves stay in your bucket until you remove them — nothing in a backup run deletes from your storage. If you want them expiring on a timer, an S3 lifecycle rule on the prefix does exactly that, and it keeps the delete decision on your side of the line.

In two ways worth knowing before you set one up. First, the tooling: mongodump and mongorestore live in mongodb-database-tools, which is packaged separately from the MongoDB server, so a machine running MongoDB frequently does not have them — a backup job checks for mongodump before it runs, and restore preflight checks for mongorestore on the target, so a missing package is the reason you are given rather than an empty archive. Second, the shape of a restore: mongorestore is run with --drop, so each collection in the archive replaces the one on the target and a collection created since the backup is left alone. Before anything is dropped the same command is run with --dryRun, which reads the whole archive and authenticates against the target while writing nothing — a truncated or corrupt archive fails there rather than halfway through.

Where your user is defined, which is usually not the database being backed up. If the user was created in admin and granted rights elsewhere — the common setup — put admin there. If it was created in the database you are backing up, leave it blank and mongodump authenticates against that database, which is its default. Getting it wrong looks exactly like a wrong password, which is why it is a field rather than an assumption.

Run the same job through the Agent instead of over SSH. The Agent is a Docker container you run inside your own network; it holds an outbound WebSocket to us, so nothing needs to be exposed inbound. It performs the dump locally and uploads to your bucket itself — the data never transits our infrastructure at all.