Back-ups protect your data, but business continuity requires more. Which systems need to come back first? How much data may be lost? How long may recovery take? And has that recovery ever actually been tested?
Malenco manages back-up from the perspective of recoverability. Not only checking whether the back-up succeeded, but also assessing what is needed to get your organisation functioning again when systems, data or even a complete environment fail.
A back-up system can report every day that everything completed successfully. Yet during a calamity, questions can arise that the back-up status does not answer.
Not every system, cloud environment or Microsoft 365 component is automatically included.
Restoring a file is something different from making a complete server environment available again.
When hardware, storage or a complete environment fails, a usable recovery environment must also be available.
An organisation usually cannot recover everything at once. Business-critical processes determine the order.
Only during a recovery test does it become clear whether back-ups, capacity, procedures, dependencies and knowledge actually come together.
Back-up and recovery consists of several components that need to reinforce each other.
We make sure relevant systems and data are protected at an appropriate frequency and that deviations are actively followed up.
Email, OneDrive, SharePoint and other Microsoft 365 data require a deliberate choice: what must be independently recoverable and with which retention?
For business-critical systems, additional recovery facilities can significantly shorten recovery time.
Applications rarely work independently. Identity, databases, storage, network and integrations together determine the order needed during recovery.
It is not only the last successful job that counts. Missing systems, failed jobs, deviations and the availability of recovery facilities must also be monitored.
For critical systems we document how recovery takes place and periodically test whether the chosen approach is practically feasible.
The question is not: how often can we make a back-up? The question is: what does downtime mean for your organisation?
How much data may be lost?
The Recovery Point Objective determines how far back in time we are maximally willing to go during recovery.
How quickly must a service be back?
The Recovery Time Objective is about the desired time between failure and usable availability.
What impact does downtime have on your organisation?
A Domain Controller, ERP system, file server or production application can have a completely different impact than a less critical application.
Which systems need to recover together?
An application can be technically recovered and still remain unusable when a database, identity service, network connection or connected system is missing.
With a defective server you usually want to recover as recently as possible. With ransomware the opposite may be necessary: a recent recovery point may already be infected itself.
That is why we first assess what has happened and which recovery point is reliable.
From taking inventory to testing and improving: recoverability requires a consistent way of working.
We map out relevant systems, data, applications and dependencies.
We determine appropriate RPO and RTO objectives and translate these into the required facilities.
We set up appropriate back-up and recovery layers for the various systems and scenarios.
We check that back-ups and recovery facilities keep functioning and follow up on deviations.
We describe who does what, which order is required and which technical and functional checks are part of recovery.
Recovery tests reveal whether the chosen approach works in practice. If the environment changes, the recovery strategy changes with it.
A new server, SaaS solution, ERP system, location or migration changes not only your IT environment, but also your recovery requirements.
Must the new system be included in the back-up, and does the desired back-up frequency change?
Are existing recovery procedures still usable, and do new dependencies arise?
Must the recovery order be adjusted, and does the new system replace old functionality that temporarily still needs to remain part of the recovery scope?
In an environment with several business-critical servers, simply knowing that the back-up succeeded is not enough.
It must also be clear which systems come back first, which dependencies exist, which infrastructure is available during recovery and which alternative recovery options can be deployed.
That is why we work out recoverability in system classification, RPO and RTO, recovery order, procedures, calamity scenarios and recovery tests.
A back-up is only one part of recovery. Discover which choices, dependencies and facilities determine how quickly your organisation can carry on.
How much data loss and downtime can your organisation accept? RPO and RTO make these limits concrete and help determine which recovery facilities are needed.
Read the articleNot every system needs to be restored at the same time. A recovery plan connects business priorities with technical dependencies and clear responsibilities.
Read the articleA successful back-up does not yet prove that your organisation can resume its work. Recovery tests show whether systems, data and the connections between them are usable again in practice.
Read the articleMicrosoft 365 offers several options for retaining and restoring data. But what happens in the event of accidental deletion, data loss or a security incident? Independent recovery options therefore deserve attention.
Read the articleWhen a few hours of downtime already have serious consequences, traditional recovery may not be fast enough. Additional facilities can shorten recovery time, provided the underlying dependencies are also taken into account.
Read the articleAfter a ransomware attack, the most recent back-up is not necessarily the safest choice. Recovery requires insight into the infection, verification of recovery points and a responsible return to production.
Read the articleA back-up provides certainty about a copy of your data. A recovery strategy provides insight into what is needed to get your organisation functioning again.
