Automation Service is committed to delivering 99.95% SLA uptime. Bizagi Automation Service uses Web Apps technology that encompasses the Azure App Services' global infrastructure. This true cloud technology lets Bizagi assure the reliability of your Automation Service. Reliability is one of the three main pillars offered by Automation Service, as described at Automation Service overview.
The infrastructure behind the service is designed for availability and resiliency, and this includes storage, networks, and communications. Bizagi conducts 24x7 monitoring on the services and underlying technology with regions around the world where data centers are located to provide higher performance and meet data location requirements.
Web apps technology - true cloud
Bizagi Automation Service infrastructure is built using Azure App Services. Compare to a single Virtual Machine, a Web App uses a full stack of active dedicated servers where the Web App can run from the Azure Service Fabric. These servers are pre-provisioned in a data center of the Azure region that you choose for your service where the Bizagi web apps are provisioned. See the Bizagi Automation Service Architecture and learn about the Bizagi web apps.
Therefore, if one server suffers a failure, the web app is redirected to another pre-provisioned and warm server. So users do not see any downtime in the service. Web Apps only contains the logic and functions layer underlying a web application, for example, to run the Work Portal. Data and other confidential information are not stored in any web app but in the database.
All the servers of one web app are located within the same Azure region. If you want to have full redundancy of all architecture's web apps, you can acquire the Disaster Recover full replica service.
Database and storage reliability
One of the most important components in Bizagi Automation Services is the storage layer and the database. Reliability is designed for all underlying services of Automation Service and especially enforced through a highly available storage layer, which is set up by making the most out of replication and data redundancy mechanisms. Bizagi configures the storage layer based on two reliability principles: redundancy and backups.
A database is comprised of two main files: data and logs. Both files have a local redundancy in a storage account located in the same Azure region, where three replicas of the files are stored. When the database needs to execute a transaction, it runs the transaction using the transient data in a server. The Azure service fabrics, similar to web the apps, run several pre-provisioned fail-over servers, so in case one server fails, still have a set of servers ready to execute transactions of the database. Additionally, Bizagi executes backups to have a full reliability strategy.
As an additional safety measure, Bizagi performs different type of backups of the production environment database.
•Transaction log backups every 10 minutes
•Differential backups every 24 hours
•Full backup every week.
These backups are stored under the same Azure region. In case of any failure of the main database, Bizagi can restore the database using any of the previous backups.
Retention policy and point in time restore
Bizagi keeps a backup for up to 35 days. This policy lets you restore the database of your test or production environment of the Automation service to any time within the 35 days window. For example, in case a deployment fails, you can raise a ticket and ask for the restoration. You need to define the date and time (UTC), and we will restore to the nearest restoring point that Azure offers based on the database backups made.
Backups vs Disaster Recovery
These backups are stored in the same region and are part of Azure's backup strategy to keep running databases. However, if you need to replicate your database having a read-access geo-redundancy in different regions you can purchase the Disaster Recovery - Database only service.
Bizagi uses cloud storage for tables and files that are replicated with Geo-redundancy (GRS) to protect against hardware failures and increase system reliability. The GRS first copies the data three times in a local region synchronously, and then asynchronously moves these physical copies to a second paired region.
The storage account is used for tables and files. It does not include the database.
If Bizagi does not achieve the SLA Commitment in any given month, the customer will be eligible to receive Service Credits towards a portion of the monthly service fees.