Disaster Recovery Plan
To increase the reliability of your Automation Service, Bizagi offers Disaster Recover services (DR). The DR service offers two options: to replicate the database or the full set of cloud-based resources (active-pasive multisite). This service has an extra cost, additional to the Automation Service's fees. To prevent outages after a disaster, Bizagi offers a Disaster Recovery service that can select be purchased to suit high availability scenarios.
|
This service is available for the Production environment only. |
Database-only
In the DR option, the environment is fully deployed in the primary region. Both sites are synchronized with the contents of the database. In case of a disaster, Automation Service is activated in a secondary site and connected to the standby database. All requests are routed to the new site using the replicated database. With this approach, there is no need to incur overhead and time that the database restore operation requires because the database is ready and running. The database only disaster recovery has the following characteristic.
Database Recovery Point Objective (RPO)
This is the point where the data from the database is recovered. In the Bizagi database-only Replica Disaster recovery the RPO is 5 minutes.
File Storage Recovery Point Objective (RPO)
This is the point where the data from the file storage from files attached to tasks or cases is recovered. In the Bizagi database-only Replica Disaster recovery the RPO is less than 15 minutes for files and it is different from the database RPO because files are stored in a Storage Account.
|
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. |
Full replica
Both the primary site and the Recovery Site have a full deployment. This deployment includes the Automation Services and a synchronized database. The primary site is actively handling requests from the interaction of end-users. The recovery site becomes active only when the primary site experiences a service disruption and a disaster has been declared. In that case, all new user requests are routed to the recovery site.
|
If you have a VPN, you need to purchase a second VPN (additional). This second VPN it is configured in the on boarding. |
This approach provides a lower RTO. Failover occurs faster because the application and services are already deployed. This service has the following characteristics:
Database Recovery Point Objective (RPO)
This is the point where the data from the database is recovered. In the Bizagi full Replica Disaster recovery the RPO is 5 minutes.
File Storage Recovery Point Objective (RPO)
This is the point where the data from the file storage is recovered. In the Bizagi full Replica Disaster recovery the RPO is less than 15 minutes for files and it is different from the database RPO because files are stored in a Storage Account.
|
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)
This is the timeframe that all your Bizagi Automation service is restored after an outage. The RTO is 6 hours.
In case of a major disruption, Bizagi will declare a Disaster and activate the Disaster Recovery plan. As a result, the Recovery Site will temporarily become active and receive the operation in a secure, isolated, and reliable way. The recovery site will be redirected to the replicated database. After the Disaster event has been resolved, Bizagi will make the decision to initiate the fallback plan to run the service in the original primary site. During failover, users may experience a slight impact on performance, but it is temporary since the Recovery Site will be running at the same Performance Level of the primary site.