The Backup Mentality

1. Abstract

Each Board environment should foresee an appropriate backup policy for the existing Data Models, should it be a development, sandbox or production environment. Such backup policy must always be present and it should be developed on top of the standard backup policies implemented by the cloud team for disaster recovery purposes.

The backup policy should take into account the acceptable frequency, and retention period. The backups should be easily retrieved and restored in case they are needed.

2. Content

A standard backup in Board is a backup of a Board Data Model. The backup function creates a snapshot of the Data model by making a copy of its files in the backup directory. Board can run "Hot Backup" in a live environment while Board service is running without requiring any downtime.

A backup copy of a Data model includes everything that has been created in it (Entities, Relationships, Cubes, Procedures, Rules, Data readers, Database profiles, etc.): it's an exact and complete copy of the source Data model.

A proper backup policy is necessary to protect us from multiple adverse events like human error, data loss, hardware failures, and application corruption. In such a case it might be necessary to restore the Data Model to the earlier healthy state. To prevent the loss of days of work, it is recommended to implement a regularly scheduled backup process.

In general, a backup process should be foreseen in both production and development or test environment. However, the frequency might vary based on purposes.

2.1 Scheduled execution

In general, the best practice for backup processes is to have them included in the nightly routine. If data load processes are included during the nightly load, it is recommended to have one backup before the load and one backup after the load. This approach helps to preserve the data from the last day which might get lost if a loading process is not working properly. The latter backup is relevant for corrupting processes after the nightly load (for instance a user cleared the plan cube by accident).

In case of intense planning phases, one might schedule further backup processes, for instance around midday during lunch break. Even if Board backup process can run in concurrency with users working in parallel to the running task, the best practice is to find a low peak timeframe during the day: indeed, the backup runs even if other tasks are running, without waiting for the execution end, and this can cause backup data misalignment with the one stored in the database.

2.2 Manual execution

However, there are also cases when it makes sense to not only rely on scheduled backups but also to create them ad hoc. This might be necessary when experimenting in the database that might lead to an unknown output. But also when deploying structures and/or content from one system to another, it is highly recommended to perform a backup beforehand. For the deployment, the backup path should be noted somewhere (e.g. One Note) so that in case of an occurring issue, a restore can be easily performed.

The backup can be either created manually using the “backup data model” icon of the data model tile or in a procedure via the backup step where we can also provide a custom path and a specific expiration date. If there are no path and expiration days explicitly defined, the settings from the server configuration are applied.

2.3 Backup path

For cloud customers, the database backups are by default saved on the Z-drive. This allows the administrators to access the backup folders via e.g. Azure Storage Explorer. Per default, the path is defined as Z:\backup. Since all instances share one shared storage, all backups would regularly be located under Z:\backup. To avoid any confusion it is recommended to use computer variables (%computername%) and sub-folders to backup only into the dedicated path for the corresponding instance.

Note that the backup process on the shared storage takes more time than a regular backup onto the local drive. In case the backup takes too much time and might cause any runtime issues, you can ask the cloud support to provide a dedicated local drive. This new drive will be only available for the requested instance and performs backups as fast as on C. But be aware you will not be able to access this drive directly from the explorer tool.

If Board is hosted on-premise the backups are directly placed on the server within the defined Board standard path. Per default, this is C:\Board\Database\_backup on the corresponding machine. Depending on the server architecture the administrator can access the backup using a remote desktop connection manager.

2.4 Single objects backup

The standard backup described above has as scope the whole Data Model, especially during developments, while performing minor changes to existing objects, could be necessary to create copies of single objects, avoiding creating a backup of the full application.

In particular, for all the objects like procedures, screens, data readers and others, it is possible to “Save as” and keep them as a copy. If something goes wrong, it is enough to copy back the previous object and then remove the new one.

Please pay attention to the fact that the old procedure needs to be linked again to the object it was linked to before.

2.5 Capsules’ backup

For what concerns the capsules, the backup is feasible only manually, by downloading them from the Cloud Admin Portal. This allows you to choose the path where to save the downloaded zip folder, and, if necessary, upload them somewhere else.

When deploying the development capsules to the production environment, it is necessary to download them from the Cloud Admin Portal. At that moment, it is suggested to save a copy in order to not lose the old versions.