Linode · Akamai
Disk images, not the Backups add-on
Sign in with Linode and VPS Snaps captures a disk image on your schedule. This is the one provider where the shape of the backup genuinely differs, so the page says exactly what it covers.
Backup Jobs
Automated backup schedules
postgres-main nightly
Last run 6h ago
web-01 snapshots
Last run 9h ago
api-prod volumes
Last run 4m ago
staging-db weekly
Last run 3d ago
Connecting Linode (Akamai)
OAuth connection
Sign in with Linode (Akamai) and authorize VPS Snaps, or paste a personal access token with Read/Write on Linodes and Images.
Click Connect Linode and authorize VPS Snaps — the OAuth path needs nothing pasted anywhere.
Using a token instead? In Cloud Manager go to My Profile → API Tokens → Create a Personal Access Token, and grant Read/Write on both Linodes and Images. Images is the one people forget, and without it the snapshot call fails while the connection test passes.
When you create the job, VPS Snaps lists the Linode's disks and pre-selects the one it detected as the boot disk. Confirm or change it — that choice is what gets imaged.
What one connection reaches
One connection reaches every Linode on the account, in every region. The per-job choice is not which account or region, but which disk.
What one run actually produces
No proprietary format and no copy on our side. VPS Snaps makes the same API call you could make yourself, and records what Linode (Akamai) gave back.
Disk image
POST /v4/images { disk_id, label }- What it covers
- One disk — the one selected on the job. VPS Snaps reads the first configuration profile's sda slot to pre-select the boot disk, and falls back to the first populated device slot if sda is empty.
- How consistent it is, honestly
- The Linode keeps running. The image is captured from the live disk, so it is crash-consistent, and a Linode with a separate data disk needs a second job to cover it.
And what happens to the old ones
Images from runs older than your retention window are deleted with DELETE /v4/images/{id} after each successful run, so stored images stop accumulating on your Akamai account once the first one ages out.
Cleanup runs only after a run has already succeeded, so a failing schedule never deletes the last good copy you have. Every deletion is written into that run’s log with the date of the backup it removed.
VPS Snaps stores the ID and the name of each image it creates — never the image itself. Close your account and every copy already taken stays exactly where it is, in your Linode (Akamai) account.
Linode (Akamai) specifics worth knowing first
Every provider does this differently, and the differences are the part that bites at 3am. These are the ones that changed how the integration had to be built.
Why not the Backups add-on
Linode Backups is a paid per-Linode add-on that keeps a single rolling slot: each new backup replaces the previous one. Retention windows cannot be built on that — asking for 30 days would quietly give you one backup. The Images API creates independent objects that can be kept and deleted individually, so VPS Snaps uses that instead and your retention setting means what it says.
One disk per image, stated plainly
Because the Images API takes a disk_id and not a Linode ID, an image covers one disk. If your Linode has an application disk and a separate data disk, one job covers one of them. Create a second job on the same Linode for the other — the picker makes it a thirty-second addition, but you have to know to do it.
Boot-disk detection is a suggestion, not a decision
VPS Snaps reads your first config profile and pre-selects whatever sits in sda, which is where a standard deployment puts its boot disk. It never silently commits to that guess: the disk picker is always shown, because unusual layouts are exactly the case where a wrong guess is expensive.
The image is its own status machine
There is no separate action to poll. VPS Snaps watches the image resource move from creating to available for up to 20 minutes, and treats any other status it reports as a failed run rather than waiting out the clock.
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
Is a disk image enough to rebuild the Linode?
For the standard single-disk deployment, yes — you deploy a new Linode from the image and you are back. For a Linode with additional data disks, the image restores the disk it captured and nothing else, so cover the rest with a second job. This is the one provider where reading the fine print before an outage genuinely changes what you would set up.
Why does the connection test pass but the backup fail?
Almost always a token scope. The connection test reads your profile and lists Linodes, which a Read-only token can do; creating an image is a write against a different endpoint. Grant Read/Write on both Linodes and Images, or use the OAuth path, which requests what it needs up front.
Where do the images live, and who charges for them?
On your own Akamai account, under whatever image storage pricing and account limits Akamai applies — VPS Snaps has no say in either and never holds a copy. What VPS Snaps stores about a run is the image ID, its label and the run's outcome. Retention cleanup deletes aged images for you, which is what stops a daily schedule from quietly compounding a few weeks in.
Running on more than one of these?
Connections are additive and independent — a Hetzner project and an AWS region live side by side in the same workspace, on the same schedules and the same run history.
A snapshot restores a Linode on Linode (Akamai) and nowhere else. For a copy you can carry anywhere, add a database, file or Docker job on the same Linode — those write plain .tar.gz and .sql.gz into an S3-compatible bucket you own.
Everything else it does
Storage, schedules, alerts, recovery and team access, in one place. Which plan each one starts on is on the pricing page.
- Bring your own storage
- Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3 — or in your own Google Drive, Box, Dropbox or OneDrive. 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.
- Eight providers, one dashboard
- DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
- A replacement server on demand
- Recover now builds a new server on your own DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account, from its snapshot or from its backups, software included.
- Failover on any cloud
- When a server stops answering, its traffic moves to the recovery server: by reserved or floating IP where your cloud has one, or by your DNS on Cloudflare, which works on every cloud.
- Know it's down, with the way back
- Uptime monitors for sites, ports and scheduled jobs confirm an outage before alerting, name the server's newest backup, and publish a status page. On paid plans.
- Your DNS zones, backed up
- Every record in a Cloudflare zone, kept in your own storage as a BIND file too. A restore previews what differs and writes back only that.
- 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.
- Every run on record
- Status, duration, size and trigger, with each step it took in order and its warnings and errors kept in place — so a failure tells you which step broke.
- 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.
“The biggest advantage for us is that VPS Snaps works with the infrastructure we already have instead of forcing us into a proprietary backup environment. Provider snapshots stay inside our cloud account, while database and file archives can go directly into our own bucket.”
Schedule your first Linode (Akamai) backup tonight.
Connect the account, pick a Linode, set a schedule and a retention window. The first run is what proves the credential has the scope it needs — a much better thing to discover on a quiet evening.
No credit card required. Cancel anytime.