VPS Snaps

InterServer

One InterServer VPS. One job per site.

InterServer hands you unmanaged KVM with full root, and cPanel and DirectAdmin both put sites under /home/*/public_html — a layout VPS Snaps already scans. Every site gets its own file and database job, landing in a bucket you own.

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 InterServer integration to authorise

No API token field, no OAuth screen, nothing to approve inside your InterServer account. The VPS is added the same way a bare Hetzner box is — host, port, username, key.

That is a consequence of what InterServer’s API is for. The published VPS interface covers services, power state, a console screenshot and billing. It can start your machine, stop it and cancel it; it cannot image its disk. A snapshot job has nothing there to call, so VPS Snaps does not pretend to offer one.

Which turns out to matter less than it sounds. The two things you actually want back after a bad night are a site’s files and its database, and both of those live on the filesystem and in MySQL on the machine itself. An SSH session reaches both directly, at per-site granularity rather than per-server — so one client’s site restores without touching the other eleven on the box, which no whole-machine image can do.

Full root on unmanaged KVM is the ideal starting point for this. 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 published InterServer VPS API

SOAP, from the documentation for my.interserver.net/api.php — checked 7 September 2026

  • api_vps_get_services
  • api_vps_get_service
  • api_vps_get_server_name
  • api_vps_queue_start
  • api_vps_queue_stop
  • api_vps_queue_restart
  • api_vps_screenshot
  • api_vps_get_client_invoices
  • api_vps_get_client_unpaid_invoices
  • api_vps_cancel_service

Ten operations, none of which touches a disk. If InterServer publishes one that does, we will build the integration and this section will change.

What the connection needs

  • The VPS's IP address
  • An SSH username — root, or any user that can read the paths you want
  • Port 22, unless you have moved it
  • An SSH key pair, or a password if you prefer

What it never asks for

  • Your InterServer account login
  • An InterServer API token
  • Your cPanel or DirectAdmin password
  • A daemon or agent running on the server

Every credential — the SSH key, the storage access key, any database password read during detection — is encrypted with AES-256-GCM before it reaches our database, and decrypted only inside the worker while a run is happening.

From a key to a schedule per site

Five steps. The only typing is an IP address and a username; the sites find themselves.

  1. Add the VPS under Servers

    Generate an SSH key pair in VPS Snaps under Settings, or bring your own. Only the public half is ever shown to you; the private half is sealed with AES-256-GCM before it is written to our database and is decrypted inside the worker at the moment a run starts. InterServer gives you an unmanaged machine with real root, so ssh-copy-id works normally — nothing on the platform rewrites authorized_keys behind you.

  2. Run the connection test

    One SSH session, opened and closed, with the result on screen. Worth doing before anything is scheduled: an authentication problem is much easier to read here than at 02:00 in a run log.

  3. Click Detect applications

    A read-only scan runs a single find across six web-root conventions. /home/*/public_html is one of them, which is where both cPanel and DirectAdmin put every account's sites — so a panelled InterServer VPS needs no special mode. The scan writes nothing and installs nothing.

    The root that matches on a cPanel or DirectAdmin box

    /home/*/public_html

  4. Point a storage destination somewhere that is not InterServer

    Any S3-compatible bucket you own — Backblaze B2, Cloudflare R2, Wasabi, Spaces, S3. Deliberately a different provider from the one being backed up: a copy inside the same account as the original is the copy you cannot reach on the day the account is the problem.

  5. Accept the sites you want and let the schedules run

    Each accepted application becomes a file job for its document root, plus a database job when its config file gave up a usable database name. Both start daily at 02:00 UTC with 7-day retention and failure alerts on — all of it editable, per job, afterwards.

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

What is not in an InterServer backup

A file job archives a directory and a database job dumps a database. Neither knows the word InterServer, and four things follow from that.

A snapshot job for InterServer

Snapshot jobs work by calling the host's own API to create an image, and InterServer's published VPS API is an account and power-management interface — list your services, start, stop, restart, fetch a console screenshot, pull invoices, cancel. There is no disk or image operation in it to call. That rules out a snapshot job here and rules out nothing else on this page.

Anything outside the paths a job archives

A file job tars the directories you list. Your Apache or nginx vhosts, PHP configuration, mail, DNS zones, and anything cPanel or DirectAdmin keeps in its own directories all sit outside a document root. Add extra file jobs for the paths you care about, or use the panel's own account export alongside this for the panel-level configuration.

A one-click restore

What lands in your bucket is a .tar.gz and a .sql.gz. Restoring means recreating the account in the panel, extracting into its document root, and piping the dump into its database with that account's new credentials. Slower than a panel restore, and openable by anything — no part of it needs us.

Anything installed on the server

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

The jobs underneath the button

Detection is a convenience layer. What it creates are ordinary jobs, and you can create them by hand at any time.

File backups

The job behind every detected site: tar and gzip over your paths, minus your excludes, streamed to your bucket and checksummed in flight.

Read more

Database backups

mysqldump for the MySQL and MariaDB databases a panel provisions per account, pg_dump for Postgres. Compressed on the server, never written to ours.

Read more

Application detection

What the scanner looks for, which platforms hand over their own database credentials, and where the scan comes back empty.

Read more

FAQs

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

Why isn't InterServer in the provider list?

The provider list is the set of hosts whose API can create a snapshot on request, because that is what a snapshot job does. InterServer's published VPS API handles services, power state, a console screenshot and billing — there is no image or disk operation to call. Everything else works normally: an InterServer VPS is unmanaged KVM with full root, which is the easiest kind of machine to back up over SSH.

Does this work with cPanel and DirectAdmin?

Yes, and it is the case detection handles best. Both panels put each account's sites under /home/<account>/public_html, and /home/*/public_html is one of the six roots the scanner searches. It finds WordPress by its wp-config.php, Laravel and Craft by their .env, and Ghost by its config.production.json — reading the database name, user and password out of the application's own config file, so you rarely have to look anything up in the panel.

Does it install a plugin or touch the panel?

No. There is no plugin, no mu-plugin, no panel login, and no API token for cPanel or DirectAdmin. Detection is find and cat over SSH, three directory levels deep from each known root. The backup itself is tar on your server and a dump against the database. Nothing is written into any site, and the panel never learns this is happening.

I run a plain VPS with no panel at all. Does anything change?

Only which root matches. /var/www and /srv/www are both scanned, and if your layout is somewhere else entirely you skip detection and create the jobs by hand — a manually created job is identical to a detected one in every respect. Docker workloads have their own job type that dumps named volumes and container databases from inside the running containers.

I added slices and the disk got bigger. Does the backup cost more?

Not to us. Pricing is per backup job and per server, not per gigabyte, so growing the VPS does not change your VPS Snaps bill. What it can change is your storage bill at whichever bucket provider you chose, since a larger site is a larger archive — which is what per-job retention windows are for. Set how many days to keep and old copies are pruned automatically instead of accumulating.

Can I restore onto something other than InterServer?

Yes. A .tar.gz and a .sql.gz restore onto any host, any panel, or no panel — that portability is the main practical difference between an archive in your own bucket and an image bound to the platform that made it. If you ever move a client site off InterServer, the copy you need is already sitting in storage you control.

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
Chris Bennett
“We manage a mix of VPS instances, Docker workloads, and traditional Linux servers, so backups used to be scattered across several different processes. VPS Snaps brought all of that into one dashboard and made it much easier to see what ran, what failed, and what needs attention.”
Chris BennettSystems Administrator

Every site on the box, in a bucket you own.

Add the server, run detection once, and each site on your InterServer VPS has its own file and database job by the end of the afternoon.

No credit card required. Cancel anytime.