VPS Snaps

SSD Nodes

Their snapshot never leaves the node. This one does.

SSD Nodes keeps seven rolling daily snapshots on the same node as your VPS, and restores them all-or-nothing. VPS Snaps adds scheduled database, file and Docker backups over SSH, landing in a bucket you own — on a different provider, in a format you can open without us.

Back up your first server free, forever. No credit card required.

We only use your email to create your account. See our Privacy Policy.

There is no SSD Nodes snapshot job, and there cannot be

Every provider integration here works by calling that provider's own API to create a snapshot. SSD Nodes publishes fifteen endpoints. None of them creates one.

Two of the fifteen concern snapshots. One lists what exists on a VM, returning identifiers like 20250502_daily and 20250508_on_demand. The other restores one. Creating a snapshot happens in the control panel, by hand, and there is no request that does it for you.

So this is not a provider we have not got to yet. Scheduling a snapshot on SSD Nodes is not a thing any software can do, ours included, and we would rather say that plainly than leave you waiting for a roadmap item that cannot arrive. If they publish a create endpoint, the integration follows and this section gets rewritten.

What that does not change is whether your SSD Nodes server can be backed up. Three of the four job types in VPS Snaps never touch a provider API — they open an SSH session and work on the machine directly. An SSD Nodes VPS is unmanaged KVM with real root, which makes it one of the more straightforward servers to point them at.

The published SSD Nodes API

ssdnodes.com/api-docs, checked 7 September 2026

  • List VM's
  • List API Subscriptions
  • List Domains
  • List SSL's
  • List OS's
  • List Apps
  • List VM Details
  • List VM Snapshots
  • Get VM Root Password
  • Get VM Console Credentials
  • Change VM Status
  • Reinstall VM (OS/App)
  • Reset VM Root Password
  • Change VM Console Status
  • Restore VM Snapshot

List and restore. No create. That single missing verb is the whole reason this page exists instead of a provider page.

Their snapshots are good. Here is exactly how far they go.

Nothing on this page argues you should turn them off. They are free, they are automatic, and they fix the problem you hit most weeks. Four strengths, and the edge of each one.

They live on the same node as your VPS

SSD Nodes describes them as stored on the same node your VPS runs on, as close to the server's main disks as possible. That is why a restore is quick.

It is also the reason they are not off-site. A snapshot beside the disk it came from shares that disk's node, that node's failure modes, and the account they both hang off. The copy that survives the account is the copy stored somewhere else.

A daily one is taken for you, automatically

Seven daily snapshots on a rolling window, with no schedule to configure and nothing to remember. For undoing yesterday's mistake this is exactly right.

A rolling seven means the window is one week. A corruption you notice on the ninth day has already rolled off the end, and the snapshot you want is gone. Retention past a week has to live somewhere that keeps things longer.

Restoring is one call and the whole machine is back

Point at a date, and the VPS returns to how it was. No file shuffling, no rebuild, no reinstall.

Their documentation is blunt about the trade: restoring a snapshot wipes out all your current data and returns the machine to that date. It is the whole disk or nothing — there is no way to take back one dropped table and keep this morning's orders.

On-demand snapshots let you mark a known-good state

Three, seven or ten of them depending on the tier, kept until you delete them — a deliberate marker before an upgrade you are unsure about.

They are made in the control panel. The API can list a snapshot and restore one, but there is no endpoint that creates one, so "snapshot before every deploy" is a thing you do by hand or not at all.

The short version: a same-node snapshot answers “put it back how it was yesterday”. It does not answer “that table was wrong three weeks ago”, “I need this one file and nothing else”, or “the account is gone”. Those three are what a scheduled dump in your own bucket is for.

From a bare VPS to a running schedule

Five steps, and the only genuinely SSD Nodes-specific thing about them is that there is nothing SSD Nodes-specific about them.

  1. Add the VPS under Servers

    Host, port, username, and either an SSH key generated in VPS Snaps or one you already use. SSD Nodes gives you an unmanaged KVM machine with real root, so there is no platform layer rewriting authorized_keys behind you — ssh-copy-id works exactly the way it does anywhere else.

    Where the IP comes from

    SSD Nodes control panel → your VPS → the address you already SSH to

  2. Run the connection test before anything is scheduled

    One SSH session, opened and closed. An authentication problem is far easier to read here, with the result on screen, than at 02:00 in a run log a week later.

  3. Point a storage destination at a bucket you own

    Any S3-compatible endpoint — Backblaze B2, Cloudflare R2, Wasabi, DigitalOcean Spaces, AWS S3. The access keys are sealed with AES-256-GCM before they reach our database. Deliberately somewhere other than SSD Nodes: a copy in the same account as the original is the copy you cannot use on the day the account is the problem.

  4. Create the jobs the machine actually needs

    A database job for Postgres or MySQL, a file job for the paths that matter, a Docker job if the workload runs in containers. Each gets its own schedule in your timezone, its own retention window, and its own alerting.

  5. Watch the first run finish

    Every step is logged as it happens, with the actual error text if something fails rather than a generic message. The first scheduled run is what proves the credentials, the paths and the bucket are all what you assumed — better to learn that tonight than during an incident.

