Microsoft Azure
Every disk on the VM, not just the one that boots
Register an app in Microsoft Entra ID, give it Disk Snapshot Contributor and Reader on the 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.
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
Service principal
Four values from an Entra ID app registration. Deliberately not OAuth: a delegated token is issued against a person, and a password change, an MFA re-registration or that person leaving revokes it — which for an unattended nightly job means backups stopping silently.
In Microsoft Entra ID, create an app registration and add a client secret. Note its Directory (tenant) ID and Application (client) ID.
On the subscription you want to protect, assign that app the Disk Snapshot Contributor and Reader roles — enough to list VMs and snapshot their disks, and nothing more.
Paste the tenant ID, client ID, client secret and subscription ID into VPS Snaps. The connection test names the subscription back to you, which is how you confirm you scoped it to the one you meant.
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 a service principal instead of signing in with Microsoft?
Because a delegated OAuth token belongs to a person. A password change, an MFA re-registration, a Conditional Access policy or that person leaving the company all revoke it — and for a job that runs unattended at 02:00, that means backups stopping with nobody watching. A service principal has no user session to lose, and you scope it to exactly the subscription and role you intend.
What permissions does it actually need?
Disk Snapshot Contributor and Reader on the subscription. Reader lets it list your VMs and read which disks are attached; Disk Snapshot Contributor lets it create and delete snapshot resources. It cannot start, stop, resize or delete a VM, and it cannot read the contents of a disk. Assign the roles on a single resource group instead if you want the blast radius smaller still.
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.
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.
“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.