Wil je disaster recovery IT kiezen voor jouw organisatie?
Dan kom je al snel voor allerlei keuzes te staan.
Kies je voor:
back-up en restore;
replicatie;
cloud disaster recovery;
Disaster Recovery as a Service;
een tweede datacenter;
een cold site;
een warm site;
een hot site;
of een combinatie van verschillende oplossingen?
Daarnaast moet je bepalen welke IT-systemen als eerste moeten worden hersteld, hoeveel gegevens verloren mogen gaan en hoeveel downtime acceptabel is.
De beste disaster recovery-oplossing is daarom niet automatisch de technisch meest uitgebreide oplossing.
En ook niet automatisch de goedkoopste.
De juiste oplossing sluit aan op:
de bedrijfsprocessen;
de IT-omgeving;
de risico’s;
de gewenste hersteltijd;
de hoeveelheid acceptabel dataverlies;
het beschikbare budget;
en de kennis binnen de organisatie.
In deze uitgebreide gids lees je hoe je disaster recovery IT kunt kiezen, welke mogelijkheden er zijn en welke criteria belangrijk zijn bij het maken van een definitieve keuze.
Disaster recovery IT kiezen begint niet bij technologie
Het is verleidelijk om direct verschillende oplossingen te vergelijken.
Maar begin eerst met een andere vraag:
Wat moet onze organisatie na een ernstig IT-incident zo snel mogelijk weer kunnen doen?
Dat vormt de basis.
Technologie volgt daarna.
Begin bij de bedrijfsprocessen
Bekijk welke processen essentieel zijn voor de organisatie.
Denk bijvoorbeeld aan:
verkoop;
orderverwerking;
productie;
planning;
logistiek;
klantenservice;
facturatie;
betalingen;
communicatie;
of dienstverlening aan klanten.
Bepaal vervolgens welke IT-systemen daarvoor nodig zijn.
Niet iedere applicatie is even belangrijk
Een organisatie kan tientallen of honderden applicaties gebruiken.
Toch zijn meestal niet alle applicaties even kritisch.
Misschien kan een intern archiefsysteem twee dagen worden gemist.
Maar moet het ERP-systeem binnen enkele uren beschikbaar zijn.
Dat verschil moet terugkomen in de gekozen disaster recovery-oplossing.
Maak herstelcategorieën
Een praktische aanpak is systemen in categorieën verdelen.
Bijvoorbeeld:
Categorie 1: bedrijfskritiek
Deze systemen moeten zeer snel worden hersteld.
Categorie 2: belangrijk
Enkele uren uitval is acceptabel.
Categorie 3: ondersteunend
Een werkdag uitval kan eventueel worden opgevangen.
Categorie 4: niet-kritiek
Deze systemen kunnen later worden hersteld.
De exacte indeling bepaal je zelf.
Het belangrijkste is dat niet alles automatisch dezelfde prioriteit krijgt.
Kies op basis van bedrijfsimpact
Vraag per systeem wat er gebeurt wanneer het niet beschikbaar is.
Denk aan:
kunnen medewerkers nog werken?
Kunnen klanten bestellen?
Kan productie doorgaan?
Kunnen betalingen worden verwerkt?
Kan logistiek functioneren?
Ontstaat gegevensverlies?
Ontstaan contractuele problemen?
Hoe langer een systeem uitvalt, hoe groter de mogelijke impact.
Business Impact Analysis
Een Business Impact Analysis kan helpen deze gevolgen systematisch te onderzoeken.
Daarbij kijk je niet alleen naar techniek, maar vooral naar bedrijfsprocessen.
Het resultaat helpt bepalen hoeveel bescherming een systeem werkelijk nodig heeft.
Kies een passende RTO
Een van de belangrijkste selectiecriteria is de Recovery Time Objective.
RTO gaat over de gewenste maximale tijd waarbinnen een systeem na een ernstige verstoring weer beschikbaar moet zijn.
Hoe korter deze periode, hoe uitgebreider de benodigde oplossing doorgaans wordt.
Een lange RTO
Wanneer een systeem langere tijd gemist kan worden, kan traditionele backup & restore voldoende zijn.
Er hoeft dan niet permanent een volledig voorbereide tweede omgeving klaar te staan.
Een korte RTO
Moet een systeem snel terugkomen?
Dan kan een oplossing met:
replicatie;
stand-by capaciteit;
cloud recovery;
of DRaaS
geschikter zijn.
Zeer korte RTO
Wanneer vrijwel geen uitval acceptabel is, kom je mogelijk dichter bij:
high availability;
actieve redundantie;
automatische failover;
en geografisch gespreide infrastructuur.
Dat is technisch complexer en doorgaans kostbaarder.
Kies ook een passende RPO
Naast RTO moet je kijken naar de Recovery Point Objective.
RPO gaat over hoeveel recente gegevens maximaal verloren mogen gaan.
Stel dat iedere nacht een back-up wordt gemaakt.
Bij een incident aan het einde van de werkdag kan dan mogelijk een groot gedeelte van de wijzigingen sinds de vorige back-up verloren gaan.
Is dat acceptabel?
Zo niet, dan is frequentere gegevensbescherming nodig.
Lage RPO
Wanneer weinig dataverlies acceptabel is, kunnen technieken nodig zijn zoals:
frequentere back-ups;
snapshots;
replicatie;
of continue gegevensbescherming.
RTO en RPO samen beoordelen
Deze twee doelstellingen horen bij elkaar.
Je kunt bijvoorbeeld verlangen:
systeem binnen vier uur beschikbaar;
maximaal één uur dataverlies.
De gekozen disaster recovery-architectuur moet beide doelen ondersteunen.
Maak RTO en RPO niet onnodig streng
Bijna iedere organisatie zou het liefst zeggen:
geen downtime;
geen dataverlies.
Maar dat kan technisch en financieel grote gevolgen hebben.
Vraag daarom:
Wat is noodzakelijk voor de bedrijfsvoering?
Niet:
Wat zou theoretisch het mooiste zijn?
Disaster recovery oplossing kiezen
Wanneer de eisen duidelijk zijn, kun je verschillende technische strategieën vergelijken.
Er bestaat niet één beste oplossing voor iedere organisatie.
Vaak wordt zelfs een combinatie gebruikt.
Optie 1: backup & restore
De eenvoudigste strategie is herstel vanuit back-ups.
Na een incident worden:
infrastructuur;
systemen;
configuraties;
en data
hersteld.
Wanneer backup & restore kiezen?
Dit kan geschikt zijn wanneer:
langere hersteltijd acceptabel is;
de IT-omgeving relatief eenvoudig is;
het budget beperkt is;
en systemen niet continu beschikbaar hoeven te zijn.
Voordeel
Relatief eenvoudig en kostenefficiënt.
Nadeel
Herstel kan meer tijd kosten.
Optie 2: replicatie
Bij replicatie worden gegevens of systemen gekopieerd naar een tweede omgeving.
Daardoor kan sneller worden hersteld.
Wanneer replicatie kiezen?
Bijvoorbeeld wanneer:
een korte RTO belangrijk is;
grote hoeveelheden data moeten worden beschermd;
of snel een tweede omgeving beschikbaar moet zijn.
Let op
Replicatie vervangt niet automatisch een goede back-up.
Een fout of beschadiging kan mogelijk eveneens worden gerepliceerd.
Gebruik daarom meerdere beschermingslagen.
Optie 3: cloud disaster recovery
Bij cloud disaster recovery wordt cloudinfrastructuur gebruikt als onderdeel van de herstelstrategie.
Dit kan interessant zijn wanneer je niet permanent een volledig tweede fysiek datacenter wilt onderhouden.
Wanneer cloud recovery kiezen?
Bijvoorbeeld wanneer:
de infrastructuur al deels in de cloud staat;
schaalbaarheid belangrijk is;
je geen tweede fysieke locatie wilt;
of capaciteit pas tijdens recovery volledig nodig is.
Voordeel van cloud recovery
Je kunt infrastructuur vaak flexibeler beschikbaar maken.
Tijdens normale bedrijfsvoering hoeft mogelijk niet dezelfde hoeveelheid compute-capaciteit actief te zijn als tijdens een calamiteit.
Let op cloudafhankelijkheden
Kijk wel naar:
netwerk;
identity;
cloudaccounts;
regio’s;
opslag;
licenties;
en configuraties.
Cloud is geen automatische disaster recovery-strategie.
Optie 4: Disaster Recovery as a Service
Bij Disaster Recovery as a Service, oftewel DRaaS, wordt een gedeelte van de recovery-infrastructuur als dienst afgenomen.
Een externe leverancier kan bijvoorbeeld zorgen voor:
replicatie;
opslag;
recovery-infrastructuur;
monitoring;
testen;
en ondersteuning.
Wanneer DRaaS kiezen?
DRaaS kan interessant zijn wanneer:
weinig interne IT-capaciteit beschikbaar is;
je geen eigen tweede omgeving wilt bouwen;
sneller herstel gewenst is;
of gespecialiseerde ondersteuning belangrijk is.
Managed DRaaS
Bij managed DRaaS neemt de leverancier meer verantwoordelijkheid voor beheer en recovery.
Dat kan aantrekkelijk zijn voor organisaties zonder groot intern IT-team.
Self-service DRaaS
Bij een self-service oplossing beheert de organisatie een groter gedeelte zelf.
Dat kan meer flexibiliteit geven, maar vraagt ook interne kennis.
Optie 5: cold site
Een cold site is een alternatieve locatie die beperkt is voorbereid.
Bij een calamiteit moet nog relatief veel worden ingericht.
Wanneer cold site kiezen?
Wanneer:
langere hersteltijd acceptabel is;
fysieke uitwijk belangrijk is;
en kosten beperkt moeten blijven.
Optie 6: warm site
Een warm site is verder voorbereid.
Een gedeelte van infrastructuur en configuratie is al aanwezig.
Daardoor kan recovery sneller verlopen.
Wanneer warm site kiezen?
Een warm site kan een middenweg zijn tussen:
kosten;
beschikbaarheid;
en herstelsnelheid.
Optie 7: hot site
Een hot site is sterk voorbereid op snelle overname.
Systemen en data kunnen grotendeels gereedstaan.
Wanneer hot site kiezen?
Vooral wanneer:
downtime grote gevolgen heeft;
zeer snelle recovery nodig is;
en de extra investering zakelijk te rechtvaardigen is.
Optie 8: actieve tweede omgeving
Bij zeer kritieke systemen kan een organisatie meerdere actieve omgevingen gebruiken.
Verkeer of workloads kunnen dan over meerdere locaties worden verdeeld.
Dit ligt dichter tegen high availability aan.
Disaster recovery versus high availability
Deze begrippen worden regelmatig door elkaar gehaald.
High availability is vooral gericht op het beperken van uitval bij bepaalde technische problemen.
Disaster recovery richt zich op herstel na grotere verstoringen.
Een organisatie kan beide nodig hebben.
Kies niet één strategie voor alles
Dit is misschien wel de belangrijkste keuze.
Een organisatie hoeft niet te zeggen:
“Wij kiezen DRaaS voor alles.”
Je kunt bijvoorbeeld kiezen voor:
replicatie voor ERP;
cloud recovery voor virtuele servers;
backup & restore voor archiefsystemen;
SaaS-back-up voor clouddata;
en een aparte strategie voor Microsoft 365.
Zo ontstaat een gelaagde oplossing.
Tiered disaster recovery
Dit wordt vaak praktisch ingericht met verschillende beschermingsniveaus.
Bijvoorbeeld:
Tier 1
Meest kritieke systemen.
Snelle recovery en lage RPO.
Tier 2
Belangrijke systemen.
Iets langere hersteltijd.
Tier 3
Ondersteunende systemen.
Traditionele backup & restore.
Hiermee kun je kosten en risico beter in balans brengen.
On-premises of cloud kiezen?
Een belangrijke beslissing is waar de recovery-omgeving komt.
Mogelijkheden zijn:
eigen tweede locatie;
extern datacenter;
cloud;
of hybride.
Eigen tweede locatie
Voordelen kunnen zijn:
veel controle;
eigen infrastructuur;
en specifieke configuratiemogelijkheden.
Nadelen kunnen zijn:
investering;
beheer;
onderhoud;
en hardwarevervanging.
Extern datacenter
Een extern datacenter kan fysieke scheiding bieden zonder zelf een tweede serverruimte te beheren.
Kijk wel naar:
connectiviteit;
afstand;
toegang;
SLA;
en afhankelijkheden.
Cloud
Cloud kan schaalbaar en flexibel zijn.
Maar onderzoek:
kosten;
vendor lock-in;
netwerk;
skills;
en recoveryprocedures.
Hybride disaster recovery
Voor veel organisaties kan een hybride strategie logisch zijn.
Bijvoorbeeld productie on-premises en recovery in de cloud.
Of kritieke systemen in twee locaties en minder belangrijke workloads alleen vanuit back-up.
Kies geografische spreiding bewust
Een recovery-omgeving moet voldoende onafhankelijk zijn van de primaire omgeving.
Twee serverruimtes in hetzelfde gebouw beschermen niet tegen ieder scenario.
Denk daarom na over gebeurtenissen die beide locaties tegelijk kunnen raken.
Kies de juiste back-upstrategie
Welke recoveryarchitectuur je ook kiest:
betrouwbare back-ups blijven belangrijk.
Meerdere herstelkopieën
Voorkom afhankelijkheid van één kopie.
Wanneer één opslagomgeving beschadigd raakt, moet er een alternatief zijn.
Gescheiden back-ups
Zorg dat een incident in productie niet automatisch alle back-ups kan raken.
Technische en organisatorische scheiding kunnen hierbij belangrijk zijn.
Immutable back-up kiezen
Immutable opslag kan interessant zijn wanneer bescherming tegen ongewenste wijziging of verwijdering belangrijk is.
Vooral ransomware heeft dit onderwerp belangrijker gemaakt.
Offline back-up
Voor bepaalde omgevingen kan een offline of sterk geïsoleerde kopie een aanvullende beschermingslaag vormen.
Retentie kiezen
Hoeveel herstelpunten wil je bewaren?
Alleen de laatste back-up is niet altijd voldoende.
Misschien wordt een fout pas dagen later ontdekt.
Dan wil je mogelijk verder terug kunnen.
Kies herstelpunten op basis van risico
Denk bijvoorbeeld aan:
ransomware;
databasecorruptie;
per ongeluk verwijderen;
foutieve updates;
en menselijke fouten.
Niet ieder probleem wordt direct ontdekt.
Kies disaster recovery voor ransomware
Een moderne disaster recovery-strategie moet rekening houden met cyberaanvallen.
Dat vraagt meer dan alleen een snelle restore.
Schone herstelomgeving
Bij een cyberincident wil je voorkomen dat besmette systemen direct opnieuw worden gestart.
Een gecontroleerde recoveryomgeving kan daarom belangrijk zijn.
Gescheiden beheeraccounts
Productie en recovery volledig met dezelfde beheeraccounts toegankelijk maken kan extra risico veroorzaken.
Kies waar mogelijk voor voldoende scheiding.
MFA
Multi-factor authentication voor beheertoegang helpt het risico op misbruik van accounts te beperken.
Secrets en certificaten
Denk ook aan:
API-sleutels;
serviceaccounts;
certificaten;
tokens;
en andere secrets.
Na een securityincident kunnen deze vervangen moeten worden.
Kies disaster recovery voor Microsoft 365
Gebruikt de organisatie Microsoft 365?
Bepaal dan wat je wilt beschermen.
Bijvoorbeeld:
Exchange;
OneDrive;
SharePoint;
Teams;
en gebruikersdata.
Kijk naar de beschikbare herstelmogelijkheden en bepaal of aanvullende bescherming nodig is.
Kies disaster recovery voor SaaS
Bij SaaS moet je vooral kijken naar de verantwoordelijkheidsverdeling.
Vraag:
welke data kan de leverancier herstellen?
Hoe lang?
Welke exportmogelijkheden bestaan?
Wat gebeurt er bij verwijdering?
Wat gebeurt er als de leverancier langdurig uitvalt?
Kies disaster recovery voor databases
Databases vragen extra aandacht.
Een database simpelweg terugzetten kan gevolgen hebben voor:
transacties;
integriteit;
koppelingen;
en andere applicaties.
Bepaal daarom specifieke recoveryprocedures voor kritieke databases.
Kies disaster recovery voor virtuele machines
Virtualisatie kan recovery vereenvoudigen doordat volledige virtuele machines kunnen worden beschermd.
Maar test wel of:
VM’s starten;
netwerk klopt;
storage beschikbaar is;
en applicaties daadwerkelijk functioneren.
Kies disaster recovery voor fysieke servers
Niet iedere workload is gevirtualiseerd.
Voor fysieke servers moet mogelijk worden gekeken naar:
reservehardware;
bare-metal recovery;
drivers;
firmware;
en installatiebestanden.
Legacy-systemen
Oude systemen kunnen een grote uitdaging vormen.
Misschien is de oorspronkelijke hardware niet meer beschikbaar.
Of de software wordt niet meer ondersteund.
Test daarom voordat een calamiteit plaatsvindt of het systeem werkelijk kan worden hersteld.
Kies disaster recovery voor netwerkcomponenten
Servers zonder netwerk zijn weinig waard.
Neem daarom ook mee:
firewalls;
switches;
routers;
VPN;
DNS;
DHCP;
en configuraties.
Configuratieback-ups
Bewaar actuele configuraties van belangrijke netwerkapparatuur.
Dit kan herstel aanzienlijk versnellen.
Kies disaster recovery voor identity
Identity is tegenwoordig een kritieke afhankelijkheid.
Zonder authenticatie kunnen gebruikers mogelijk geen enkel ander systeem gebruiken.
Denk daarom aan:
Active Directory;
Entra ID;
MFA;
identity providers;
en privileged accounts.
Kies op basis van afhankelijkheden
Een veelgemaakte fout is systemen afzonderlijk bekijken.
Stel dat ERP afhankelijk is van:
Active Directory;
DNS;
database;
fileserver;
internet;
en een externe API.
Dan moeten deze afhankelijkheden in de juiste volgorde worden hersteld.
Maak een recoveryvolgorde
Bijvoorbeeld:
- basisinfrastructuur;
- netwerk;
- identity;
- storage;
- databases;
- kritieke applicaties;
- integraties;
- gebruikersdiensten;
- overige systemen.
De precieze volgorde verschilt per organisatie.
Kies automatisering waar dit voordeel oplevert
Recovery kan gedeeltelijk worden geautomatiseerd.
Bijvoorbeeld:
VM’s starten;
netwerken configureren;
resources aanmaken;
of recoveryplannen uitvoeren.
Dit kan snelheid en consistentie verbeteren.
Automatisering moet getest worden
Een automatisch script dat nooit is getest, geeft geen garantie.
Controleer daarom regelmatig of automatisering nog aansluit op de actuele omgeving.
Infrastructure as Code
Bij cloudomgevingen kan Infrastructure as Code interessant zijn.
Daarmee kan infrastructuur vanuit vastgelegde configuraties opnieuw worden opgebouwd.
Dit kan recovery ondersteunen.
Maar ook deze configuraties moeten:
veilig worden opgeslagen;
versiebeheerd;
en getest.
Kies de juiste disaster recovery leverancier
Naast de techniek moet je mogelijk een leverancier kiezen.
Kijk daarbij verder dan marketing en prijs.
Technische expertise
Heeft de leverancier aantoonbare ervaring met jouw:
cloudplatform;
virtualisatie;
besturingssystemen;
databases;
netwerk;
en applicaties?
Ervaring met vergelijkbare organisaties
Een leverancier die vooral zeer kleine bedrijven ondersteunt, is niet automatisch geschikt voor een complexe internationale infrastructuur.
Andersom kan een enterpriseprovider onnodig zwaar zijn voor een klein MKB-bedrijf.
Kies een passende schaal
De dienstverlening moet aansluiten op:
omvang;
complexiteit;
budget;
en interne kennis.
Managed of zelf beheren?
Dit is een belangrijke keuze.
Heeft de organisatie voldoende eigen expertise?
Dan kan een self-managed oplossing geschikt zijn.
Is die expertise beperkt?
Dan kan managed disaster recovery aantrekkelijker zijn.
Wie doet wat?
Leg duidelijk vast:
wie monitort;
wie incidenten beoordeelt;
wie recovery activeert;
wie systemen herstelt;
wie applicaties test;
en wie communiceert.
Kies op supportniveau
Heb je ondersteuning nodig:
alleen tijdens kantooruren;
’s avonds;
in het weekend;
of 24/7?
Stem support af op de werkelijke bedrijfsvoering.
24/7 is niet voor iedereen nodig
Een kantoor dat alleen maandag tot vrijdag overdag werkt heeft andere behoeften dan een webshop die continu orders ontvangt.
Betaal daarom niet automatisch voor het hoogste serviceniveau.
Maar kies ook niet te laag
Wanneer een systeem op zaterdagavond uitvalt en recovery pas maandagochtend begint, moet dat wel passen bij de bedrijfsimpact.
Kies op reactietijd
Controleer wat een SLA precies bedoelt.
Reactietijd betekent niet automatisch dat het systeem binnen die periode hersteld is.
Vraag daarom naar:
reactietijd;
start van herstel;
beoogde hersteltijd;
en escalatie.
Kies op testmogelijkheden
Een van de belangrijkste selectiecriteria is testen.
Een disaster recovery-oplossing die nooit wordt getest, levert vooral theoretische zekerheid.
Restore-test
Minimaal moet regelmatig gecontroleerd kunnen worden of data teruggezet kan worden.
Applicatietest
Beter is ook controleren of de volledige applicatie werkt.
Failover-test
Wanneer failover onderdeel is van de oplossing, moet dit getest kunnen worden.
Failback-test
Ook terugschakelen naar productie verdient aandacht.
Volledige DR-oefening
Voor kritieke omgevingen kan periodiek een grotere oefening nodig zijn.
Daarmee test je:
techniek;
mensen;
procedures;
communicatie;
en afhankelijkheden.
Kies een oplossing die meetbaar is
Vraag tijdens tests naar concrete resultaten.
Bijvoorbeeld:
werkelijke hersteltijd;
bereikt herstelpunt;
problemen;
afwijkingen;
en verbeterpunten.
Daarmee kun je controleren of de oplossing aan RTO en RPO voldoet.
Kies niet alleen op certificeringen
Certificeringen kunnen nuttig zijn.
Maar kijk ook naar praktische uitvoering.
Wie zit er tijdens een echte calamiteit achter de knoppen?
Heeft die persoon ervaring?
Zijn meerdere engineers beschikbaar?
Is kennis gedocumenteerd?
Kies niet alleen op reviews
Goede reviews zijn positief.
Maar een algemene beoordeling zegt weinig over technische disaster recovery-capaciteit.
Combineer reviews daarom met:
cases;
tests;
referenties;
technische gesprekken;
en contractuele afspraken.
Kies op documentatie
Goede disaster recovery moet reproduceerbaar zijn.
Niet afhankelijk van één engineer die alles uit zijn hoofd weet.
Vraag daarom naar:
architectuur;
recoveryprocedures;
contactlijsten;
afhankelijkheden;
configuraties;
en escalatie.
Documentatie buiten productie
Zorg dat belangrijke recoverydocumentatie ook beschikbaar is wanneer de normale IT-omgeving uitvalt.
Kies op monitoring
Een back-up die wekenlang niet goed draait heeft weinig waarde.
Kies daarom een oplossing waarbij problemen worden gedetecteerd.
Bijvoorbeeld:
mislukte back-up;
replicatiefout;
opslagtekort;
connectiviteitsprobleem;
of verlopen credentials.
Wie reageert op een waarschuwing?
Monitoring zonder opvolging is onvoldoende.
Leg daarom vast wie meldingen behandelt.
Kies op rapportage
Periodieke rapportage kan inzicht geven in:
back-upstatus;
replicatie;
tests;
incidenten;
opslag;
en eventuele afwijkingen.
Kies op schaalbaarheid
Een oplossing die vandaag perfect past kan over drie jaar te klein zijn.
Vraag daarom wat gebeurt wanneer:
data verdubbelt;
meer medewerkers komen;
nieuwe vestigingen openen;
extra servers worden toegevoegd;
of nieuwe cloudplatformen worden gebruikt.
Kies op flexibiliteit
Kun je systemen eenvoudig naar een andere recoverycategorie verplaatsen?
Misschien wordt een applicatie later bedrijfskritisch.
Dan moet je bescherming kunnen verhogen.
Kies op kosten
Prijs blijft natuurlijk belangrijk.
Maar vergelijk de totale kosten.
Niet alleen het maandbedrag.
Eenmalige kosten
Denk aan:
analyse;
ontwerp;
implementatie;
migratie;
configuratie;
documentatie;
en eerste test.
Terugkerende kosten
Denk aan:
licenties;
opslag;
cloud;
monitoring;
beheer;
support;
en tests.
Kosten tijdens calamiteit
Controleer ook wat gebeurt wanneer disaster recovery daadwerkelijk wordt geactiveerd.
Zijn extra:
cloudresources;
engineeruren;
restorekosten;
of supporturen
inbegrepen?
Kosten tijdens testen
Een test kan tijdelijke infrastructuur nodig hebben.
Vraag of dit inbegrepen is.
Kies prijs en risico samen
Een goedkopere oplossing met langere RTO kan uitstekend zijn wanneer langere downtime acceptabel is.
Een duurdere oplossing kan logisch zijn wanneer ieder uur uitval grote schade veroorzaakt.
Goedkoopste disaster recovery kiezen
De goedkoopste oplossing is niet automatisch verkeerd.
Wanneer deze aantoonbaar aan de eisen voldoet, kan het juist een verstandige keuze zijn.
Maar bespaar niet door essentiële onderdelen weg te laten.
Waar je niet op wilt besparen
Bijvoorbeeld:
restore-tests;
goede documentatie;
beveiliging;
monitoring;
of voldoende herstelkopieën.
Kies op contractvoorwaarden
Bekijk voor ondertekening:
contractduur;
opzegtermijn;
SLA;
prijswijzigingen;
verantwoordelijkheden;
data-eigendom;
en beëindiging.
Exitstrategie
Wat gebeurt er wanneer je later wilt overstappen?
Kun je:
data exporteren;
configuraties meenemen;
documentatie behouden;
en herstelkopieën migreren?
Vendor lock-in
Sommige oplossingen maken overstappen ingewikkeld.
Dat hoeft niet automatisch een probleem te zijn.
Maar je moet vooraf weten welke afhankelijkheid ontstaat.
Kies op dataopslag
Vraag waar back-ups en replicadata worden opgeslagen.
Denk aan:
locatie;
land;
cloudregio;
datacenter;
en gebruikte provider.
Encryptie
Controleer hoe data wordt beschermd:
tijdens transport;
en tijdens opslag.
Toegangsbeheer
Wie heeft toegang tot de recoveryomgeving?
Zijn beheerrechten beperkt?
Wordt MFA gebruikt?
Worden activiteiten gelogd?
Kies op compliance
Afhankelijk van sector en data kunnen aanvullende eisen gelden.
Neem daarom interne security-, privacy- en compliance-eisen mee in de selectie.
Disaster recovery kiezen voor klein bedrijf
Voor een klein bedrijf kan eenvoud belangrijk zijn.
Een passende oplossing kan bijvoorbeeld bestaan uit:
goede cloudback-up;
gescheiden herstelkopieën;
documentatie;
monitoring;
en periodieke restore-tests.
Een volledige hot site is waarschijnlijk niet voor iedere kleine organisatie nodig.
Disaster recovery kiezen voor MKB
MKB-bedrijven hebben vaak een hybride omgeving.
Bijvoorbeeld:
Microsoft 365;
lokale server;
SaaS;
boekhoudsoftware;
CRM;
en cloudopslag.
Kies dan een oplossing die deze verschillende onderdelen samen bekijkt.
Disaster recovery kiezen zonder interne IT-afdeling
Wanneer er geen interne IT-specialist aanwezig is, kan managed dienstverlening extra belangrijk worden.
Je wilt tijdens een calamiteit niet zelf hoeven uitzoeken:
waar de back-ups staan;
hoe servers worden hersteld;
of welke volgorde nodig is.
Disaster recovery kiezen voor grote organisatie
Grotere organisaties kunnen een gelaagde architectuur gebruiken.
Bijvoorbeeld:
high availability voor Tier 1;
replicatie voor Tier 2;
backup & restore voor Tier 3;
en archivering voor minder kritieke data.
Zo worden kosten gericht ingezet.
Disaster recovery kiezen voor meerdere vestigingen
Heeft de organisatie meerdere locaties?
Bepaal dan of deze locaties:
elkaar kunnen opvangen;
eigen infrastructuur hebben;
dezelfde applicaties gebruiken;
of volledig afhankelijk zijn van een centraal datacenter.
Centrale recovery
Een centrale recoveryomgeving kan beheer vereenvoudigen.
Maar controleer netwerkafhankelijkheid.
Recovery per vestiging
Voor bepaalde organisaties kan lokale recovery nodig zijn.
Bijvoorbeeld wanneer een locatie zelfstandig moet kunnen blijven functioneren.
Disaster recovery kiezen voor thuiswerk
Veel organisaties hebben structureel thuiswerk.
Denk daarom ook aan:
VPN;
identity;
cloudtoegang;
laptops;
virtuele desktops;
en communicatie.
Een hersteld datacenter heeft weinig waarde wanneer medewerkers er niet bij kunnen.
Disaster recovery kiezen voor webshop
Bij een webshop kan de prioriteit bijvoorbeeld liggen bij:
website;
database;
betalingen;
voorraad;
DNS;
ERP;
en logistieke integraties.
Kijk naar de hele klantreis.
Disaster recovery kiezen voor productie
Bij productie kan IT-uitval direct operationele gevolgen hebben.
Neem daarom ook:
OT;
machineconfiguraties;
productieplanning;
SCADA;
PLC’s;
en industriële netwerken
mee wanneer deze relevant zijn.
Disaster recovery kiezen voor zorg
Bij zorg kunnen beschikbaarheid en vertrouwelijkheid beide belangrijk zijn.
Herstel moet daarom niet alleen snel maar ook veilig plaatsvinden.
Disaster recovery kiezen voor financiële dienstverlening
Bij financiële systemen kunnen:
dataconsistentie;
transacties;
logging;
en auditability
extra belangrijk zijn.
De gekozen recoverymethode moet daarbij aansluiten.
Kies een oplossing die bij mensen past
Technologie alleen bepaalt niet of disaster recovery werkt.
Mensen moeten weten:
wat ze moeten doen;
wanneer het plan wordt geactiveerd;
wie beslist;
en wie communiceert.
Training
Medewerkers met een recoveryrol moeten procedures kennen.
Oefen daarom regelmatig.
Tabletop exercise
Een eenvoudige manier is een fictief scenario bespreken.
Bijvoorbeeld:
“Ransomware heeft onze belangrijkste servers getroffen. Wat doen we nu?”
Hiermee ontdek je snel onduidelijkheden.
Technische oefening
Daarna kun je daadwerkelijk systemen herstellen.
Dat laat zien of procedures ook technisch werken.
Kies niet voor papieren zekerheid
Een mooi disaster recovery-plan is nuttig.
Maar uiteindelijk moet het functioneren wanneer:
servers niet beschikbaar zijn;
accounts problemen hebben;
medewerkers onder druk staan;
en klanten wachten.
Praktijktests zijn daarom essentieel.
Proof of concept voor disaster recovery
Bij een grote investering kan een proof of concept verstandig zijn.
Selecteer bijvoorbeeld enkele kritieke workloads.
Test:
replicatie;
restore;
failover;
netwerk;
security;
en hersteltijd.
Pilot
Je kunt ook beginnen met één afdeling of applicatie.
Na succesvolle tests kan de oplossing verder worden uitgerold.
Disaster recovery oplossing vergelijken
Heb je meerdere oplossingen over?
Vergelijk ze dan op vaste criteria.
Bijvoorbeeld:
Bedrijfsfit
Past de oplossing bij de kritieke processen?
RTO
Kan de gewenste hersteltijd worden gehaald?
RPO
Kan het gewenste herstelpunt worden gehaald?
Security
Zijn recovery en back-ups voldoende beschermd?
Ransomware
Kan veilig worden hersteld na een cyberaanval?
Testen
Kan recovery realistisch worden geoefend?
Beheer
Past de oplossing bij de interne kennis?
Support
Is hulp beschikbaar wanneer nodig?
Schaalbaarheid
Kan de oplossing meegroeien?
Kosten
Past de totale investering bij het risico?
Contract
Zijn verantwoordelijkheden duidelijk?
Exit
Kun je later overstappen?
Maak must-haves
Bepaal vooraf welke eisen absoluut noodzakelijk zijn.
Bijvoorbeeld:
maximale RTO;
maximale RPO;
immutable back-up;
MFA;
24/7 support;
geografische scheiding;
periodieke DR-test;
of ondersteuning voor specifieke applicaties.
Maak nice-to-haves
Andere eigenschappen kunnen prettig zijn maar niet noodzakelijk.
Bijvoorbeeld:
uitgebreide dashboards;
extra rapportages;
specifieke automatisering;
of aanvullende integraties.
Door dit onderscheid te maken voorkom je dat aantrekkelijke functies belangrijker worden dan de kernvereisten.
Rode vlag: geen testmogelijkheid
Een oplossing die je niet realistisch kunt testen is moeilijk te vertrouwen.
Rode vlag: alleen back-up
Wanneer de leverancier alleen uitlegt hoe data wordt opgeslagen maar niet hoe volledige applicaties worden hersteld, is mogelijk geen sprake van volwaardige disaster recovery.
Rode vlag: onrealistische RTO
Extreem snelle recovery beloven zonder de infrastructuur uitgebreid te analyseren verdient extra vragen.
Rode vlag: onduidelijke RPO
Vraag altijd welk herstelpunt werkelijk haalbaar is.
Rode vlag: geen ransomwarestrategie
Cyberrecovery hoort tegenwoordig serieus te worden meegenomen.
Rode vlag: alle systemen hetzelfde behandelen
Dit kan onnodig duur zijn of kritieke systemen onvoldoende beschermen.
Rode vlag: geen afhankelijkheden analyseren
Een server is zelden een volledig zelfstandig systeem.
Rode vlag: geen failback
Na de calamiteit moet je uiteindelijk terug naar de normale situatie.
Ook dat moet worden voorbereid.
Rode vlag: geen monitoring
Je moet weten wanneer bescherming niet goed functioneert.
Rode vlag: één beheerder
Wanneer slechts één persoon de omgeving begrijpt, ontstaat een operationeel risico.
Rode vlag: onduidelijke kosten bij calamiteit
Juist tijdens een incident wil je geen discussie over onverwachte tarieven of verantwoordelijkheden.
Disaster recovery IT kiezen: stappenplan
Stap 1: bepaal kritieke bedrijfsprocessen
Welke activiteiten moeten zo snel mogelijk doorgaan?
Stap 2: koppel IT-systemen aan deze processen
Welke systemen zijn noodzakelijk?
Stap 3: bepaal bedrijfsimpact
Wat gebeurt er wanneer een systeem uitvalt?
Stap 4: classificeer systemen
Maak verschillende recoverycategorieën.
Stap 5: bepaal RTO
Hoe snel moet ieder systeem terug?
Stap 6: bepaal RPO
Hoeveel gegevensverlies is acceptabel?
Stap 7: breng afhankelijkheden in kaart
Denk aan netwerk, identity, databases en integraties.
Stap 8: beoordeel risico’s
Technische storing, ransomware, brand, cloudstoring en menselijke fouten.
Stap 9: kies beschermingsniveau
Backup & restore, replicatie, cloud recovery, DRaaS of andere strategie.
Stap 10: kies recoverylocatie
Eigen locatie, datacenter, cloud of hybride.
Stap 11: kies back-upstrategie
Meerdere kopieën, retentie en voldoende scheiding.
Stap 12: ontwerp ransomware recovery
Bescherm herstelvoorzieningen tegen dezelfde aanval.
Stap 13: bepaal beheer
Zelf beheren of managed dienstverlening.
Stap 14: bepaal support
Kantooruren of 24/7.
Stap 15: vergelijk leveranciers
Gebruik dezelfde eisen.
Stap 16: vergelijk totale kosten
Niet alleen abonnementskosten.
Stap 17: controleer contracten
SLA, verantwoordelijkheden en exit.
Stap 18: voer eventueel een proof of concept uit
Test kritieke onderdelen.
Stap 19: voer een volledige eerste recovery-test uit
Controleer of de oplossing daadwerkelijk functioneert.
Stap 20: meet RTO en RPO
Vergelijk werkelijkheid met doelstellingen.
Stap 21: verbeter tekortkomingen
Los problemen op voordat een echte calamiteit plaatsvindt.
Stap 22: blijf testen
Disaster recovery is geen eenmalig project.
Checklist disaster recovery IT kiezen
Gebruik deze checklist voor de uiteindelijke beslissing.
Bedrijf
Zijn kritieke processen bekend?
Is de impact van downtime bepaald?
Zijn systemen geprioriteerd?
RTO
Heeft ieder kritisch systeem een realistische RTO?
Kan de oplossing deze aantoonbaar halen?
RPO
Is acceptabel dataverlies vastgesteld?
Past de back-up- of replicatiefrequentie daarbij?
Technologie
Backup & restore?
Replicatie?
Cloud recovery?
DRaaS?
Cold, warm of hot site?
Hybride oplossing?
Data
Hoeveel data wordt beschermd?
Welke retentie?
Meerdere herstelpunten?
Security
MFA?
Encryptie?
Gescheiden accounts?
Immutable back-up?
Voldoende geïsoleerde herstelkopie?
Ransomware
Clean recovery?
Veilige herstelomgeving?
Credential reset?
Malwarecontrole?
Infrastructuur
Servers?
Storage?
Netwerk?
Firewalls?
DNS?
Identity?
Databases?
Cloud
Welke regio?
Welke accounts?
Welke netwerkverbindingen?
Welke kosten tijdens recovery?
SaaS
Welke data kan worden hersteld?
Welke verantwoordelijkheid ligt bij de provider?
Leverancier
Relevante ervaring?
Voldoende engineers?
Heldere verantwoordelijkheden?
Goede bereikbaarheid?
Support
Kantooruren?
24/7?
Reactietijd?
Escalatie?
Testen
Restore-test?
Applicatietest?
Failover-test?
Failback-test?
Volledige DR-oefening?
Monitoring
Worden fouten automatisch gedetecteerd?
Wie reageert?
Documentatie
Recoveryplan?
Architectuur?
Afhankelijkheden?
Contactgegevens?
Stappenplan?
Kosten
Implementatie?
Licenties?
Opslag?
Cloud?
Beheer?
Support?
Testen?
Werkelijke recovery?
Contract
SLA?
Looptijd?
Opzegging?
Data-eigendom?
Exitstrategie?
Kun je deze vragen duidelijk beantwoorden, dan heb je een veel betere basis om een passende disaster recovery IT-oplossing te kiezen.
Veelgestelde vragen over disaster recovery IT kiezen
Hoe kies ik disaster recovery IT?
Begin bij bedrijfsimpact, kritieke systemen, RTO en RPO. Kies daarna pas de technologie en leverancier.
Wat is de beste disaster recovery oplossing?
Er bestaat geen universeel beste oplossing. De juiste keuze hangt af van de IT-omgeving, bedrijfsrisico’s, gewenste hersteltijd en het budget.
Moet ik kiezen voor cloud disaster recovery?
Cloud recovery kan aantrekkelijk zijn vanwege flexibiliteit en schaalbaarheid, maar is niet automatisch voor iedere omgeving de beste oplossing.
Is DRaaS een goede keuze?
DRaaS kan interessant zijn wanneer je recovery-infrastructuur en eventueel beheer als dienst wilt afnemen.
Moet ik een tweede datacenter hebben?
Niet altijd. Cloud disaster recovery, DRaaS of andere strategieën kunnen alternatieven bieden.
Wat is beter: backup of replicatie?
Ze hebben verschillende functies. Back-ups bieden herstelpunten, terwijl replicatie snelle beschikbaarheid van data of systemen kan ondersteunen. Vaak worden beide gecombineerd.
Wat is belangrijker: RTO of RPO?
Beide zijn belangrijk. RTO gaat over hersteltijd en RPO over acceptabel dataverlies.
Moet ieder systeem dezelfde RTO hebben?
Nee. Verschillende systemen kunnen verschillende herstelprioriteiten krijgen.
Wat is het voordeel van verschillende recovery tiers?
Je kunt meer investeren in kritieke systemen en minder in systemen die langere tijd gemist kunnen worden.
Moet disaster recovery ransomware meenemen?
Ja, wanneer cyberaanvallen een relevant bedrijfsrisico vormen moet worden nagedacht over veilig herstel vanuit betrouwbare kopieën.
Zijn immutable back-ups noodzakelijk?
Dat hangt af van de risico’s en omgeving. Ze kunnen een belangrijke extra beschermingslaag bieden tegen ongewenste wijziging of verwijdering.
Hoe kies ik tussen cold, warm en hot site?
Kijk vooral naar gewenste herstelsnelheid en budget. Hoe verder de tweede omgeving voorbereid is, hoe sneller recovery doorgaans mogelijk wordt, maar hoe hoger de structurele kosten kunnen zijn.
Is een hot site altijd beter?
Niet noodzakelijk. Wanneer een systeem een dag gemist kan worden, kan een hot site onnodig duur zijn.
Kan een klein bedrijf disaster recovery gebruiken?
Zeker. De oplossing kan veel eenvoudiger zijn dan bij een grote onderneming.
Zelf beheren of uitbesteden?
Dat hangt af van beschikbare kennis, capaciteit en gewenste ondersteuning. Organisaties met weinig interne IT-capaciteit kunnen voordeel hebben van managed dienstverlening.
Hoe weet ik of de oplossing werkt?
Door recovery daadwerkelijk te testen en de werkelijke hersteltijd en het bereikte herstelpunt te meten.
Hoe vaak moet disaster recovery getest worden?
De juiste frequentie hangt af van risico en veranderingen in de omgeving. Test in ieder geval structureel en opnieuw na belangrijke wijzigingen.
Moet failback worden getest?
Ja. Terugschakelen naar de normale omgeving kan complex zijn en verdient daarom eveneens aandacht.
Waar moet ik op letten bij een disaster recovery leverancier?
Onder andere expertise, testmogelijkheden, support, security, ransomware recovery, documentatie, SLA en transparante kosten.
Moet ik de goedkoopste disaster recovery oplossing kiezen?
Alleen wanneer deze aantoonbaar aan de noodzakelijke herstel- en beveiligingseisen voldoet.
Kan ik later van disaster recovery oplossing veranderen?
Meestal wel, maar onderzoek vooraf data-export, contractvoorwaarden en mogelijke vendor lock-in.
Conclusie: disaster recovery IT kiezen draait om de juiste balans tussen risico, herstel en kosten
Disaster recovery IT kiezen begint niet bij een leverancier, softwarepakket of cloudplatform.
Het begint bij de organisatie.
Vraag eerst:
Welke bedrijfsprocessen zijn kritiek?
Welke IT-systemen zijn daarvoor nodig?
Hoe lang mogen deze uitvallen?
Hoeveel gegevens mogen verloren gaan?
Welke incidenten moeten we kunnen opvangen?
Daarna kun je bepalen welke technische oplossing daarbij past.
Voor sommige systemen is traditionele backup & restore voldoende.
Andere systemen hebben misschien:
replicatie;
cloud recovery;
DRaaS;
een warm site;
een hot site;
of actieve redundantie
nodig.
Het hoeft bovendien geen keuze voor één technologie te zijn.
Juist een combinatie van verschillende beschermingsniveaus kan verstandig zijn.
Geef de meest kritieke systemen de sterkste bescherming.
Accepteer langere recovery voor minder belangrijke systemen.
Daarmee ontstaat een disaster recovery-strategie die zowel technisch als financieel beter aansluit op de organisatie.
Kijk vervolgens verder dan alleen techniek.
Een goede oplossing moet ook beschikken over:
duidelijke verantwoordelijkheden;
monitoring;
security;
documentatie;
support;
en vooral goede testmogelijkheden.
Want uiteindelijk telt niet wat een brochure belooft.
Het telt wat er gebeurt wanneer de primaire IT-omgeving daadwerkelijk uitvalt.
Kun je dan herstellen?
Hoe snel?
Naar welk herstelpunt?
Werken de applicaties daarna echt?
Kunnen medewerkers weer inloggen?
Werken koppelingen?
En weet iedereen wat hij moet doen?
Daarom is testen een essentieel onderdeel van de keuze.
De juiste disaster recovery IT-oplossing is uiteindelijk de oplossing die aantoonbaar aansluit op de bedrijfsimpact, de afgesproken RTO en RPO kan ondersteunen en binnen een verantwoord budget daadwerkelijk herstelbaar is wanneer zich een ernstige IT-storing voordoet.