For Bizagi Engine, as usually for any other system, backups will provide you the possibility to:
•Rollback unapproved changes to restore your system to a previous state, with as little downtime as possible.
•Rely on a snapshot that serves as a restore point for contingency measures (in case of an unplanned event which affects your operation).
Due to these reasons, creating backups of Bizagi is an important task for system maintenance and administration. For more information about other related tasks, refer to Maintenance and administration.
Backing up an operational Bizagi Engine is done by backing up both its information at the database, attachments, and its components' files, each following different aspects.
1. Taking database backups frequently
For Bizagi Engine, database backups are the main tool of any contingency and therefore these should be generated in a frequent manner.
It will be up to you and your policies to determine the frequency in which such backups are taken, bearing in mind that the higher the frequency, the lower the possibility of losing data when facing an unexpected event or disaster.
For this, consider:
•It is strongly recommended to take database backups minimum on a daily basis.
However and according to your analysis, sizing of the project or corporate policies, you may choose to take backups more frequently.
Note that such backups may be created automatically by scheduling the use of agents and tools as provided by the database engine products themselves.
•It is strongly recommended to take additional backups prior to any procedure which implies major changes in the database.
For instance, if you are planning a deployment of processes and new versions, or if you are planning a Bizagi version upgrade or certain changes in your implementation that require verification, then it is a best practice to rely on a database backup to have a restore point to rollback such changes (in case the results derived from such changes are not as expected).
For more information regarding how to create backups manually, refer to Database backups.
2. Taking backups of other components, considering the frequency when these change
In addition to the database, within the Bizagi System you should take backups to consider other components as well:
•Files of the Work portal (Web application) and the Scheduler service.
It is strongly recommended to take an initial backup of the files used by these components as soon as the configuration is properly set.
And afterward, just before making any changes to it.
Backing up these files can be done just before doing a procedure that changes them, such as a Bizagi version upgrade or a fix applied (Bizagi does not generate code, meaning also that such files do not change or grow over time -within the daily execution of processes).
For more information about how to take backups of these files, refer to Work Portal and Scheduler backups.
•Case attachments (files and documents uploaded from the processes).
By default, case attachments are not stored directly in the database but separately in an ECM system or file server.
Ensure you take backups of the attachments of process instances, either if these are stored in an ECM or if these are stored at a file server.
oIf your project stores uploads at an external ECM, then it is important that you consider them within your ECM management and corporate policies.
oOn the other hand and if your project stores such uploads in a file server (as in by default), then you will need to take backups by only creating a copy of the main folder holding them (named Docs by default), for instance, moving that copy into an external drive or the cloud.
It is recommended to take backups of uploads in the same frequency in which database backups are taken.
Files and documents that are uploaded within the different cases, are stored by default at the local Bizagi server (in C:\BizAgi\Projects\[your_project]\Docs\).
However, it is recommended that you define a different location for this purpose, that it is not held at the Bizagi server (such as a shared file server or an ECM repository).
This path and location is configured and managed through the upload path parameter as shown above.
Though its value can be changed anytime, recall that you will need to move the complete folder structure to the new location when using a file server (upon a change of location).