I want to set up DR for my prod services. how can i set up.

Hello @Aravind S K (External - Capgemini India Pvt. Ltd)

Thank you for reaching out to Microsoft Q&A.

I understand that you’re trying to design DR for a fairly complex Azure estate: multiple App Services behind private networking (private DNS/private endpoints), a PostgreSQL Flexible Server backend, Key Vault (secrets), Storage Accounts (logs), and an ADF pipeline to on-prem Oracle.

Below is a practical way to “where to start” using the provided Azure guidance.

1. Start with the DR approach you’ll use per workload

Based on the docs you shared, Azure Site Recovery (ASR) is primarily the orchestration/replication tool for workloads like SQL Server / Active Directory / multi-tier apps (VM-based). For example, the ASR guidance focuses on replicating infrastructure (VMs, and key application tiers) and then running recovery plans to orchestrate failover.

For your setup, a common pattern is:

• If your “databases and tiers” can be represented as recoverable workloads (e.g., SQL on VMs, AD, multi-tier IIS/IIS-like tiers), then ASR can be used to replicate those tiers and orchestrate failover with a Recovery Services vault.
• If the workload is not a VM-tier replication scenario, you typically use the appropriate backup/disaster recovery service for that specific resource (the documentation you provided includes backup guidance for PostgreSQL Flexible Server and storage types).

The docs specifically call out:

• SQL Server DR with ASR (often combined with SQL BCDR tech like Always On / failover clustering)
• Active Directory/DNS DR with ASR
• Backup/config for PostgreSQL Flexible Server
• Backup/config for Storage/Blob and File Shares

2. Create the ASR foundation (if you use ASR for any tiers)

If you decide to use Azure Site Recovery for any VM-based tiers (or for key infrastructure like AD/DNS where applicable), the ASR application replication guidance says to:

1. Confirm ASR is enabled for your subscription.
2. Create a Recovery Services vault.
3. Ensure ASR network/infrastructure prerequisites are met (ASR has networking prerequisites).

ASR “replicate + orchestrate” workflow (high level):

• Replicate the VM workload(s) to Azure (or secondary).
• Configure supporting infra (e.g., AD/DNS if required by your app/DB).
• Set up recovery plan(s) and validate using test failover before real failover.

3. Pay special attention to SQL/AD orchestration concepts (even if your backend isn’t SQL)

Even though your backend is PostgreSQL Flexible Server (not SQL Server), the provided ASR guidance is very clear about how application failover should be orchestrated:

• Database tier should be recovered/primary before web/app tiers
• Set up Active Directory replication for SQL/SAP-style multi-tier applications (because many app architectures depend on AD/DNS)
• Ensure connectivity between tiers is ready for test failover

This is still useful as a design rule for any multi-tier app:

restore/activate the “stateful backend” first, then bring up dependent services.

In your case, that means ensure your PostgreSQL failover/restore strategy is validated first, then ensure App Services (and anything consuming secrets/data) can reach it.

4. For PostgreSQL Flexible Server + data protection: consider Azure Backup for that workload

Your provided documentation explicitly includes PostgreSQL Flexible Server backup as a supported/covered backup solution in the “configure backup solutions for multiple Azure resources” guidance.

So, for PostgreSQL Flexible Server DR, you’d typically start by:

• Confirming your DR targets (RPO/RTO) for PostgreSQL
• Using the PostgreSQL Flexible Server backup documentation approach to configure backups appropriate for DR
• Validating restore into the recovery environment

(ASR itself is not described in your provided docs as the mechanism for PostgreSQL Flexible Server; the docs you included point to backup for PostgreSQL.)

5. Include Key Vault + Storage in your DR scope

From your description:

• Key Vault stores secrets (you’ll want your DR plan to include how secrets are accessed in recovery—typically recovery-side access and connectivity)
• Storage Accounts store logs (often DR for logs is covered by backup/restore patterns depending on your retention/recovery needs)

Your provided “configure backup solutions for multiple Azure resources” guidance includes backup configuration references for:

• File Share backup
• Blob backup
• (and PostgreSQL)

So, for logs:

• decide whether you need cross-region durability for logs during DR,
• then use the appropriate backup strategy for the storage type you use.

6. Validate with test failover / restore drills

The ASR application replication doc emphasizes:

• do test failover before production failover
• create recovery plans to automate failover actions
• verify in the Recovery Services vault and confirm tiers behave correctly

For PostgreSQL backup-based DR, likewise:

• run restore tests to confirm application connectivity and secret usage work end-to-end.

Reference:

• Replicate Azure VMs / ASR enable replication: https://docs.microsoft.com/azure/site-recovery/azure-to-azure-how-to-enable-replication-s2d-vms
• Set up disaster recovery for SQL Server (ASR + SQL BCDR concepts): https://learn.microsoft.com/azure/site-recovery/site-recovery-sql
• Disaster recovery of Active Directory and DNS (ASR): https://docs.microsoft.com/azure/site-recovery/site-recovery-active-directory
• https://docs.microsoft.com/azure/site-recovery/site-recovery-iis
• https://docs.microsoft.com/azure/site-recovery/site-recovery-sap
• PostgreSQL Flexible Server backup (linked from the backup guide): https://learn.microsoft.com/azure/backup/backup-azure-database-postgresql
• Azure Backup for Blob: https://learn.microsoft.com/azure/backup/blob-backup-configure-manage?tabs=operational-backup
• Azure File Share Backup: https://learn.microsoft.com/azure/backup/backup-azure-files?tabs=backup-center

If the answer is helpful, please click" Accept Answer" it. If you have extra questions about this answer, please click "Comment".