Every IT professional has lived through some version of this moment: someone runs a script against production instead of staging. A “temporary” DELETE statement forgets its WHERE clause. A ransomware notice pops up on a Monday morning. A region goes dark for six hours and nobody saw it coming.
In every one of those stories, there are two kinds of people: the ones who had a good backup and restore strategy, and the ones who are now explaining to leadership why the company just lost three days of customer orders.
Azure Backup & Restore is the toolkit that keeps you in the first group. It’s not one single button — it’s a set of overlapping capabilities (Azure Backup the service, plus native backup features baked into individual Azure data services) that together answer three very different questions: “Can I undo something that happened five minutes ago?” “Can I recover if an entire Azure region disappears?” and “Can I produce a database snapshot from three years ago for an auditor?”
Those three questions map almost exactly onto Point-in-Time Restore (PITR), Geo-Restore, and Long-Term Retention (LTR) — the three concepts this article spends the most time on, because confusing them is one of the most common (and expensive) mistakes teams make when designing a recovery strategy.
The Big Picture: What “Azure Backup” Actually Covers
Before zooming into the three concepts above, it helps to know the landscape:
- Azure Backup is Microsoft’s centralized backup service, built around Recovery Services vaults (and newer Backup vaults for certain workloads). It protects Azure VMs, Azure Files, SQL Server running on Azure VMs, SAP HANA, and more, plus can reach on-premises machines via the Microsoft Azure Backup Server (MABS) agent.
- Platform-native backup is different — it’s built directly into a data service. Azure SQL Database, Azure Database for PostgreSQL, and Cosmos DB all have their own automatic backup systems that don’t route through a Recovery Services vault at all. This is where PITR, Geo-Restore, and LTR most commonly live.
- Azure Site Recovery (ASR) is a cousin, not a sibling — it’s about replicating entire running workloads to another region for disaster recovery (near-zero downtime failover), which is a different job than backup (recovering data from a point in the past). It’s worth knowing they’re not the same tool, because “we have backups” and “we have disaster recovery” are two different sentences.
With that map in place, let’s get into the part most people actually search for.
Point-in-Time Restore (PITR): Undoing “Five Minutes Ago”
PITR is your rewind button. Most Azure data services (Azure SQL Database, SQL Managed Instance, PostgreSQL Flexible Server, and others) take automatic backups continuously in the background — typically a full backup roughly weekly, differential backups every 12–24 hours, and transaction log backups every few minutes. When you ask for a point-in-time restore, Azure reconstructs the database’s exact state at the timestamp you specify by replaying that chain: full backup, then differential, then transaction logs, right up to the second you asked for.
What it’s good for: accidental data corruption, a bad deployment, an errant DELETE or UPDATE, a botched schema migration — anything where the data itself got damaged but the infrastructure is fine.
What it’s not good for: an entire region going offline. PITR restores create a new database, usually on the same server, in the same region as the original. If that region is the thing that’s down, PITR can’t help you — which is exactly why geo-restore exists.
Real-world example: A SaaS company’s support team gets a frantic call — a customer’s entire order history vanished after an internal maintenance script ran with the wrong filter. The on-call engineer doesn’t panic, because they know the transaction logs are backed up roughly every ten minutes. They restore the database to a new name, targeting the moment just before the script ran:
az sql db restore \
--resource-group ecommerce-prod-rg \
--server prod-sql-server \
--name orders-db \
--dest-name orders-db-restored-preincident \
--time "2026-07-28T02:14:00Z"
Twenty minutes later, they’ve pulled the missing order records out of the restored copy and reinserted just those rows into production — without taking the live database offline or losing any of the good data written after the mistake.
One detail people trip over: you can even restore a database that was deleted entirely, as long as you’re within the retention window and you know the deletion time:
az sql db restore \
--resource-group ecommerce-prod-rg \
--server prod-sql-server \
--name orders-db \
--dest-name orders-db-recovered \
--deleted-time "2026-07-28T09:00:00Z" \
--time "2026-07-28T08:55:00Z"
Geo-Restore: Surviving a Regional Disaster
Geo-restore is what you reach for when the problem isn’t “bad data,” it’s “the entire region is gone.” Because PITR backups are stored on geo-redundant storage by default in most Azure SQL configurations, a copy of your backup chain already exists in Azure’s paired region — geo-restore simply lets you stand up a new database from that copy, in a different region than the one that just had a bad day.
What it’s good for: regional outages, region-wide service disruptions, or disaster recovery drills where you need to prove your team can actually bring the business back up somewhere else.
What it costs you: geo-restore isn’t instantaneous, and it isn’t “up to the second.” Because it relies on geo-replicated backup data, there’s typically some replication lag — you should expect a recovery point objective (RPO) of up to roughly an hour, not seconds. If your business genuinely cannot tolerate that gap (think: trading platforms, payment processors), geo-restore alone isn’t enough — you’d pair it with active geo-replication or failover groups, which keep a continuously synchronized secondary database ready to take over almost instantly.
Real-world example: A logistics company’s primary Azure region has a multi-hour outage during a severe weather event that knocks out a datacenter’s cooling systems. Rather than sitting and waiting, their DR runbook kicks off a geo-restore of their SQL Database into a secondary region hundreds of miles away. Within the hour, their dispatch system is back online in the new region — routing trucks and processing deliveries — while the original region is still recovering. It’s not a seamless zero-downtime failover (that’s what failover groups are for), but it turns what could have been a full-day outage into an hour-long blip.
Long-Term Retention (LTR): Backups for Compliance, Not Just Recovery
LTR solves a completely different problem than the first two. PITR and geo-restore are about operational recovery — getting back to a recent good state quickly. LTR is about retention — being able to produce a database as it existed years ago, because a regulator, auditor, or legal team asked for it.
Standard automated backups typically only stick around for a matter of weeks (commonly up to 35 days). LTR lets you configure separate weekly, monthly, or yearly backups that are retained for up to 10 years, stored independently of your regular short-term backup chain. You can even mark LTR backups as immutable, meaning nobody — not even an admin — can delete or alter them before their retention period expires, which matters a lot when the whole point is proving to an auditor that the data wasn’t tampered with.
What it’s good for: regulatory compliance (financial services, healthcare, government contracts), legal holds, and situations where “we need last year’s Q3 snapshot for an audit” is a completely normal Tuesday request.
What it’s not meant for: fast operational recovery. Restoring from a multi-year-old LTR backup isn’t something you’d do to fix a bug from this morning — that’s PITR’s job.
Real-world example: A healthcare software vendor is subject to regulations requiring that patient billing records be reproducible for seven years. Their standard PITR retention is set to 35 days — plenty for operational recovery, useless for a compliance audit. So they configure an LTR policy that keeps a monthly backup for 7 years and a yearly backup for 10, all marked immutable. Two years later, when an auditor asks for proof of a specific patient record’s state from a particular quarter, the compliance team restores the relevant LTR backup, pulls the record, and closes the request — without ever touching the live production database.
PITR vs. Geo-Restore vs. LTR: Side-by-Side
| Point-in-Time Restore (PITR) | Geo-Restore | Long-Term Retention (LTR) | |
|---|---|---|---|
| Solves for | Undoing recent data damage | Surviving a regional outage | Long-term compliance & audit needs |
| Typical retention window | Up to 35 days | Same as PITR retention (backups are geo-replicated) | Up to 10 years |
| Restore location | Same server/region as original | A different (paired) region | Any server/region, per policy |
| Granularity | Near-continuous (down to minutes, via transaction logs) | Coarser — RPO up to ~1 hour | Whatever backup interval you configured (weekly/monthly/yearly) |
| Typical use case | “Someone deleted rows an hour ago” | “Our region just went down” | “We need a database snapshot from 2 years ago” |
| Speed to restore | Fast | Slower (cross-region, and some replication lag) | Depends on backup age/size; not built for speed |
| Immutability option | No | No | Yes (in Azure SQL Database) |
The short version: PITR is your undo button, geo-restore is your disaster recovery plan, and LTR is your filing cabinet for auditors. Mature backup strategies use all three together, not as alternatives to each other.
Where Azure Backup (the Service) Fits Alongside All This
Everything above focused on database-native backup features, but it’s worth circling back to Azure Backup itself, since a lot of real environments protect more than just databases.
Real-world example: A mid-sized manufacturing firm runs a mix of Azure VMs (their ERP application servers), Azure Files shares (shared engineering drawings), and an on-premises file server that hasn’t been migrated yet. They centralize protection for all of it in a single Recovery Services vault:
- VM backups run nightly, retained for 30 days, with instant restore available for the first two days (so a bad OS update on a VM can be undone in minutes, not hours).
- Azure Files snapshots protect against a user accidentally deleting a folder of CAD files — restorable to any snapshot point without restoring the whole share.
- The on-prem file server backs up to the same vault via the MABS agent, so their entire backup estate — cloud and on-prem — shows up in one dashboard instead of three disconnected tools.
- The vault itself is configured with geo-redundant storage (GRS), so even if the primary region is lost, the backup data survives in the paired region — and soft-delete is enabled, so a compromised admin account (or a ransomware attack) can’t simply delete the backups to cover its tracks.
That last point deserves its own mention: Azure Backup’s soft delete feature keeps deleted backup data recoverable for a period after “deletion,” specifically as a defense against ransomware scenarios where an attacker with admin access tries to destroy your backups before encrypting your data. It’s a small feature that has saved more than a few companies from a very bad week.
Putting It Together: A Sane Backup Strategy
If you’re building this out for the first time, here’s a reasonable shape to aim for:
- Enable short-term automated backups (PITR) on every production database by default — for most Azure SQL/PostgreSQL services, this is on automatically; just make sure the retention window (commonly configurable up to 35 days) actually matches how quickly your team tends to notice problems.
- Confirm geo-redundant storage is enabled on your backups so geo-restore is actually available if you need it — don’t assume; check the storage redundancy setting.
- Layer in LTR for anything compliance-relevant, and mark it immutable if your industry requires tamper-proof records.
- Use a Recovery Services vault for VMs, file shares, and anything outside the “database with native backup” category, and turn on soft delete.
- Actually test a restore before you need one for real. A backup you’ve never restored from is a theory, not a plan — and the CloudWebSchool line about teams discovering their restore process is broken during an incident is a genuinely common story, not a scare tactic.
Key Takeaways
- PITR is for fast, granular recovery from recent data mistakes — think minutes to weeks in the past, same region.
- Geo-restore is for surviving a regional disaster — recovers from geo-replicated backups into a different region, with a coarser recovery point.
- LTR is for compliance and audit needs — years of retained backups, restorable on demand, optionally immutable.
- Azure Backup (Recovery Services vaults) is the broader service protecting VMs, files, and on-prem machines — complementary to, not a replacement for, the native backup features built into services like Azure SQL Database.
- The best strategies don’t pick one of these — they use PITR, geo-restore, and LTR together, each covering a different kind of “oh no” moment, and they test the restore process before an actual emergency forces the issue.
Discover more from Technology with Vivek Johari
Subscribe to get the latest posts sent to your email.
