Backups are crucial for any mission-critical application as they protect against unforeseen disasters. Regular backups help minimize the Recovery Point Objective (RPO), allowing systems to recover quickly with minimal data loss. However, it’s equally important to store backups safely. If backups are kept in the same location as the primary site and something goes wrong, you may have no way to recover, leading to complete data loss.
To reduce these risks, many organizations choose fully managed servers to host their databases. One popular option is Azure Flexible Server for PostgreSQL, which offers a reliable, scalable, and managed solution.
Azure provides 3 levels of redundancy in three different ways, and not only that, you can recover backups using these same three methods. These are
- Locally Redundant Storage
- Zone Redundant Storage
- Geo Redundant
Each level of redundancy offers unique advantages when it comes to restoring backups. In today’s blog, we will explore all three types of backups and recovery methods. We will dive into the differences between each type and learn how to restore your backup if your primary site goes down.
Let’s dive in and explore each backup and restore method in detail!
Locally Redundant Storage
Locally Redundant Storage (LRS) replicates your data three times within a single data center in the primary region. This means that if you create your primary instance in a region with only one availability zone, LRS will store and replicate your data across three different racks on 3 different physical servers within that same availability zone or data center.
LRS offers an impressive durability rate of 99.999999999% (11 nines) for objects over the course of a year.
Source: Microsoft
Pros of Locally Redundant Backups
-
Low Latency Data Access: Since LRS keeps all replicas within the same data center, read and write operations experience minimal latency compared to geographically distributed storage.
- Synchronous Data Replication: Every write operation is synchronously replicated across three different storage nodes within the same data center, ensuring data consistency and durability.
- Fast Recovery from Hardware Failures: Since multiple copies exist within the same data center, LRS provides quick recovery in case of disk or server rack failures without needing cross-zone data transfer.
- Simplified Backup and Restore Process: With all replicas stored in a single location, backup and restore operations are faster and do not require complex replication management across multiple zones or regions.
Cons of Locally Redundant Backups
- Limited Protection Against Regional Failures: Since LRS only replicates data within the same data center, it does not protect you from large-scale regional failures, such as natural disasters or region-wide outages. If the entire data center goes down, your backups will be at risk.
Note: When writing data to a storage account using LRS, the operation occurs synchronously, meaning the write request is only successful once the data is written to all three replicas.
When to Choose Locally Redundant Backups
Locally Redundant Backups (LRS) are ideal in situations where
- Limited-scale or small projects: If you are managing smaller projects or non-critical applications that are geographically limited to a single region, LRS can meet your backup needs without adding unnecessary complexity or cost.
- You only need protection against hardware failures: If you are primarily concerned with protecting against disk or server failures within the same region, LRS provides enough protection with minimal overhead.
- Your data and services are not highly critical: If your data is important but not mission-critical and you can afford brief periods of downtime in case of regional outages, LRS can be a suitable choice.
Zone Redundant Storage
Zone Redundant Storage (ZRS) replicates your data across multiple availability zones within a region. An availability zone is essentially a separate data center, designed to be isolated from failures in other zones. Each availability zone is a physically separate location with its own power, cooling, and networking systems.
For example, Canada Central is a region with three availability zones. If your primary instance is in Availability Zone 1 (AZ 1), your backups will also be stored in AZ 1. Since ZRS is zone-redundant, it ensures that your backups are also available in AZ 2 and AZ 3, providing a higher level of resilience than Locally Redundant Storage (LRS), which only replicates data within a single data center.
ZRS offers durability for your data with a guaranteed rate of 99.9999999999% (12 nines) over the course of a year.
Source: Microsoft
Pros of Zone Redundant Storage
- Protection Against Zone-Level Failures: Unlike LRS, ZRS protects your data from failures at the availability zone level. If one zone experiences an outage due to power failure, network issues, or other problems, your data remains accessible from the other zones in the same region.
- High Availability: By replicating your data across multiple availability zones, ZRS provides you 99.9999999999% (12 nines) of high availability over the course of a year.
- Improved Performance: Since data is replicated across multiple zones, ZRS can also help with load balancing and reducing latency for applications that need access to data from different locations within the region.
Cons of Zone Redundant Storage
- Region-Specific: Like LRS, ZRS only provides redundancy within a single region. While it offers better protection than LRS, it doesn’t guard against regional outages, such as natural disasters or widespread infrastructure failures. For that level of protection, Geo-Redundant Storage (GRS) may be required.
When to Choose Zone Redundant Storage
Zone Redundant Storage (ZRS) is ideal in situations where
- High Availability is Critical: If you need a higher level of availability and protection against zone-level failures, ZRS is a great choice. It’s especially beneficial for critical applications that cannot afford downtime even in the event of an availability zone failure.
- You Need Resilience Against Infrastructure Failures: If your data or applications must remain accessible during hardware failures, power outages, or network issues affecting a single zone, ZRS ensures continued operation by replicating data across multiple zones.
- Scaling Within a Single Region: If your application operates within a single region but you want to improve its fault tolerance and latency, ZRS offers a balanced solution.
Geo-redundant storage
Geo-redundant storage (GRS) copies the data synchronously three times within a single physical location or datacenter in the primary region using LRS. It then copies the data asynchronously to a single physical location in a secondary region that is hundreds of miles away from the primary region.
GRS offers durability for storage resources of at least 99.99999999999999% (16 9s) over a given year.
A write operation is first committed to the primary location and replicated using LRS. The update is then replicated asynchronously to the secondary region. When data is written to the secondary location, it also replicates within that location using LRS.
Source: Microsoft
Pros of Geo-Redundant Storage (GRS) for Backups
- Cross-Region Disaster Recovery: GRS replicates data to a secondary region, ensuring recovery even if the primary region experiences a total failure.
- Read Access for Verification: With Read-Access Geo-Redundant Storage (RA-GRS), you can verify backups in the secondary region without impacting the primary workload.
- Asynchronous Replication: Data is first written to the primary region and then asynchronously replicated to the secondary region, reducing write latency.
- Compliance and Regulatory Requirements: Helps meet regulatory requirements for data redundancy across geographically separate locations.
- Automatic Failover Readiness: In case of regional outages, backups in the secondary region can be used to restore services with minimal manual intervention.
Cons of Geo-Redundant Storage (GRS) for Backups
- Higher Recovery Time Objective (RTO): Since replication is asynchronous, recent writes may not be immediately available in the secondary region.
- Data Consistency Risks: Potential for data inconsistency if a failure occurs before the latest writes are replicated to the secondary region.
When to Use GRS for Backups
- Applications with Critical Disaster Recovery (DR) Requirements: When business continuity depends on data being recoverable from a geographically distant region.
- Regulatory Compliance Needs: When data redundancy across different geographic locations is mandated for compliance.
- Multi-Region Business Operations: If applications serve users across multiple regions, GRS ensures data availability even during regional failures.
- Primary Region is Prone to Natural Disasters: If the primary region has a high risk of earthquakes, hurricanes, or other disasters, GRS ensures data survivability.
Restoring a PostgreSQL Flexible Server
When dealing with disasters, failures can occur at different levels. Understanding these failure scenarios helps determine the best recovery approach
Primary Server Failure
- If only the primary server fails while the data center remains operational, you can restore the server within the same data center for minimal downtime.
Data Center Outage
- If the entire data center goes down, you need to restore your backups in a different availability zone within the same region to maintain high availability.
Regional Outage
- If the entire region becomes unavailable, restoring to a geo-redundant backup in a paired region is necessary to resume operations.
Once we determine the cause of the failure and decide on the restoration location, the next steps become straightforward.
Restore Process
Navigate to the Azure Database for PostgreSQL – Flexible Servers dashboard in the Azure Portal.
Select the server instance you want to restore or that is down for any reason.
Initiate Restore
From the left menu bar select the Backup and Restore option
On the Backup and Restore screen, locate the backup you want to restore. Then, select the “Fast Restore” option located directly in front of the backup name and its associated properties.
Setting Up a New Restore Server
You will be redirected to the Create Azure Database for PostgreSQL Flexible Server – Restore Server screen.
On this screen
- Choose your subscription and resource group.
- Provide a new name for the restored server.
Restore options
To perform a restore, you have three available options
Local Restore – Restore within the Same Data Center
If the primary server was created in a region that does not have multiple availability zones, and the geo-redundancy option was not selected while creating the primary server the restore process will be limited to the same data center.
As shown in the image below, no availability zone options are available, meaning a local restore is the only option.
Zone-Level Restore – Restore to a different availability zone within the same region
If the primary server is in a region with multiple availability zones, and it was created with zone redundancy option we can restore the backup to a different availability zone.
For example, the Canada Central region currently has three availability zones. If our primary server is in AZ 1, we have the option to restore the backup in AZ 2 or AZ 3. Alternatively, selecting AZ 1 would result in a local restore within the same availability zone.
in the diagram below you can see I have selected AZ 2 to restore.
Region-Based Restore – Restore to a designated paired region
If geo-redundancy was enabled for backups when creating the primary server, you can restore the backup to the paired regions as well as different availability zones as well.
To perform a cross-region restore, first, select the option “Restore to paired region (Canada East).” Since Canada East is the paired region for Canada Central, it is automatically displayed as the restore destination. This means your backup will be restored in the Canada East region.
If Canada East had multiple availability zones, you would be able to choose a specific zone for the restoration. However, since there are no availability zones currently available in Canada East, no options are displayed under the Availability Zone section. In this case, you can simply leave it as “No preference”.
Review and Create
Click on Review + Create to verify your configuration.
Once satisfied, click Create to deploy the restored server.
Reconnect Applications
Update your application’s database connection strings to point to the newly restored server.
FAQs
Will the PostgreSQL parameters be restored and applied to the newly recovered server?
It depends on how the backup was taken and how the restore was performed. If PostgreSQL config parameters were updated but no full backup was taken, it won’t be possible to recover the parameter changes during the restore.
As a general practice, whenever changes are made to the PostgreSQL config parameters, it’s recommended to take a On-Demand backup immediately. In case of a disaster on the primary server, recovery should be done using the On-Demand backup taken after updating the PostgreSQL config parameters.
Additionally, if automated full backup is available after the PostgreSQL config parameter updates, you can use it as it will contain the updated PostgreSQL config parameters.
How long will it take to copy the initial full backup, transaction logs, and daily backups to the paired region?
When the server is configured with geo-redundant backup, the backup data and transaction logs are copied to the paired region asynchronously through storage replication. After you create a server, wait at least one hour before initiating a geo-restore. That allows the first set of backup data to be replicated to the paired region.
Later, the transaction logs and the daily backups are asynchronously copied to the paired region. There might be up to one hour of delay in data transmission.
If any rules and firewalls are configured in the primary server, will they also be restored?
No rules or firewalls that we have in the primary server won’t be restored to other server we will have to configure them manually again
