Azure Backup for PostgreSQL flexible server and elastic cluster (v2) is now in public preview
Azure Backup for PostgreSQL flexible servers and elastic clusters (v2) is now in public preview. Built on physical, snapshot-based backups, v2 brings scalable protection, flexible retention and streamlined recovery to PostgreSQL estates of all sizes. It helps customers improve data resiliency through vaulted backups and support compliance requirements with long-term retention of backups. Organizations can protect larger databases, back them up more frequently and restore them directly to a server when recovery is needed. What v2 can do V2 protects both Azure Database for PostgreSQL flexible servers and elastic clusters. It supports databases of up to 32 TB on Premium SSD v1 and up to 64 TB on Premium SSD v2, including production configurations with high availability, virtual network or private endpoint connectivity through Trusted Access, and Customer Managed Key encryption. You can schedule backups daily or weekly, with a recovery point objective goal of one day, and create on-demand backups whenever an additional recovery point is required. The first backup is full and subsequent backups are incremental, enabling a practical daily protection cadence even for multi-terabyte databases. Retention can range from 7 days to 10 years. Separate daily, weekly, monthly and yearly retention rules make it possible to align one policy with both operational recovery and long-term compliance requirements. Recovery points are stored in an Azure Backup vault and can use the platform protections organizations already rely on: Soft delete and WORM immutability to protect backups from premature deletion or alteration. Multi-user authorisation and MFA for sensitive operations. Customer Managed Key encryption and cross-subscription vaulting within the same tenant. Central monitoring and management through Backup center. Restore as Server Restore as Server turns a recovery point into a ready-to-use PostgreSQL environment by restoring it directly to a pre-created flexible server or elastic cluster. Unlike Restore as Files, which writes the backup to a storage container and requires a separate manual import into PostgreSQL, Restore as Server removes that intermediate phase. This reduces operational effort, shortens the path to application recovery and provides a more consistent restore experience at scale. How v2 improves on v1 V2 moves from logical exports to physical backups created from managed disk snapshots. This architectural change expands the service from the 1 TB limit in v1 to as much as 64 TB on supported storage, while incremental backups make daily schedules possible instead of limiting vaulted backups to a weekly full copy. The new solution also extends protection to elastic clusters and introduces direct restoration to a server. Together, these improvements provide broader workload coverage, more frequent recovery points and a simpler path from backup to a usable PostgreSQL environment. How to get started with v2 You can configure v2 in the Azure portal from a Backup vault, the Resiliency experience, or the LTR (Vaulted Backups) pane of the flexible server. Each entry point leads to the same policy and protection workflow. Before enabling protection, confirm that the server meets the preview requirements and check details on supported scenarios and limitations. Once eligibility is confirmed, create or select a Backup vault, define the schedule and retention rules that fit your recovery objectives, and enable protection for the server or elastic cluster. For PostgreSQL flexible server and elastic cluster vaulted backup v2 (preview), you incur charges from 15 October 2026. Refer to Azure Backup pricing page and pricing calculator for more details. How to migrate from v1 to v2 Existing protected items can be moved to v2 while retaining the same policy and Backup vault. The protected item and its existing recovery points are preserved, allowing organisations to adopt the new capabilities without losing backups already retained for operational or compliance needs. The migration is one way, so review readiness before starting. Servers running PostgreSQL 14 or earlier must first be upgraded to PostgreSQL 15 or later, and servers on the Burstable tier must be scaled to General Purpose or Memory Optimized. With those prerequisites complete, the move to v2 opens the way to larger-scale protection, daily incremental backups, elastic cluster coverage and direct server recovery—all while preserving the continuity of your existing backup estate.Applying DevOps Principles on Lean Infrastructure. Lessons From Scaling to 102K Users.
Hi Azure Community, I'm a Microsoft Certified DevOps Engineer, and I want to share an unusual journey. I have been applying DevOps principles on traditional VPS infrastructure to scale to 102,000 users with 99.2% uptime. Why am I posting this in an Azure community? Because I'm planning migration to Azure in 2026, and I want to understand: What mistakes am I already making that will bite me during migration? THE CURRENT SETUP Platform: Social commerce (West Africa) Users: 102,000 active Monthly events: 2 million Uptime: 99.2% Infrastructure: Single VPS Stack: PHP/Laravel, MySQL, Redis Yes - one VPS. No cloud. No Kubernetes. No microservices. WHY I HAVEN'T USED AZURE YET Honest answer: Budget constraints in emerging market startup ecosystem. At our current scale, fully managed Azure services would significantly increase monthly burn before product-market expansion. The funding we raised needs to last through growth milestones. The trade: I manually optimize what Azure would auto-scale. I debug what Application Insights would catch. I do by hand what Azure Functions would automate. DEVOPS PRACTICES THAT KEPT US RUNNING Even on single-server infrastructure, core DevOps principles still apply: CI/CD Pipeline (GitHub Actions) • 3-5 deployments weekly • Zero-downtime deploys • Automated rollback on health check failures • Feature flags for gradual rollouts Monitoring & Observability • Custom monitoring (would love Application Insights) • Real-time alerting • Performance tracking and slow query detection • Resource usage monitoring Automation • Automated backups • Automated database optimization • Automated image compression • Automated security updates Infrastructure as Code • Configs in Git • Deployment scripts • Environment variables • Documented procedures Testing & Quality • Automated test suite • Pre-deployment health checks • Staging environment • Post-deployment verification KEY OPTIMIZATIONS Async Job Processing • Upload endpoint: 8 seconds → 340ms • 4x capacity increase Database Optimization • Feed loading: 6.4 seconds → 280ms • Strategic caching • Batch processing Image Compression • 3-8MB → 180KB (94% reduction) • Critical for mobile users Caching Strategy • Redis for hot data • Query result caching • Smart invalidation Progressive Enhancement • Server-rendered pages • 2-3 second loads on 4G WHAT I'M WORRIED ABOUT FOR AZURE MIGRATION This is where I need your help: Architecture Decisions • App Service vs Functions + managed services? • MySQL vs Azure SQL? • When does cost/benefit flip for managed services? Cost Management • How do startups manage Azure costs during growth? • Reserved instances vs pay-as-you-go? • Which Azure services are worth the premium? Migration Strategy • Lift-and-shift first, or re-architect immediately? • Zero-downtime migration with 102K active users? • Validation approach before full cutover? Monitoring & DevOps • Application Insights - worth it from day one? • Azure DevOps vs GitHub Actions for Azure deployments? • Operational burden reduction with managed services? Development Workflow • Local development against Azure services? • Cost-effective staging environments? • Testing Azure features without constant bills? MY PLANNED MIGRATION PATH Phase 1: Hybrid (Q1 2026) • Azure CDN for static assets • Azure Blob Storage for images • Application Insights trial • Keep compute on VPS Phase 2: Compute Migration (Q2 2026) • App Service for API • Azure Database for MySQL • Azure Cache for Redis • VPS for background jobs Phase 3: Full Azure (Q3 2026) • Azure Functions for processing • Full managed services • Retire VPS QUESTIONS FOR THIS COMMUNITY Question 1: Am I making migration harder by waiting? Should I have started with Azure at higher cost to avoid technical debt? Question 2: What will break when I migrate? What works on VPS but fails in cloud? What assumptions won't hold? Question 3: How do I validate before cutting over? Parallel infrastructure? Gradual traffic shift? Safe patterns? Question 4: Cost optimization from day one? What to optimize immediately vs later? Common cost mistakes? Question 5: DevOps practices that transfer? What stays the same? What needs rethinking for cloud-native? THE BIGGER QUESTION Have you migrated from self-hosted to Azure? What surprised you? I know my setup isn't best practice by Azure standards. But it's working, and I've learned optimization, monitoring, and DevOps fundamentals in practice. Will those lessons transfer? Or am I building habits that cloud will expose as problematic? Looking forward to insights from folks who've made similar migrations. --- About the Author: Microsoft Certified DevOps Engineer and Azure Developer. CTO at social commerce platform scaling in West Africa. Preparing for phased Azure migration in 2026. P.S. I got the Azure certifications to prepare for this migration. Now I need real-world wisdom from people who've actually done it!
Pipeline Intelligence is live and open-source real-time Azure DevOps monitoring powered by AI .
Every DevOps team I've worked with had the same problem: Slow pipelines. Zero visibility. No idea where to start. So I stopped complaining and built the solution. So I built something about it. ⚡ Pipeline Intelligence is a full-stack Azure DevOps monitoring dashboard that: ✅ Connects to your real Azure DevOps organization via REST API ✅ Detects bottlenecks across all your pipelines automatically ✅ Calculates exactly how much time your team is wasting per month ✅ Uses Gemini AI to generate prioritized fixes with ready-to-paste YAML solutions ✅ JWT-secured, Docker-ready, and fully open-source Tech Stack: → React 18 + Vite + Tailwind CSS → Node.js + Express + Azure DevOps API v7 → Google Gemini 1.5 Flash → JWT Authentication + Docker 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁? Most tools show you generic estimates. Pipeline Intelligence reads your actual cluster config, node count, and pipeline structure and gives you recommendations specific to your infrastructure. 🎯 This year, I set myself a personal challenge: Build and open-source a series of production-grade tools exclusively focused on Azure services tools that solve real problems for real DevOps teams. This project represents weeks of research, architecture decisions, and late-night debugging sessions. I'm sharing it with the community because I believe great tooling should be accessible to everyone not locked behind enterprise paywalls. If this resonates with you, I have one simple ask: 👉 A like, a comment, or a share takes 3 seconds but it helps this reach the DevOps engineers who need it most. Your support is what keeps me building. ❤️ GitHub: https://github.com/HlaliMedAmine/pipeline-intelligenceExcited to share my latest open-source project: KubeCost Guardian
After seeing how many DevOps teams struggle with Kubernetes cost visibility on Azure, I built a full-stack cost optimization platform from scratch. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀: ✅ Real-time AKS cluster monitoring via Azure SDK ✅ Cost breakdown per namespace, node, and pod ✅ AI-powered recommendations generated from actual cluster state ✅ One-click optimization actions ✅ JWT-secured dashboard with full REST API 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸: - React 18 + TypeScript + Vite - Tailwind CSS + shadcn/ui + Recharts - Node.js + Express + TypeScript - Azure SDK (@azure/arm-containerservice) - JWT Authentication + Azure Service Principal 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁: Most cost tools show you generic estimates. KubeCost Guardian reads your actual VM size, node count, and cluster configuration to generate recommendations that are specific to your infrastructure not averages. For example, if your cluster has only 2 nodes with no autoscaler enabled, it immediately flags the HA risk and calculates exactly how much you'd save by switching to Spot instances based on your actual VM size. This project is fully open-source and built for the DevOps community. ⭐ GitHub: https://github.com/HlaliMedAmine/kubecost-guardian This project represents hours of hard work, and passion. I decided to make it open-source so everyone can benefit from it 🤝 ,If you find it useful, I’d really appreciate your support . Your support motivates me to keep building and sharing more powerful projects 👌. More exciting ideas are coming soon… stay tuned! 🔥.
Replicate workload from VMWare to Azure using Azure Site Recovery(ASR)
Hello, I am working on a project to replicate worklooad hosted on a VMWare to Azure Site Recovery for disaster recovery purpose. Current Environment: More than 80 VMs hosted on VMWare managed by VMWare Sphere running both Linux and Windows OS.. Databases: Oracle DB, Microsoft SQL and MySQL Requirements: seamless failover and disaster recovery requirements. scalable setup No down-time integrate identity and access mgt. integration with Microsoft Entra ID. RTO < 2 hrs and RPO > 15 minutes Backup: critical database backup every 3 hours App servers: Daily*incremental) and weekly (full) Transaction Logs: every 10 mins backup config. should be Daily Questions I have confirmed ASR supports fail back from Azure- on premise(VMWare specifically). Hence ASR(Azure site recovery) will be used for the project. However, what is the seamless method to replicate the databases(Oracle, Microsoft SQL and MySQL). https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-failback What is the best approach to replicate the Application Servers? integrating existing on-premise 3rd party network security tool for firewall etc instead of the azure cloud native security tool. recommendation?? cost optimization techniques/recommendations Best practices for conducting non-destructive DR drills.
Backing up Azure Files - High cost Read operations
I have found that Azure Files is unusable for large deployments due to the high cost of backups, especially for deployments with lots of small files. Most backup solutions have a changed block tracking mechanism and filter driver that can quickly determine what has changed between the prior backup. If nothing has changed since the last backup, the job quickly makes this determination and the backup job can take seconds to complete. But with Azure Backup backing up Azure Files, it appears to me that each backup has to enumerate every file and blob before making this determination. I first noticed this when I created a 1TB file share and nothing changed with the files from the prior backup and the job took 12 hours to complete. I then looked at my bill and it was $12 in read operations just for that backup where no files have changed. Azure Files is an awesome product, but securing your backups in a vault using Azure Backup just isn't doable from a price perspective. Does anyone know if there are changes on the horizon to Azure Backup in terms of a more robust change block tracking system?Protect Azure Data Lake Storage with Vaulted Backups
Update 11/21/2025: Vaulted Backup for Azure Data Lake Storage is now generally available! For more information refer to Generally Available: Vaulted Backup for Azure Data Lake Storage (ADLS) --- Original Blog --- We are thrilled to announce a limited public preview of vaulted backups for Azure Data Lake Storage. This is available now for test workloads and we’d like to get your feedback. Vaults are secure, encrypted copies of your data, enabling restoration to an alternate location in cases of accidental or malicious deletion. Vaulted backups are fully isolated from the source data, ensuring continuity for your business operations even in scenarios where the source data is compromised. This fully managed solution leverages the Azure Backup service to manage backups with automated retention and scheduling. By creating a backup policy, you can define a backup schedule and retention period. Based on this policy, Azure Backup service generates recovery points and manages the lifecycle of backups seamlessly. Ways vaulted backups protect your data: Isolation from Production Data – Vaulted backups are stored in a separate, Microsoft-managed tenant, preventing attackers from accessing both primary and backup data. Strict Access Controls – Backup management requires distinct permissions, ensuring segregation of duties and reducing insider threats. Advanced Security Features – With features like soft delete, immutability, and encryption, vaulted backups safeguard data against unauthorized modifications and premature deletions. Even if attackers compromise the primary storage account, backups remain secure within the vault, preserving data integrity and ensuring compliance. Alternate location recovery - Vaulted backups provide a reliable recovery solution by enabling restoration to an alternate storage account, ensuring business continuity even when the original account is inaccessible. Additionally, this capability allows organizations to create separate data copies for purposes such as testing, development, or analytics, without disrupting production environments. Granular recovery - With vaulted backups, you can restore the entire storage account or specific containers based on your needs. You can also use prefix matching to recover select blobs. With the growing frequency and sophistication of cyberattacks, protecting your data against loss or corruption is more critical than ever. Consider the following example use case where having vaulted backups can save the day. Enhanced Protection Against Ransomware Attacks Ransomware attacks can encrypt critical data, complicating recovery unless a ransom is paid. Vaulted backups offer an independent and secure recovery solution, allowing you to restore data without succumbing to attackers' demands. Accidental or Malicious Storage Account Deletion Human errors, insider threats, or compromised credentials can result in the deletion of entire storage accounts. Vaulted backups provide a crucial layer of protection by storing backups in Microsoft-managed storage, independent of your primary storage account. This ensures that an additional copy of your data remains intact, even if the original storage account is accidentally or maliciously deleted. Compliance Regulations Certain industries mandate offsite backups and long-term data retention to meet regulatory standards. Vaulted backups enable organizations to comply by offering offsite backup storage within the same Azure region as the primary storage account. With vaulted backups, data can be retained for up to 10 years. Getting started Vaulted backups can be configured for block blobs within HNS-enabled, standard general-purpose v2 ADLS storage accounts in specified regions here. Support for additional regions will be added incrementally. Currently, this preview is recommended exclusively for testing purposes. The Azure Backup protected instance fee and the vault backup storage fees are not currently charged. Now is a great time to give vaulted backups a try! Contact us If you have questions or feedback, please reach out to us at AskAzureBackupTeam@microsoft.com.Azure Policy - Configure backup on virtual machines with a given tag
I wonder if somebody could sanity check something for me with this please in case it's something I could be missing. We have this existing policy configured in a customers tenant (https://www.azadvertizer.net/azpolicyadvertizer/345fa903-145c-4fe1-8bcd-93ec2adccde8.html After creating a VM and allocating the correct tag etc. it didn't automatically have the backup policy assigned to it. With the policy assignment itself it didn't even appear as a non-compliant resource. I went through the checks to make sure it was the same region, correct tag, correct rsv and policy, which all appeared to look fine. When remediating it still wasn't pulling the resource through. When I went into the definition detail to see what could be amiss, I noticed the list of WindowServer image SKU's that were listed (image attached here https://i.stack.imgur.com/1YPpM.png. As I was sanity checking everything, I looked at the VM to see that the SKU wasn't actually in this list (2019-datacenter-smalldisk-g2). As every SKU is listed specifically it makes me think this image has just been missed off and needs adding? Rather than it getting captured by one of the SKU's listed. I can add the VM manually to the existing RSV for now but for future ref, is there a way I can raise this if my findings are indeed correct?
