Why Long-Term Retention (LTR) Backups Don’t Attach After a PITR Restore in Azure SQL Database
Summary Customers sometimes expect that after performing a Point‑in‑Time Restore (PITR) and renaming the restored database back to its original name, existing Long‑Term Retention (LTR) backups will automatically appear and continue from where they left off. This behavior may have worked in older or legacy environments, but in modern Azure SQL Database deployments—especially across new servers or subscriptions—this expectation can lead to confusion. This article explains why LTR backups do not attach to restored databases, even if the database name is reused, and what customers should expect instead. The Scenario The discussion originated from a common migration pattern: A customer has an Azure SQL Database with LTR policies configured (for example, monthly backups retained for 10 years). The customer performs a Point‑in‑Time Restore (PITR) of that database. After the restore, the database is renamed to match the original database name. The customer expects the existing LTR backups to appear under the restored database. In legacy environments, this behavior appeared to work. However, in newer Azure SQL Database deployments, the LTR backups are not visible after the restore and rename process. Key Technical Detail: LTR Is Not Based on Database Name The most important concept to understand is this: LTR backups are associated with the database’s logical database ID—not the database name. Each Azure SQL Database is assigned a unique logical database ID at creation time. When a PITR restore is performed: A new database is created It receives a new logical database ID Even if you rename the database to match the original name, the logical ID remains different As a result, the restored database is treated as a completely new database from an LTR perspective, and it does not inherit the historical LTR backup chain. Why Renaming the Database Does Not Help Renaming a database only changes its display name. It does not change: The logical database ID The internal association used by the LTR system Because LTR configuration and backup visibility are tied to the logical database ID, renaming alone cannot reattach historical LTR backups. Subscription Boundaries Matter Another important clarification raised in the discussion: LTR backups are scoped to the subscription where the database was created While you can restore LTR backups to a different server within the same subscription, you cannot carry historical LTR backups across subscriptions If a customer migrates to a new subscription, the historical LTR chain from the old subscription cannot be reused or reattached. Only new LTR backups created after the move will exist in the new subscription. What Customers Will Observe After a PITR restore and rename: ✅ The database is successfully restored ✅ LTR policies can be configured again ❌ Historical LTR backups from the original database are not visible ❌ The restored database does not inherit old LTR backups, even if the name matches This is expected behavior and aligns with the current Azure SQL Database architecture. How to Validate LTR Backups Correctly To avoid confusion caused by portal caching or UI expectations, customers can list LTR backups programmatically using PowerShell or Azure CLI, as documented in Microsoft Learn: Azure SQL Database: Manage long-term backup retention Azure SQL Database: Manage long-term backup retention - Azure SQL Database | Microsoft Learn This confirms whether LTR backups exist for a specific logical database ID. Best Practices and Recommendations Do not rely on database renaming to preserve LTR history. Treat any PITR restore as a new database from an LTR perspective. If historical LTR backups must remain accessible: Keep the original database intact Restore LTR backups directly from the original database when needed Plan migrations carefully, especially when moving across subscriptions, as LTR history cannot be migrated. Final Thoughts LTR backups are a powerful compliance and recovery feature in Azure SQL Database, but they are intentionally designed to be immutable and identity‑based, not name‑based. Understanding that logical database ID—not database name—controls LTR association helps set correct expectations and avoids surprises during restores or migrations. Frequently Asked Questions (FAQ) Q1: Why don’t my existing LTR backups appear after I restore a database using PITR? Because a Point‑in‑Time Restore (PITR) creates a new database with a new logical database ID. Long‑Term Retention (LTR) backups are associated with the database’s logical ID—not its name—so the restored database does not inherit the historical LTR backup chain. Q2: If I rename the restored database to the original name, shouldn’t the LTR backups reappear? No. Renaming a database only changes its display name. It does not change the logical database ID, which is what LTR uses to associate backups. As a result, renaming does not reattach existing LTR backups. Q3: This used to work in our legacy environment—why is it different now? In older environments, the behavior may have appeared to work due to differences in platform implementation. In current Azure SQL Database architecture, LTR association is strictly identity‑based, which ensures immutability, compliance, and predictable backup behavior. Q4: Can I attach historical LTR backups to a restored database manually? No. LTR backups are immutable and cannot be reattached or reassigned to a different logical database ID. This behavior is by design. Q5: What happens if I move my database to a new subscription? LTR backups are scoped to the subscription where the database was created. If you migrate to a new subscription: Historical LTR backups from the old subscription cannot be carried over Only new LTR backups created after the move will exist in the new subscription Q6: Can I still restore from my old LTR backups? Yes. As long as the original database (or its logical identity) still exists in the original subscription, you can restore directly from those LTR backups—even if a newer database with the same name exists elsewhere. Q7: How can I verify which LTR backups actually exist? The most reliable way is to list LTR backups programmatically using Azure PowerShell or Azure CLI, which queries backups by logical database ID rather than relying solely on portal views. Refer to the official documentation: Azure SQL Database – Manage long‑term backup retention Q8: What is the recommended approach if we need long‑term recoverability after PITR? Treat every PITR restore as a new database from an LTR perspective Keep the original database intact if historical LTR backups must remain accessible Plan subscription migrations carefully, as LTR history cannot be migratedUnlocking Flexibility with Azure Files Provisioned V2
In this episode of E2E:10-Minute Drill, host Pierre Roman sits down with Will Gries, Principal PM in Azure Storage, to explore the newly released Azure Files Provisioned V2 billing model. This model introduces a game-changing approach to cloud file storage by allowing users to provision storage, IOPS, and throughput independently—a major leap forward in flexibility and cost optimization. 📺 Watch the full episode: https://youtu.be/Tb6y0fvJBMs Previously, Standard Azure Files used a pay-as-you-go model where you pay per GB of storage plus transaction fees for every file operation (reads, writes, lists, etc.). That often made bills hard to predict. There was also a Premium tier (Provisioned V1 on SSDs, where you pre-allocated capacity; that gave you fixed performance and no transaction charges, but you might have to over-provision storage to get more IOPS, whether you needed that extra space or not. Provisioned V2 changes the game... You can now pre-provision your storage, IOPS, and throughput you need for a file share. That’s what you pay for – and nothing more. There are no per-operation fees at all in V2. It’s like moving from a metered phone plan to an unlimited plan: a stable bill each month, and you can adjust your “plan” up or down as needed. Key Benefits of Provisioned V2 Predictable (and Lower) Costs: No more paying for every single read/write. You pay a known monthly rate based on the resources you reserve. This means no surprise spikes in cost when your usage increases. In many cases, Provisioned V2 actually lowers the total cost for active workloads. Microsoft has noted that common workloads might save on the order of 30–50% compared to the old pay-as-you-go model, thanks to lower storage prices and zero transaction fees. High Performance on Demand: Each file share can now scale up to 50,000 IOPS and 5 GiB/sec throughput, and support up to 256 TiB of data in a single share. That’s a big jump from the old limits. More importantly, you’re in control of the performance: if you need more IOPS or bandwidth, you can dial it up anytime (and dial it down later if you overshot). Provisioned V2 also includes burst capacity for short spikes, so your share can automatically handle occasional surges above your baseline IOPS. Bottom line – your Azure Files can now handle much larger and more IO-intensive workloads without breaking a sweat. Simpler Management & Planning: Forget about juggling Hot vs Cool vs Transaction Optimized tiers or guessing at how many transactions you’ll run. With V2, every Standard file share works the same way – you just decide how much capacity and performance to provision. This makes it much easier to plan and budget. You can monitor each share’s usage with new per-share metrics (Azure shows you how much of your provisioned IOPS/throughput you’re using), which helps right-size your settings. If you’re syncing on-prem file servers to Azure with Azure File Sync, the predictable costs and higher limits of V2 make your hybrid setup easier to manage and potentially cheaper, too. Azure Files provisioned v2 billing model for flexibility, cost savings, and predictability | Microsoft Community Hub Provisioned V2 makes Azure Files more cloud-friendly and enterprise-ready. Whether you’re a new user or have been using Azure Files for years, this model offers a win-win: you get more control and performance, and you eliminate the unpredictable bills. If you have heavy usage, you’ll appreciate the cost savings and headroom. If you have lighter usage, you’ll enjoy the simplicity and peace of mind. Overall, if you use Azure Files (or are planning to), Provisioned V2 is likely to make your life easier and your storage costs lower. It’s a welcome upgrade that addresses a lot of customer pain points in cloud file storage. If you're looking to optimize your Azure storage strategy, this episode is a must-watch. 🔗 Explore all episodes: https://aka.ms/E2E-10min-Drill Resources: Azure Storage Blog – Provisioned V2 Announcement (Jan 2025):“Azure Files provisioned v2 billing model for flexibility, cost savings, and predictability” – Official blog post introducing Provisioned V2, with details on the new limits and pricing model. (Microsoft Tech Community)Microsoft Azure Blog (Apr 2025):“Azure Files: More performance, more control, more value for your file data” – Azure blog highlighting the increased performance and value offered by Azure Files (including the new billing model). Microsoft Learn – Understand Azure Files Billing Models: Documentation explaining Azure Files billing, with sections on the Provisioned V2 model and how it differs from previous models. Cheer! Pierre
