Business Continuity Planning and Disaster Recovery Planning : reliability for your business emails

Focus on BlueMind's work to ensure that users do not experience any disruption to their email service, even during updates or technical changes.
Résilience BlueMind

In a world where technology is constantly evolving, one thing is certain: email is the backbone of business communication. It is the most widely used means of communication for companies, authorities, organisations and associations. Ideally, your email service should constantly evolve. However, it should never stop, not even during updates. These should be transparent for your user, regardless of which changes need to be made.
Our goal at BlueMind is that users will never experience any disruption to their email, even during updates or technical changes behind the scenes. Read about how we achieve „zero downtime“ (zero planned service interruptions).

BCP and DRP – allies of business continuity


Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP) are two fundamental concepts that you should implement in your organisation to ensure resilience.

Business Continuity Planning


The Business Continuity Plan (BCP) lists all measures that must be taken in the information system (IS) in the event of a disruption. The aim of the BCP is to keep business operations running. This also applies if operations have to be relocated or alternative tools and processes have to be used. In other words, the BCP is about avoiding obstacles in order to minimise the impact on business operations.

The BCP for your e-mail solution must answer the following questions (incomplete list):

  • What risks and threats could disrupt your business emails? These can include hardware failures, security attacks, natural disasters and the like.
  • What availability levels for emails are you aiming for? Classify your email systems and services according to their importance. For example, incoming and outgoing emails could be categorised as critical, while certain functions such as filehosting for heavy attachments are probably less important.
  • What does your detailed action plan look like? It must include the following steps, among others: recognising the incident, notifying those involved, implementing emergency measures, communicating with users, raising awareness and training your teams.
  • What about an emergency architecture for your business emails? This may require, for example, the installation of backup servers, redundant data centres or offsite backups.

Disaster recovery planning

The BCP includes measures to minimise the consequences of a disruption in real time and to ensure business continuity during the incident. The Disaster Recovery Plan (DRP), on the other hand, is future-orientated and clarifies the resumption of operations after the incident. The DRP aims to restore systems and services after a certain period of time, such as a few hours or days, after the incident has occurred.
Regarding business emails, the procedures might include restoring data from backup copies if data is lost or damaged and prioritising the recovery of mailboxes according to their importance. The aim of these procedures is to enable the organisation to resume normal operations as quickly as possible.
Ultimately, DRP and BCP are two sides of the same coin that complement each other with the aim of ensuring the organisation’s resilience. Together, they ensure that emails are always available – under all circumstances.

Updates with BlueMind

Ideally, the email system should never be interrupted, or only for as short a time as possible, even during updates. These should be transparent to the user, regardless of what changes are made.
BlueMind has greatly improved its standard update system (In Place). A new system for non-disruptive updates is now being added, starting with version 5 (available in early 2024) and for large locations and volumes.

The standard update of BlueMind-In-Place using the SetupWizard

  • Terminating the service,
  • Installation of the new version (the download can be done in advance),
  • Data transformation using “upgraders” (programmes that initiate the necessary changes and updates to the data),
  • Restarting the service.

The installation of the new version is quick and easy

Over the last three years, a lot of work has been put into improving data transformation. The aim is for the upgraders to be able to run in the background after the service has been restarted. The new version should be able to handle data in both the old and the new format and convert the data step by step. This applies to all new upgrades and updates, for example the removal of the Cyrus IMAP server for v5.
The v5 can manage emails regardless of whether they are in the Cyrus store or the new object store. When an email is requested, BlueMind v5 searches for it in the new, optimised path. If they are not there, it retrieves them from the Cyrus store. A hot upgrade process in the background ensures that the emails are migrated from the Cyrus store to the new store.

Updates without interruption

But how can “zero downtime” be achieved for email transmission? BlueMind answers this question with a new update system that complements the existing one.
This system, which is intended for very large installations, requires a second infrastructure. However, it offers much more:

  • Real-time backup, i.e. backing up data, including emails and documents, in real time so that they are not lost in the event of an incident,
  • DRP and BCP without interrupting the service,
  • Updates without interrupting operations.

The secret lies in the realisation of three concepts :

  • a proxy system that enables the smooth transition of data traffic from the production environment to the new platform, ensuring seamless continuity;
  • the object storage for non-modifiable data such as e-mails and documents, which is shared by the instances and ensures their constant availability;
  • a system for recording changes for all other data.
  • For other data types such as calendars, contacts, directories, read/unread information, BlueMind has set up a system for recording changes using “Kafka”.

General principle of recording changes

General principle of recording changes - BlueMind Kafka

The BlueMind standard architecture is based on Kafka. This means that every change is recorded in real time. In the event of an incident, it can be reproduced on an identical version of BlueMind, or alternatively on a higher version to prepare an update.

Conclusion

Large installations (tens of thousands of users) do not tolerate downtime. To fulfil this requirement, BlueMind has set up a solid infrastructure based on Kafka and object storage. Updates, Disaster Recovery Planning (DRP) and Business Continuity Planning (BCP) are now carried out without any interruption. It is even possible to clone production, for example to change the operating system or install a pre-production version. However, it should be noted that this type of infrastructure is only suitable for very large installations with tens of thousands of users. For more manageable installations, we have upgraded the standard system (In Place).

All in all, our goal at BlueMind is to enable robust working with email. Resilience is paramount to ensure that communication within organisations is never interrupted. This is true no matter what challenges lie ahead.

Picture of Leslie Saladin

Leslie Saladin

Share this article

Leave a Reply

Your email address will not be published. Required fields are marked *

− 1 = 1

Subscription to the newsletter

One e-mail per month to keep up to date with all BlueMind news