If the machine has no inbound route — behind NAT, or with SSH firewalled to a bastion — the same three job types run outbound through the Agent instead, and nothing else about the setup changes.

What you do not get

Four things this page would be dishonest not to say, given what the previous three sections claim.

A snapshot job for SSD Nodes

There is no create-snapshot endpoint in their API, so there is nothing for a snapshot job to call. This is not a queue we are working through — it is a capability that does not exist to integrate with. If SSD Nodes publishes one, we will build it and this paragraph will change.

Any involvement with their daily snapshots

VPS Snaps does not read, trigger, restore or delete anything in SSD Nodes' snapshot system, and could not if it wanted to. The two run beside each other and neither knows about the other. Keeping both is a reasonable choice — a same-node snapshot for speed, an off-site copy for everything a same-node snapshot cannot survive.

A bootable image of the machine

What lands in your bucket is a .sql.gz and a .tar.gz, not a disk. Rebuilding means a fresh VPS, your OS and packages back on it, then the archive and the dump restored into place. Slower than their one-click restore, and the thing that still works when their one-click restore is not available to you.

Anything installed on the server

No agent, no daemon, no cron entry, no package. A run is an SSH session that executes pg_dump, mysqldump or tar and streams the output straight out to your bucket. Nothing is left behind, and you revoke it by deleting one public key.

The three jobs that run on an SSD Nodes box

None of them asks SSD Nodes for anything. Each one is an SSH session, a command on the far end, and an upload to storage you control.

Database backups

pg_dump and mysqldump run on the VPS and stream straight to your bucket, compressed. Application-consistent, which no disk snapshot is.

Read more

File backups

Any list of paths, with excludes, archived and uploaded on a schedule. A plain tar.gz you can open without us and restore onto any host.

Read more

Docker backups

Named volumes and the databases inside running containers, dumped from within them so the dump matches the engine that wrote it.

Read more

FAQs

Can’t find the answer you’re looking for? Reach out to our support team.

Why isn't SSD Nodes in the provider list?

Because a snapshot job needs an API call that creates a snapshot, and SSD Nodes does not publish one. Their API has fifteen endpoints; two of them touch snapshots, and those two list and restore. Everything else in VPS Snaps works on an SSD Nodes VPS exactly as it does anywhere else, because the other job types reach the machine over SSH and ask nothing of the host's API at all.

Do I still need SSD Nodes' own daily snapshots?

Keep them. They cost nothing extra, they restore a broken machine faster than any archive will, and they cover the case you hit most often — undoing something you did yesterday. What they do not cover is a week-old corruption that has rolled off the seven-day window, a single file you need back without losing everything since, or anything at all if you lose access to the account. Those are the gaps this fills, which is why running both is the sensible answer rather than a sales pitch.

Does anything about an unmanaged VPS make this harder?

Easier, if anything. SSD Nodes hands you a KVM machine with root and gets out of the way, so there is no managed layer regenerating authorized_keys, no restricted shell, and no platform user whose permissions you have to work around. Add the host, add a key, run the test. The database and file jobs are the same ones running on Hetzner and DigitalOcean boxes.

Where do the backups actually go?

Into an S3-compatible bucket you own and pay for — Backblaze B2, Cloudflare R2, Wasabi, Spaces, S3 itself. We never hold a copy. The dump is produced on your VPS and streamed through the SSH connection to your bucket, so it does not sit on our disks even briefly, and the credentials for both ends are encrypted with AES-256-GCM at rest.

Can I restore onto a different host later?

Yes, and that is the point of the format. A .tar.gz and a .sql.gz restore onto a Hetzner box, a Vultr instance, a machine in your own rack, or a laptop. A provider snapshot never can — a snapshot is bound to the platform that made it. If moving off SSD Nodes is ever on the table, the archives already in your bucket are what makes it a Tuesday afternoon rather than a project.

What happens if SSD Nodes adds a create-snapshot endpoint?

We build the integration and SSD Nodes joins the provider list like any other. Nothing you set up in the meantime is wasted — a snapshot job would sit alongside the database and file jobs rather than replace them, the same way it does for the providers already supported.

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.
View all features
Ryan Patel
“I wanted reliable backups without building and maintaining another internal system. With VPS Snaps, our production database and application files are backed up automatically to storage we control, and retention is handled for us. It's one less piece of infrastructure I have to think about.”
Ryan PatelSaaS Founder

Keep their snapshots. Add the copy that outlives the node.

Add the server, point a job at your own bucket, and by tomorrow morning there is a restorable copy of your data somewhere that is not SSD Nodes.

No credit card required. Cancel anytime.