It is true that IT infrastructures need regular backups, but they also need a recovering strategy in case of any incident. This is the part where the DRP intervenes.
DRP means “Disaster Recovery Plan”. It is, following its name, a plan which allows companies to rebuild the infrastructure and to relaunch the apps supporting the company’s activity during an IT center’s major or huge crisis.
It is an important element to take into account for a project. You have to think of it at every step of your infrastructure’s conception and set up.
As a company, you always have to think of the worse thing that could happen and being able to, in a bearable time, pick up your datas and services and deploy them again. Having this in mind, it is essential to be realistic and practical in order to find the balance between lose of data or bearable time AND the DRP’s cost !
At Cantor, we use an hybrid infrastructure, a mix of cloud and on premise servers. From the very beginning, we have used internal tools which are hosted locally and clients’ tools/environments hosted in the Cloud.
Docker at Cantor
We are using Docker for several years now.
We first started with our development environments and new services and now in the process of consolidating our existings infrastructures to Docker .
Today, more than half of our services run on Docker and the gain in terms of material ressources and IT operations is significant.
Before moving to Docker, we already had an operational DRP. But the consolidation of our infrastructures through Docker gave us the opportunity to reconsider it. We wanted to make it more powerful, by reducing the delay and required actions to restaure our services and datas on a spare infrastructure.
Our use of Docker, far from being a constraint, has been a strength in the reorganization of our DRP.
One killer feature of Docker is to allow the reuse of a software configuration through “images”, although it is very complex. With this feature ,the relaunching of services is a matter of seconds. Regarding the data, Docker uses “volumes”. From a technical point of view, those volumes keep backup servers in sync with the main servers.
We have automated this feature, which has led us to backup our data on a more regular basis. The synchronization, which is incremental, is fast. We have automated the entire DRP’s line : our data and services will be safe and accessible, should ever an infrastructure failure occur.
Therefore, in the case of an infrastructure’s failure, data is already present through “mirrored” volumes, and software configurations are ready through versioned Docker images.
We don’t need to retrieve them anymore, we can relaunch our services in a few minutes !
And you, would you “dockerised” your DRP ?