Google Compute Engine
Every disk, one object, nothing orphaned
Sign in with Google, or connect keylessly through a service account in your project, name the GCP project, and VPS Snaps creates machine images on your schedule. Either way, scheduled backups run without anyone being logged in.
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 Google Compute Engine
Google sign-in or keyless
Sign in with Google, or connect keylessly: a service account in your project that VPS Snaps acts as through Workload Identity Federation, with no key and no sign-in to expire. Either way you name the GCP project, since a Google account can span many.
Enter the GCP Project ID whose instances you want to protect. A Google account can reach many projects, so this cannot be inferred.
Click Connect Google Cloud and sign in once, as someone who can manage permissions in the project. VPS Snaps sets up a service account there that it acts as, with no key, and drops the sign-in, which is what lets a 3am backup run with nobody logged in.
VPS Snaps lists instances across every zone in that project using the aggregated list endpoint, and stores each job's zone with the job.
What one connection reaches
One connection covers one GCP project, across all of its zones. A second project means a second connection, even under the same Google account.
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 Google Compute Engine gave back.
Machine image
POST /compute/v1/projects/{project}/global/machineImages- What it covers
- Every disk attached to the instance, plus its configuration, in one resource — GCE's whole-instance equivalent of a snapshot, and the only artifact here that is genuinely multi-disk by default.
- How consistent it is, honestly
- The instance is not stopped. As with every other provider on this list, that means crash-consistent rather than application-consistent — pair it with a database dump if you need a guaranteed-clean copy of a running database.
And what happens to the old ones
Machine images past your retention window are deleted with a single DELETE call. Because a machine image is self-contained, that one call is genuinely the end of it — there is no underlying disk snapshot left behind, which is the difference between this and cleaning up after an AMI.
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 Google Compute Engine account.
Google Compute Engine 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.
One click, and no key
Connecting is one click: sign in once as someone who can manage permissions in the project, and VPS Snaps creates a vpssnaps service account and a workload identity pool trusting it for your workspace only, then drops the sign-in. No key is ever created, there is no sign-in to expire, and deleting the pool revokes it. If you can't manage the project's permissions, an ordinary Google sign-in still works, but a Google Workspace can end it every few hours. There is no pasted-key option: a service account JSON key is a long-lived secret, and new Google Cloud organizations block creating them by default.
The project ID is a separate field for a real reason
An OAuth token identifies a Google account, and an account can reach dozens of projects. There is nowhere in the credential to carry which one you mean, so VPS Snaps asks and stores it on the connection. Getting it wrong shows up immediately — the instance list comes back empty.
Global resource, zonal source
Machine images live at the project's global scope, but creating one requires the instance's full zonal path. VPS Snaps detects the zone from the instance you pick and stores it with the job, so there is no zone field to fill in and no way to have it drift out of sync with the instance.
You poll an operation, not the image
The insert call returns a long-running Operation rather than the finished machine image. VPS Snaps polls that operation every 20 seconds for up to 20 minutes and surfaces Google's own error text on the run if it comes back with one, instead of a generic failure.
Recovery servers from a machine image
Recover now builds a new instance from the newest machine image — the lost server's own disks, accounts and keys — or a fresh Ubuntu 24.04 with its databases, files and software restored from its backups, on the project's default network with a firewall rule of its own for the ports the server used. Test restores run on throwaway e2-micro instances, deleted when they finish. Failover moves the server's static external IP to the recovery server — reserve the address the instance already has as static, and it stays the same — or repoints its DNS on a connected Cloudflare account; the recovery server can be built in another zone of the address's region, for when the server's own zone is the one that failed. Sizes show Google's list prices for us-central1, since the Compute Engine sign-in cannot read your billing.
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
Machine images or disk snapshots — why this one?
A disk snapshot covers one disk and leaves you to reassemble the instance around it. A machine image captures every attached disk plus the instance's configuration in a single object you can create a new instance directly from. For backup purposes that is the more useful artifact, and its self-contained deletion is what makes automatic retention trustworthy.
What happens when the Google authorization expires?
VPS Snaps requests offline access when you connect and refreshes the access token as needed, which is what keeps unattended schedules running. If the grant is revoked on Google's side, or the project ID stops being valid for that account, runs fail against the connection and reconnecting from Providers restores them. On a Google Workspace account, one more thing can end it: Google Cloud session control, which makes apps using Google Cloud sign in again every so many hours (16 is common). VPS Snaps tells you when that is the reason; to stop it recurring, a Workspace admin marks VPS Snaps as a trusted app under Security → API controls and exempts trusted apps under Security → Google Cloud session control.
Does this cover GKE, Cloud SQL, or Cloud Storage?
No. This integration lists and images Compute Engine instances. GKE clusters are covered separately by Kubernetes backup jobs, which connect with a service account token and capture namespace manifests. Cloud SQL is a managed database — point a database backup job at its endpoint for a portable dump in a bucket you own.
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 instance on Google Compute Engine and nowhere else. For a copy you can carry anywhere, add a database, file or Docker job on the same instance — 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 Google Compute Engine backup tonight.
Connect the account, pick a instance, 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.