Microsoft Azure
Every disk on the VM, not just the one that boots
Sign in with Microsoft, choose a subscription, and VPS Snaps snapshots every managed disk attached to a VM on your schedule, deleting the sets that fall out of your retention window — and builds its recovery servers and test restores in the same subscription.
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 Microsoft Azure
Sign in with Microsoft, or a service principal
Signing in is used once, to give VPS Snaps' own app access to the subscription you choose. From then on it runs as that app, never as you: a delegated token is issued against a person, and an administrator resetting their account, revoked sessions, a Conditional Access policy or that person leaving ends it — which for an unattended nightly job means backups stopping silently. A service principal of your own works too, given the same role.
Press Connect with Microsoft Azure and sign in with an account that is an Owner or User Access Administrator of the subscription.
Choose the subscription. VPS Snaps defines a VPS Snaps role on it — disk snapshots, and the machines, disks and networking of recovery servers and test restores — and grants it, with Reader, to its own app on that subscription only.
Or create an app registration of your own, give it Reader and the VPS Snaps role (its JSON is on the connect form) on the subscription, and paste its tenant ID, client ID, client secret and subscription ID.
What one connection reaches
One connection covers one subscription, every resource group and region inside it. Several subscriptions means several connections — the same shape as Hetzner's one-project-per-token.
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 Microsoft Azure gave back.
Managed disk snapshot
PUT /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Compute/snapshots/{name} { "creationData": { "createOption": "Copy", "sourceResourceId": "<disk>" } }- What it covers
- One snapshot resource per attached managed disk — the OS disk and every data disk, requested together and named with a shared vpssnaps- prefix and timestamp so a run's snapshots are recognisable as a set in the portal. There is no whole-machine equivalent in Azure to call instead.
- How consistent it is, honestly
- Nothing is powered off or frozen. Each disk is copied while the VM runs, so the set is crash-consistent — and because the disks are snapshotted one request after another, a busy database spanning two disks is a good reason to run a database job alongside this rather than instead of it.
And what happens to the old ones
After each successful run, every snapshot from runs past the retention window is deleted individually. A 204 (already gone) counts as deleted. A run is only marked pruned once all of its snapshots went, so a partial failure is retried on the next run instead of leaving orphans nobody bills you for quietly.
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 Microsoft Azure account.
Microsoft Azure 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.
Per-disk is the whole story, not a limitation we chose
Azure has no AMI, no machine image, no Droplet-snapshot equivalent. Backing up only the OS disk would produce a restore that boots and has lost your data — an outcome worse than a failed backup, because it looks like success. So every attached managed disk is snapshotted, and if any one of them fails the whole run fails.
Unmanaged (classic) VMs are refused, by name
A classic VM backed by unmanaged VHDs in a storage account has no managed disk to copy. Rather than returning an empty list that reads as "nothing to back up", the run stops with a message saying exactly that — VPS Snaps snapshots managed disks, and this VM has none.
A restore means reattaching a set
Three snapshots restore as three disks. Rebuilding is creating disks from each snapshot in the set and attaching them to a VM in the right order, rather than one button. That is Azure's model rather than ours, and it is the reason the run records every snapshot ID rather than just the first.
The API versions are pinned on purpose
Azure dates its API versions and changes response shapes between them. VPS Snaps pins the compute and snapshot versions it parses rather than tracking latest, so a change on Azure's side becomes a deliberate upgrade instead of parsing that silently drifts out of step with what is returned.
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
Why does VPS Snaps run as its own app, not as me?
Because a delegated OAuth token belongs to a person. An administrator resetting their account, revoked sessions, a Conditional Access policy or that person leaving the company all end it — and for a job that runs unattended at 02:00, that means backups stopping with nobody watching. So signing in is used once, to give VPS Snaps' own app access in your directory; it has no user session to lose, and nothing of yours is kept but the tenant and subscription ids.
What permissions does it actually need?
Signed in: Reader, and a VPS Snaps role defined on that one subscription with exactly what the product does there — create and delete snapshots and disks, build, power and destroy virtual machines with their network cards, public addresses, networks and firewall rules (recovery servers, test restores, failover), and create a resource group for test machines. It cannot read your storage accounts or their keys, databases or key vaults, run commands on your machines, change DNS, or grant anyone anything; and it destroys only what it created and tagged. Like any role that can snapshot a disk, it can export a disk's contents — Azure requires that of every snapshot — and VPS Snaps never does. Its full list is in Access control (IAM) → Roles. Not Microsoft's Disk Snapshot Contributor: despite its name, that role can also list the keys of and delete every storage account.
How many snapshots does one run create?
One per attached managed disk. A single-disk VM produces one; a VM with an OS disk and two data disks produces three, all created in the same run and all deleted together when the run ages out. Azure bills each of them for the storage it occupies, which is why retention pruning is automatic rather than optional.
Can I restore a snapshot without VPS Snaps?
Yes. They are ordinary Microsoft.Compute/snapshots resources in your own subscription, visible in the portal and usable from the CLI. Create a managed disk from one and attach it, exactly as you would with a snapshot you took by hand. Cancel VPS Snaps tomorrow and every snapshot already taken is still there and still yours.
Does this work with Azure SQL or Azure Database for PostgreSQL?
No — those are managed database services with no VM and no disk to snapshot, so this integration does not reach them. A database job pointed at the server over the network is the route for those, and Azure's own backup features cover point-in-time restore within the platform.
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 virtual machine on Microsoft Azure and nowhere else. For a copy you can carry anywhere, add a database, file or Docker job on the same virtual machine — 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 Microsoft Azure backup tonight.
Connect the account, pick a virtual machine, 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.