Overview
If you want to increase the resilience of the Automation Service and ensure service continuity in the event of an outage or disaster, Bizagi offers a Disaster Recovery service. This service is designed to minimize downtime and protect critical resources during unexpected incidents.
The Disaster Recovery service provides two recovery options:
•Architecture Full Replica, which is the replication of the complete set of resources
•Data base only which is data replication
This service is available at an additional cost, separate from the standard Automation Service fees.
The Infrastructure is provisioned in an isolated primary site, whose geographic location is selected based on your specific requirements, such as compliance with local regulations or performance considerations.
When the Disaster Recovery service is enabled, Bizagi provisions a secondary site, referred to as the recovery site, which is activated if the primary site becomes unavailable due to a disaster. The recovery site is deployed in a paired region located at least 300 miles away from the primary site, ensuring geographic redundancy and increased resilience.
|
This service is available for the Production environment only. |
Option 1: Full Replica Disaster Recovery
Both the primary and recovery sites are fully provisioned and maintained in a ready state. Each site includes the Infrastructure Base and Automation Service and synchronized databases. The recovery site is configured to replicate the primary site’s network topology, security controls, storage, and all other critical infrastructure components to ensure operational consistency.
During normal operations, the primary site functions as the active site and handles all end-user interactions and service requests. The recovery site operates in a passive standby mode and is activated only upon an officially declared disaster or major service disruption affecting the primary site. Once activated, all new user traffic is rerouted to the recovery site according to the established failover procedures.
This active/passive disaster recovery architecture is designed to achieve a reduced Recovery Time Objective (RTO).
Because applications, services, and infrastructure are pre-deployed and continuously synchronized, failover can be executed rapidly, minimizing service downtime and supporting business continuity objectives.
|
If you have a configured VPN, you need to configure a second VPN (additional). This is done in the onboarding. |
Recovery Point Objective (RPO)
•Database RPO, defines the maximum acceptable amount of data loss, measured in time, in the event of a disaster.
The Database RPO is up to a maximus 5 minutes, ensuring minimal data loss through continuous synchronization.
•File Storage RPO, defines the point in time to which file data can be restored following a disaster.
The File Storage RPO is less than 15 minutes. This RPO differs from the Database RPO because file data is stored and replicated using a dedicated Storage Account, which follows a separate replication mechanism from the database.
|
It is important to understand the difference between the database and file storage. The database contains all the information in relational tables. On the other hand, files are stored in a Storage Account to increase performance. See the Automation Service Architecture. |
Complete Environment Recovery Time Objective (RTO)
Full Replica RTO defines the maximum acceptable time required to restore the full Service following a service outage or disaster. In this configuration.
The RTO is up to 3 hours, ensuring timely recovery of all critical services and functionalities.
Option 2: Database-only Disaster Recovery
The environment is fully deployed and active in the primary region.
In the secondary region, only the required storage services, security layer, and networking resources are pre-provisioned to enable integration in the event of a disaster. Both sites maintain continuous synchronization of database and storage content.
In the event of a declared disaster, the base infrastructure and the Automation Service application are deployed in the secondary site, connected to the synchronized standby data and finally activated. Once activated, all incoming requests are redirected to the recovery site using the replicated data.
Because data is continuously replicated, there is no need to wait for backup restoration processes or file recovery operations, which typically increase restoration times. This eliminates additional recovery delays and helps ensure faster service restoration in alignment with the defined RTO objectives.
Recovery Point Objective (RPO)
•Database RPO, defines the maximum acceptable amount of data loss, measured in time, in the event of a disaster.
DAtabase RPO is up to a maximus 5 minutes, ensuring minimal data loss through continuous synchronization.
•File Storage RPO, defines the point in time to which file data can be restored following a disaster.
The File Storage RPO is less than 15 minutes. This RPO differs from the Database RPO because file data is stored and replicated using a dedicated Storage Account, which follows a separate replication mechanism from the database.
|
It is important to understand the difference between the database and file storage. The database contains all the information in relational tables. On the other hand, files are stored in a Storage Account to increase performance. See the Automation Service Architecture. |
Complete Environment Recovery Time Objective (RTO)
The Complete Environment RTO defines the maximum acceptable time required to restore the full Automation Service environment following a service outage or disaster. In this configuration, the RTO is up to 18 hours, ensuring timely recovery of all critical services and functionalities.
Testing and training
In alignment with information security best practices, Bizagi conducts continuous development, validation, and testing activities to ensure the Automation Service remains compatible and secure as new releases are introduced. Each release undergoes controlled testing to validate support for new platform changes, functionalities, and integrated products.
Additionally, each disaster recovery models are formally tested at least once per year in internal production-like environments. These tests are documented and evaluated to verify the effectiveness of recovery procedures, operational readiness, and adherence to defined recovery objectives. This regular testing cycle supports continuous improvement, ensures that disaster recovery procedures are properly maintained and fine-tuned, and provides evidence of compliance with established business continuity and information security controls.
Disaster Response Scenarios
Scenario 1: Customers with Disaster Recovery (DR) Purchased
For customers who have purchased Bizagi's Disaster Recovery (DR) service, we provide an enhanced level of protection and rapid recovery in the event of a disaster.
1.Immediate Response:
oIncident Detection: Upon detecting a service disruption, our monitoring systems alert our DR operations team immediately.
oAssessment: The team quickly assesses the situation to confirm the disaster and determine the impact on services.
2.Customer Notification:
oDeclaration of Disaster: We declare a disaster within 30 minutes to 1 hour after confirmation.
oCommunication: Customers are notified via email within the following 4 hours, with updates and expected timeframes for resolution.
3.Activation of DR Plan:
oFailover to Secondary Region: Services are switched to a secondary recovery region, ensuring minimal downtime.
oService Continuity: We aim to meet the specific Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) as outlined in the DR agreement, ensuring minimal data loss and quick restoration of services.
4.Ongoing Updates:
oStatus Reports: Regular updates are provided to customers via email regarding the recovery progress and expected restoration times.
5.Post-Restoration:
oConfirmation: Customers are notified as soon as services are fully restored.
Scenario 2: Customers Without Disaster Recovery (Relying on High Availability)
For customers who have not opted for our Disaster Recovery (DR) service, we offer a standard Service Level Agreement (SLA) with High Availability (HA) of 99.95%. You can extend the percentage of the SLA. If you consume more than 500 monthly BPUs you will have a 99.99% SLA. If you consume less, you can aquire an enhanced availability service to encrease your SLA to 99.99% by paying an additional cost, in the Production environment. This ensures business continuity within a single Azure region. In the unlikely event of a disaster, our procedures are designed to restore services as swiftly as possible once Azure has resolved the issue.
1.Initial Response:
oIncident Detection: Our monitoring systems alert our operations team to any service disruption.
oAssessment: The team assesses the situation to confirm if it is a disaster affecting the Azure region or datacenter.
2.Customer Notification:
oDeclaration of Disaster: We declare a disaster within 30 minutes to 1 hour after confirmation.
oCommunication: Customers are notified via email within the following 6 hours, with updates and expected timeframes for resolution.
3.Coordination with Azure:
oMonitoring: We work closely with Azure to monitor their restoration efforts.
oService Restoration: Once Azure restores services in the affected region, our team makes every effort to restore our services as quickly as possible.
oAs there is no defined Recovery Time Objective (RTO) or Recovery Point Objective (RPO) for customers without DR, the restoration time will depend on Azure's resolution time and subsequent Bizagi recovery efforts.
oData restoration: Bizagi manages backups to minimize interruptions to normal operations, reduce the overall impact of unexpected service interruptions, and minimize data loss in case of a disaster. Backups are geo-replicated. In case of any failure, Bizagi can restore the database to the nearest restoring point based on the database backups made.
4.Post-Restoration:
oConfirmation of Service Restoration: Customers will be notified as soon as services are fully restored.
Summary
With DR Purchased:
•Enhanced protection with a secondary recovery region.
•Minimal downtime with specific RTO and RPO.
•Prompt failover and continuous updates.
Without DR (High Availability):
•Dependent on Azure's restoration.
•No specific RTO or RPO.
•Efforts to restore services as quickly as possible post-Azure recovery.
Last Updated 1/16/2026 12:01:15 PM