Wil je disaster recovery IT vinden voor jouw organisatie?
Dan zoek je waarschijnlijk meer dan alleen een leverancier die ergens een back-up van je bestanden bewaart.
Bij een ernstig IT-incident moet je erop kunnen vertrouwen dat belangrijke systemen daadwerkelijk kunnen worden hersteld.
Bijvoorbeeld na:
ransomware;
serveruitval;
een cyberaanval;
databasecorruptie;
menselijke fouten;
hardwareproblemen;
stroomuitval;
brand;
waterschade;
of uitval van een datacenter.
Een geschikte disaster recovery IT-partner moet daarom niet alleen kunnen vertellen hoe back-ups worden gemaakt.
De leverancier moet ook kunnen uitleggen:
wat er gebeurt wanneer de primaire omgeving volledig uitvalt;
welke systemen als eerste worden hersteld;
waar herstel plaatsvindt;
hoe snel dit kan;
hoeveel gegevens mogelijk verloren gaan;
wie tijdens een calamiteit verantwoordelijk is;
en hoe regelmatig wordt getest of het herstelproces daadwerkelijk werkt.
Juist daar zit het verschil tussen simpelweg back-ups maken en een professionele disaster recovery-strategie.
In deze uitgebreide gids lees je hoe je disaster recovery IT kunt vinden, welke leveranciers je kunt overwegen, waarop je moet letten en welke vragen je moet stellen voordat je een IT-partner kiest.
Wat betekent disaster recovery IT vinden?
Disaster recovery IT vinden betekent dat je op zoek gaat naar een technische oplossing en eventueel een gespecialiseerde IT-partner waarmee je belangrijke IT-systemen na een ernstige verstoring kunt herstellen.
Dat kan bijvoorbeeld gaan om:
back-up en restore;
cloud disaster recovery;
server recovery;
replicatie;
Disaster Recovery as a Service;
alternatieve infrastructuur;
ransomware recovery;
business continuity;
of een combinatie hiervan.
Welke oplossing geschikt is, hangt volledig af van de organisatie.
Zoek niet direct naar een product
Een veelgemaakte fout is beginnen met technologie.
Bijvoorbeeld:
“We hebben DRaaS nodig.”
Of:
“We willen cloud disaster recovery.”
Maar misschien is dat helemaal niet de juiste oplossing.
Begin daarom eerst bij de bedrijfsbehoefte.
Wat moet worden beschermd?
Maak een eerste inventarisatie van de belangrijkste IT.
Denk aan:
servers;
virtuele machines;
databases;
ERP;
CRM;
bestandsopslag;
Microsoft 365;
cloudomgevingen;
websites;
webshops;
netwerken;
identity;
en bedrijfsspecifieke applicaties.
Pas wanneer je weet wat beschermd moet worden, kun je gericht naar een disaster recovery-specialist zoeken.
Welke systemen zijn bedrijfskritisch?
Niet ieder systeem heeft dezelfde prioriteit.
Een CRM-systeem kan bijvoorbeeld belangrijk zijn.
Maar misschien is het ERP-systeem absoluut noodzakelijk om:
orders;
productie;
voorraad;
logistiek;
en facturatie
te laten functioneren.
Breng daarom vooraf in kaart welke systemen de grootste bedrijfsimpact hebben.
Hoe lang mag een systeem uitvallen?
Dit is een van de belangrijkste vragen bij het vinden van een disaster recovery-oplossing.
Is:
één uur;
vier uur;
acht uur;
één werkdag;
of meerdere dagen
acceptabel?
Het antwoord heeft grote invloed op de benodigde oplossing.
RTO bepalen
De gewenste hersteltijd wordt vaak vastgelegd als Recovery Time Objective, oftewel RTO.
Wanneer een belangrijke applicatie binnen vier uur weer beschikbaar moet zijn, vormt dit een uitgangspunt voor het ontwerp.
Een goede disaster recovery IT-specialist vraagt daarom naar RTO.
RPO bepalen
Daarnaast is de Recovery Point Objective, oftewel RPO, belangrijk.
Hiermee bepaal je hoeveel recente gegevens maximaal verloren mogen gaan.
Dat kan bijvoorbeeld:
een dag;
enkele uren;
een uur;
of veel minder
zijn.
Ook dit bepaalt welke techniek nodig is.
Een specialist die niet naar RTO en RPO vraagt
Wees kritisch wanneer een leverancier direct een standaardpakket adviseert zonder te vragen naar:
bedrijfsimpact;
hersteltijd;
gegevensverlies;
systemen;
afhankelijkheden;
en huidige infrastructuur.
Disaster recovery moet aansluiten op bedrijfsdoelen.
Niet andersom.
Waar kun je disaster recovery IT vinden?
Er zijn verschillende typen leveranciers die disaster recovery kunnen aanbieden.
Denk aan:
IT-beheerbedrijven;
managed service providers;
cloudspecialisten;
cybersecuritybedrijven;
datacenters;
back-upspecialisten;
DRaaS-providers;
en gespecialiseerde disaster recovery-consultants.
Het juiste type leverancier hangt af van je omgeving.
IT-beheerbedrijf
Werk je al met een IT-beheerder?
Vraag dan eerst welke disaster recovery-diensten deze partij levert.
Een bestaande IT-partner kent mogelijk al:
servers;
netwerk;
cloudomgeving;
gebruikers;
en applicaties.
Dat kan een voordeel zijn.
Maar controleer wel of disaster recovery daadwerkelijk een specialisme is.
Managed Service Provider
Een Managed Service Provider, vaak MSP genoemd, beheert meerdere onderdelen van de IT-omgeving.
Sommige MSP’s leveren ook:
back-up;
monitoring;
security;
cloud;
en disaster recovery.
Dit kan interessant zijn wanneer je één partij verantwoordelijk wilt maken voor een groot gedeelte van de IT.
Disaster recovery-specialist
Een gespecialiseerde disaster recovery-partner richt zich sterker op continuïteit en herstel.
Zo’n partij kan bijvoorbeeld helpen met:
risicoanalyse;
RTO en RPO;
recovery-architectuur;
replicatie;
DRaaS;
hersteltests;
en disaster recovery-plannen.
Cloudspecialist
Draait een groot gedeelte van de infrastructuur in de cloud?
Dan kan een cloudspecialist geschikt zijn.
Bijvoorbeeld wanneer je recovery wilt organiseren binnen of tussen cloudomgevingen.
Cybersecurityspecialist
Wanneer ransomware en cyberincidenten een belangrijk onderdeel van de risicoanalyse vormen, kan cybersecurity-expertise belangrijk zijn.
Recovery na ransomware is namelijk niet hetzelfde als herstellen na een kapotte server.
Datacenterprovider
Organisaties met fysieke infrastructuur kunnen disaster recovery-diensten afnemen bij datacenterproviders.
Bijvoorbeeld:
colocatie;
tweede locatie;
connectiviteit;
of alternatieve infrastructuur.
Back-upleverancier
Een back-upleverancier kan een belangrijk gedeelte van disaster recovery verzorgen.
Maar controleer of de dienstverlening verder gaat dan alleen het bewaren van kopieën.
Disaster Recovery as a Service vinden
Disaster Recovery as a Service, vaak afgekort als DRaaS, kan interessant zijn wanneer je geen volledig tweede datacenter wilt onderhouden.
Bij DRaaS wordt recovery-infrastructuur als dienst geleverd.
Wat kan DRaaS bevatten?
Afhankelijk van de leverancier bijvoorbeeld:
replicatie;
cloudopslag;
stand-by infrastructuur;
failover;
monitoring;
testen;
en ondersteuning tijdens recovery.
Niet iedere DRaaS-dienst bevat hetzelfde.
Vergelijk daarom de precieze scope.
Lokale disaster recovery IT-partner
Een lokale IT-partner kan voordelen hebben.
Bijvoorbeeld:
kennis van de regionale markt;
persoonlijk contact;
mogelijkheid tot locatiebezoek;
en korte communicatielijnen.
Voor organisaties met lokale fysieke infrastructuur kan dit extra interessant zijn.
Landelijke disaster recovery-provider
Een landelijke leverancier kan juist beschikken over:
grotere supportteams;
meerdere locaties;
24/7 ondersteuning;
bredere expertise;
en uitgebreide infrastructuur.
Ook dit kan een voordeel zijn.
Lokaal versus landelijk
Kies niet automatisch voor lokaal of landelijk.
Kijk vooral naar:
expertise;
beschikbaarheid;
technologie;
support;
ervaring;
en aansluiting op jouw IT-omgeving.
Internationale disaster recovery-provider
Internationale organisaties kunnen behoefte hebben aan een leverancier die meerdere landen of regio’s ondersteunt.
Let dan onder andere op:
supporttijden;
datacenters;
cloudregio’s;
wetgeving;
dataopslag;
en internationale escalatie.
Zoek een specialist die jouw omgeving begrijpt
Niet iedere disaster recovery-specialist heeft dezelfde technische expertise.
Gebruik je voornamelijk:
Microsoft;
VMware;
Hyper-V;
Azure;
AWS;
Linux;
Kubernetes;
SaaS;
of een specifieke brancheapplicatie?
Zoek dan een partij met aantoonbare ervaring in die omgeving.
Microsoft disaster recovery specialist
Organisaties die sterk op Microsoft-technologie draaien kunnen bijvoorbeeld expertise nodig hebben rond:
Windows Server;
Active Directory;
Microsoft 365;
Azure;
SQL Server;
en identity.
Azure disaster recovery
Gebruik je Microsoft Azure?
Dan moet de specialist begrijpen hoe:
virtuele machines;
storage;
netwerken;
identity;
back-ups;
en recovery
binnen de cloudarchitectuur samenhangen.
AWS disaster recovery
Hetzelfde geldt voor Amazon Web Services.
De leverancier moet niet alleen AWS kennen, maar ook kunnen uitleggen hoe recovery voor jouw specifieke workloads wordt ontworpen.
VMware disaster recovery
Veel organisaties gebruiken virtualisatie.
Bij VMware-omgevingen kan ervaring met:
virtuele machines;
storage;
replicatie;
back-up;
en herstel
belangrijk zijn.
Hybride disaster recovery
Veel bedrijven hebben geen volledig cloud- of volledig lokale omgeving.
Ze gebruiken een combinatie van:
on-premises servers;
Microsoft 365;
SaaS;
cloud;
lokale netwerken;
en externe datacenters.
Zoek in dat geval een partij die hybride IT begrijpt.
SaaS meenemen
Vraag een disaster recovery IT-partner ook naar SaaS.
Bijvoorbeeld:
Wat gebeurt er met gegevens in online applicaties?
Welke herstelmogelijkheden biedt de SaaS-provider?
Zijn aanvullende back-ups nodig?
Hoe exporteren we data?
Een compleet recoveryplan kijkt verder dan alleen eigen servers.
Microsoft 365 meenemen
Microsoft 365 is voor veel bedrijven bedrijfskritisch.
Denk aan:
Exchange;
Teams;
SharePoint;
OneDrive;
en identiteit.
Vraag hoe deze omgeving wordt meegenomen in de recoverystrategie.
Active Directory en identity
Een vaak onderschat onderdeel is identiteit.
Wanneer medewerkers zich niet kunnen aanmelden, zijn veel herstelde systemen alsnog onbruikbaar.
Een goede specialist kijkt daarom ook naar:
Active Directory;
Entra ID;
MFA;
beheeraccounts;
serviceaccounts;
en toegangsrechten.
Netwerk meenemen
Een server herstellen is niet voldoende wanneer:
DNS niet werkt;
de firewall verkeerd staat;
VPN niet beschikbaar is;
of netwerkverbindingen ontbreken.
Daarom moet netwerkherstel onderdeel zijn van de analyse.
Vraag naar afhankelijkheden
Dit is een goede test voor een potentiële leverancier.
Vraag:
Hoe brengen jullie technische afhankelijkheden tussen onze systemen in kaart?
Een professionele partij kijkt bijvoorbeeld naar:
database;
identity;
DNS;
netwerk;
API’s;
licenties;
storage;
en externe leveranciers.
Applicatieherstel
Een virtuele machine succesvol starten betekent niet automatisch dat de applicatie werkt.
De echte vraag is:
Kan de gebruiker de bedrijfsapplicatie weer gebruiken?
Zoek daarom een leverancier die end-to-end herstel kan testen.
Branchekennis
Voor sommige organisaties kan branchekennis belangrijk zijn.
Bijvoorbeeld in:
zorg;
finance;
productie;
logistiek;
e-commerce;
overheid;
of professionele dienstverlening.
De technische basis kan vergelijkbaar zijn, maar bedrijfsrisico’s verschillen.
Disaster recovery voor MKB vinden
Een MKB-bedrijf heeft vaak behoefte aan een praktische oplossing.
Niet een enorm recoveryprogramma met honderden pagina’s documentatie.
Maar wel:
goede back-ups;
heldere verantwoordelijkheden;
duidelijke RTO/RPO;
geteste restores;
en betrouwbare ondersteuning.
Zoek daarom een partij die oplossingen kan aanpassen aan de schaal van het bedrijf.
Geen interne IT-afdeling
Heeft je organisatie geen eigen IT-team?
Dan wordt de rol van de externe leverancier groter.
Vraag dan expliciet:
Wie detecteert problemen?
Wie beslist dat recovery nodig is?
Wie voert recovery uit?
Wie communiceert met leveranciers?
Wie controleert of applicaties weer werken?
Disaster recovery voor grote organisaties vinden
Grotere organisaties hebben vaak meerdere specialisten nodig.
Bijvoorbeeld voor:
cloud;
netwerk;
security;
databases;
applicaties;
en infrastructuur.
De disaster recovery-partner moet dan goed kunnen samenwerken met interne IT-teams en andere leveranciers.
Disaster recovery voor productiebedrijf
Productiebedrijven kunnen naast gewone IT ook OT gebruiken.
Denk aan:
productielijnen;
SCADA;
PLC’s;
industriële netwerken;
en machineconfiguraties.
Zoek dan een specialist die begrijpt dat herstel van kantoor-IT niet automatisch betekent dat productie weer draait.
Disaster recovery voor webshop
Bij een webshop kunnen onder andere kritisch zijn:
webshopplatform;
database;
betalingen;
voorraad;
ERP;
CRM;
hosting;
DNS;
en logistieke koppelingen.
Vraag de leverancier hoe de volledige keten wordt hersteld.
Disaster recovery voor zorgorganisatie
Binnen de zorg kunnen beschikbaarheid, privacy en informatiebeveiliging zwaar wegen.
Een leverancier moet daarom niet alleen technisch sterk zijn, maar ook begrijpen welke eisen binnen de organisatie gelden.
Disaster recovery voor financiële organisatie
Financiële processen kunnen strenge eisen stellen aan:
dataconsistentie;
transacties;
beschikbaarheid;
audit;
en beveiliging.
Zoek daarom relevante ervaring wanneer dit voor de organisatie belangrijk is.
Disaster recovery voor accountantskantoor
Ook kleinere zakelijke dienstverleners kunnen sterk afhankelijk zijn van:
documenten;
e-mail;
boekhoudsoftware;
klantgegevens;
en cloudapplicaties.
Een relatief eenvoudige IT-omgeving kan daardoor toch bedrijfskritisch zijn.
Disaster recovery voor advocatenkantoor
Beschikbaarheid en vertrouwelijkheid kunnen beide belangrijk zijn.
Vraag daarom niet alleen hoe snel gegevens terugkomen, maar ook hoe hersteldata wordt beveiligd.
Disaster recovery voor logistiek bedrijf
Logistieke organisaties kunnen afhankelijk zijn van:
planning;
warehousemanagement;
scanners;
ERP;
transportmanagement;
en klantkoppelingen.
Hier moet recovery rekening houden met de volledige operationele keten.
Begin met een disaster recovery scan
Weet je nog niet welke oplossing nodig is?
Dan kan een eerste analyse of disaster recovery scan verstandig zijn.
Daarmee wordt de bestaande situatie onderzocht.
Wat moet een DR-scan bekijken?
Bijvoorbeeld:
IT-infrastructuur;
kritieke systemen;
back-ups;
retentie;
cloud;
netwerk;
security;
RTO;
RPO;
documentatie;
leveranciers;
en bestaande herstelprocedures.
Gap-analyse
Vervolgens kan worden vastgesteld waar verschillen bestaan tussen:
de gewenste situatie
en
de huidige mogelijkheden.
Misschien wil het bedrijf binnen vier uur herstellen, terwijl de huidige procedure waarschijnlijk twee dagen nodig heeft.
Dat is een belangrijke constatering.
Vraag om concrete bevindingen
Een goede analyse moet niet eindigen met alleen:
“Uw disaster recovery kan beter.”
Je wilt weten:
wat ontbreekt;
welk risico dit veroorzaakt;
welke verbetering nodig is;
en welke prioriteit dit heeft.
Zoek naar aantoonbare ervaring
Een leverancier kan op een website veel beloven.
Vraag daarom naar concrete ervaring.
Bijvoorbeeld:
vergelijkbare IT-omgevingen;
vergelijkbare bedrijfsgrootte;
gebruikte technologie;
en uitgevoerde recovery-tests.
Referentiecases
Cases kunnen helpen beoordelen of een partij werkelijk disaster recovery-projecten uitvoert.
Let op informatie over:
uitgangssituatie;
probleem;
oplossing;
RTO/RPO;
test;
en resultaat.
Reviews
Reviews kunnen aanvullende informatie geven.
Let vooral op terugkerende opmerkingen over:
bereikbaarheid;
deskundigheid;
communicatie;
problemen oplossen;
en support.
Reviews niet als enige criterium
Een IT-bedrijf kan uitstekende algemene reviews hebben zonder veel disaster recovery-expertise.
Gebruik reviews daarom als aanvulling.
Niet als technisch bewijs.
Certificeringen
Certificeringen kunnen iets zeggen over kennis of processen.
Maar een logo op een website garandeert niet dat de specifieke engineer die jouw omgeving beheert voldoende ervaring heeft.
Vraag daarom ook naar het team.
Wie voert het werk uit?
Een belangrijk punt.
Praat je tijdens verkoop met een ervaren architect, maar wordt het dagelijkse beheer later uitgevoerd door een totaal ander team?
Vraag daarom:
Wie ontwerpt de oplossing?
Wie implementeert?
Wie monitort?
Wie voert recovery uit?
Wie is bereikbaar tijdens een calamiteit?
24/7 disaster recovery support
Niet iedere organisatie heeft 24/7 ondersteuning nodig.
Maar wanneer jouw systemen continu beschikbaar moeten zijn, kan dit belangrijk zijn.
Controleer dan of 24/7 echt betekent:
technische engineers beschikbaar
en niet alleen:
een telefoonnummer waarop een melding kan worden achtergelaten.
Reactietijd
Vraag wat er gebeurt nadat je een kritiek incident meldt.
Bijvoorbeeld:
binnen hoeveel tijd reageert iemand?
Wanneer begint technisch onderzoek?
Wanneer start recovery?
Wie mag recovery autoriseren?
SLA controleren
Deze afspraken kunnen in een Service Level Agreement worden vastgelegd.
Controleer daarbij het verschil tussen:
reactietijd;
oplossingstijd;
hersteltijd;
en beschikbaarheid.
Deze begrippen zijn niet hetzelfde.
Gegarandeerde hersteltijd?
Wees voorzichtig met absolute garanties.
Recovery hangt soms af van factoren buiten de directe controle van de leverancier.
Vraag daarom precies wat contractueel wordt toegezegd en onder welke voorwaarden.
Vraag naar RTO in de praktijk
Een leverancier kan zeggen:
“We kunnen binnen vier uur herstellen.”
Vraag dan:
Is dat getest?
En:
Wat wordt precies binnen vier uur hersteld?
Eén server?
De volledige applicatie?
Alle gebruikers?
Alle vestigingen?
Maak verwachtingen concreet.
Vraag naar werkelijke testresultaten
Een volwassen disaster recovery-aanpak meet resultaten.
Bijvoorbeeld:
starttijd;
hersteltijd;
problemen;
afwijkingen;
en uiteindelijke beschikbaarheid.
Vraag hoe testresultaten worden vastgelegd.
Vraag hoe vaak getest wordt
Een recoveryplan dat jaren niet wordt getest kan sterk verouderd zijn.
Vraag daarom:
hoe vaak worden restores getest?
Hoe vaak wordt failover getest?
Hoe vaak wordt een complete DR-test uitgevoerd?
Wat gebeurt er na wijzigingen?
Automatische tests
Sommige platforms kunnen bepaalde herstelcontroles automatiseren.
Dat kan nuttig zijn.
Maar automatische technische controles vervangen niet altijd een volledige praktijktest.
Vraag wat er tijdens een DR-test gebeurt
Een goede test gaat verder dan:
“De back-up kon worden geopend.”
Je wilt bijvoorbeeld weten of:
servers starten;
databases beschikbaar zijn;
gebruikers kunnen inloggen;
applicaties functioneren;
netwerkverbindingen werken;
en integraties beschikbaar zijn.
Vraag naar ransomware recovery
Dit is een zeer belangrijke vraag.
Stel:
de productieomgeving is versleuteld;
beheeraccounts zijn gecompromitteerd;
en de aanvaller probeert back-ups te verwijderen.
Hoe herstellen jullie dan?
Een goede leverancier moet een duidelijk verhaal hebben over gescheiden en veilige recovery.
Immutable back-ups
Vraag of immutable back-ups onderdeel kunnen zijn van de strategie.
Daarmee kunnen gegevens gedurende een ingestelde periode tegen wijzigingen of verwijdering worden beschermd.
Gescheiden credentials
Vraag hoe toegang tot back-up- en recoveryomgevingen wordt gescheiden van normale productieaccounts.
Wanneer dezelfde beheercredentials overal toegang geven, kan één gecompromitteerd account grote gevolgen hebben.
Multi-factor authentication
Sterke authenticatie hoort eveneens bij de beveiliging van recoveryvoorzieningen.
Vraag hoe beheertoegang wordt beschermd.
Offline herstelkopie
Afhankelijk van risico en technologie kan een aanvullende offline of sterk gescheiden herstelkopie interessant zijn.
Vraag hoe de leverancier voorkomt dat één incident alle kopieën tegelijk raakt.
Vraag naar clean recovery
Na een cyberaanval wil je mogelijk niet simpelweg alle oude systemen opnieuw aanzetten.
Vraag daarom of de leverancier ervaring heeft met gecontroleerd herstel naar een betrouwbare omgeving.
Malwarecontrole tijdens recovery
Bij ransomware moet worden voorkomen dat geïnfecteerde data of systemen direct opnieuw worden geactiveerd.
Vraag hoe hersteldata wordt gecontroleerd.
Credentials resetten
Bij een ernstige securitybreuk kunnen:
wachtwoorden;
beheeraccounts;
serviceaccounts;
API-sleutels;
certificaten;
en andere secrets
moeten worden vervangen.
Een goede recoverystrategie houdt hiermee rekening.
Vraag waar je data wordt opgeslagen
Weet waar back-ups en replicadata staan.
Vraag bijvoorbeeld:
in welk datacenter;
in welk land;
in welke cloudregio;
en bij welke provider.
Dit kan relevant zijn voor beveiliging, compliance en bedrijfsbeleid.
Datacenterlocatie
Een tweede locatie heeft vooral waarde wanneer deze voldoende onafhankelijk is van de primaire omgeving.
Twee serverruimtes in hetzelfde gebouw beschermen bijvoorbeeld niet tegen ieder fysiek incident.
Geografische spreiding
Vraag hoe productie en recovery geografisch zijn gescheiden.
Dit kan relevant zijn bij:
brand;
overstroming;
regionale stroomuitval;
of andere locatiegebonden incidenten.
Data-encryptie
Vraag hoe gegevens worden versleuteld:
tijdens transport;
en tijdens opslag.
Vraag ook wie toegang heeft tot encryptiesleutels.
Privacy en compliance
Verwerkt de organisatie persoonsgegevens of andere gevoelige informatie?
Controleer dan hoe de leverancier omgaat met:
toegang;
logging;
subverwerkers;
dataopslag;
retentie;
en verwijdering.
Exitstrategie
Dit wordt vaak vergeten.
Wat gebeurt er wanneer je over drie jaar naar een andere disaster recovery-provider wilt?
Vraag:
Kunnen we onze data exporteren?
In welk formaat?
Hoe lang blijft data beschikbaar?
Hoe wordt deze daarna verwijderd?
Zijn hier extra kosten aan verbonden?
Vendor lock-in
Een technisch uitstekende oplossing kan toch nadelen hebben wanneer je vrijwel onmogelijk kunt overstappen.
Onderzoek daarom vooraf hoe afhankelijk je wordt van:
software;
cloudprovider;
proprietary formaten;
en specifieke dienstverlening.
Disaster recovery offerte aanvragen
Vraag bij voorkeur offertes op basis van dezelfde uitgangspunten.
Anders vergelijk je appels met peren.
Geef iedere leverancier dezelfde informatie
Bijvoorbeeld:
aantal servers;
aantal gebruikers;
hoeveelheid data;
cloudomgeving;
locaties;
kritieke applicaties;
RTO;
RPO;
huidige back-up;
en supportbehoefte.
Vraag om duidelijke scope
Een offerte moet beschrijven wat wel en niet is inbegrepen.
Bijvoorbeeld:
back-up;
replicatie;
cloudopslag;
monitoring;
restore;
failover;
testen;
documentatie;
support;
en consultancy.
Vraag wat niet wordt beschermd
Dit is misschien nog belangrijker.
Vraag letterlijk:
Welke onderdelen van onze IT-omgeving vallen buiten deze oplossing?
Zo ontdek je mogelijke gaten.
Vraag naar implementatie
Wie richt alles in?
Hoe lang duurt dit?
Is downtime nodig?
Welke werkzaamheden moet de eigen IT-afdeling uitvoeren?
Wordt bestaande data gemigreerd?
Vraag naar onboarding
Een professionele onboarding kan bestaan uit:
inventarisatie;
technische analyse;
ontwerp;
configuratie;
documentatie;
eerste replicatie;
en recovery-test.
Eerste recovery-test
Probeer af te spreken dat de oplossing niet als volledig operationeel wordt beschouwd voordat een eerste hersteltest succesvol is uitgevoerd.
Zo weet je dat de basis daadwerkelijk werkt.
Vergelijk niet alleen maandprijzen
De ene leverancier kan goedkoop lijken omdat alleen opslag wordt aangeboden.
Een andere prijs kan ook bevatten:
beheer;
monitoring;
tests;
support;
documentatie;
en begeleiding tijdens een calamiteit.
Vergelijk daarom de totale dienstverlening.
Eenmalige kosten
Vraag naar:
advies;
implementatie;
configuratie;
migratie;
documentatie;
en eerste test.
Terugkerende kosten
Vraag naar:
licenties;
opslag;
cloudresources;
monitoring;
beheer;
support;
en periodieke tests.
Kosten tijdens calamiteit
Een zeer belangrijke vraag:
Wat kost het wanneer we de disaster recovery-oplossing daadwerkelijk moeten gebruiken?
Zijn:
engineeruren;
extra cloudresources;
restorekosten;
en support
inbegrepen?
Of worden deze apart gefactureerd?
Kosten tijdens tests
Hetzelfde geldt voor geplande oefeningen.
Vraag of testuren en tijdelijke cloudcapaciteit onderdeel van het abonnement zijn.
Disaster recovery contract controleren
Let onder andere op:
contractduur;
opzegtermijn;
SLA;
supporttijden;
verantwoordelijkheden;
data-eigendom;
prijswijzigingen;
en exitvoorwaarden.
Verantwoordelijkheden vastleggen
Wie is verantwoordelijk voor:
monitoring;
back-ups;
updates;
tests;
documentatie;
en herstel?
Maak dit expliciet.
Shared responsibility
Vooral bij cloudomgevingen zijn verantwoordelijkheden verdeeld.
Een provider kan de fysieke infrastructuur beheren terwijl de organisatie zelf verantwoordelijk blijft voor:
data;
accounts;
configuraties;
of bepaalde back-ups.
Vraag de disaster recovery-specialist dit duidelijk uit te leggen.
Zoek een partner die begrijpelijk communiceert
Disaster recovery kan technisch worden.
Maar management moet begrijpen:
welke risico’s bestaan;
wat de oplossing doet;
en wat tijdens een incident gebeurt.
Een goede specialist kan complexe techniek daarom ook begrijpelijk uitleggen.
Pas op voor alleen technische verkooppraat
Veel termen gebruiken is niet hetzelfde als een goede oplossing.
Vraag steeds:
Wat betekent dit concreet voor onze organisatie?
Hoe snel kunnen wij weer werken?
Welke data kunnen we verliezen?
Wat gebeurt er tijdens ransomware?
Hoe hebben jullie dit getest?
Daarmee kom je snel tot de kern.
Rode vlag: “Uw back-up is uw disaster recovery”
Een back-up is belangrijk.
Maar vraag altijd hoe de volledige omgeving wordt hersteld.
Wie bouwt de infrastructuur opnieuw op?
Hoe lang duurt dat?
Hoe worden applicaties getest?
Rode vlag: geen RTO of RPO
Wanneer een leverancier deze onderwerpen volledig overslaat, ontbreekt een belangrijk gedeelte van de analyse.
Rode vlag: nooit testen
Een recovery-oplossing die nooit wordt getest biedt weinig zekerheid over de werkelijke hersteltijd.
Rode vlag: geen documentatie
Wanneer alleen één engineer weet hoe alles werkt, ontstaat afhankelijkheid van die persoon.
Rode vlag: dezelfde credentials overal
Productie, back-up en recovery volledig via dezelfde beheeraccounts toegankelijk maken kan extra risico creëren.
Rode vlag: onduidelijke verantwoordelijkheid
Tijdens een calamiteit is “we dachten dat jullie dat deden” het laatste wat je wilt horen.
Rode vlag: extreem lage prijs zonder duidelijke scope
Goedkoop kan prima zijn.
Maar controleer wat daadwerkelijk wordt geleverd.
Rode vlag: geen aandacht voor ransomware
Moderne disaster recovery moet rekening houden met cyberincidenten.
Rode vlag: alleen servers bekijken
Applicaties bestaan uit afhankelijkheden.
Een goede analyse kijkt daarom verder dan afzonderlijke servers.
Rode vlag: geen exitstrategie
Je moet weten hoe je later kunt overstappen.
Maak een shortlist
Na het eerste onderzoek kun je bijvoorbeeld drie geschikte partijen overhouden.
Vergelijk deze vervolgens op dezelfde criteria.
Criterium 1: technische expertise
Past de kennis bij jouw infrastructuur?
Criterium 2: disaster recovery-ervaring
Heeft de partij aantoonbare ervaring met echte recoveryvraagstukken?
Criterium 3: security
Hoe wordt de recoveryomgeving beschermd?
Criterium 4: testen
Hoe vaak en hoe uitgebreid wordt herstel getest?
Criterium 5: support
Wanneer is technische hulp beschikbaar?
Criterium 6: communicatie
Is duidelijk wie je tijdens een incident spreekt?
Criterium 7: schaalbaarheid
Kan de oplossing meegroeien?
Criterium 8: flexibiliteit
Kunnen workloads en beschermingsniveaus worden aangepast?
Criterium 9: transparantie
Zijn prijzen, verantwoordelijkheden en beperkingen duidelijk?
Criterium 10: vertrouwen
Disaster recovery is uiteindelijk een dienst waarop je tijdens een van de moeilijkste momenten moet kunnen vertrouwen.
Proof of concept
Bij grote of complexe omgevingen kan een proof of concept interessant zijn.
Daarbij test je de oplossing eerst op een beperkt aantal systemen.
Bijvoorbeeld:
één applicatie;
enkele virtuele machines;
of één kritieke workload.
Wat test je in een proof of concept?
Onder andere:
replicatie;
restore;
hersteltijd;
netwerk;
gebruiksgemak;
monitoring;
en support.
Daarmee krijg je praktijkervaring voordat je de volledige omgeving migreert.
Begin eventueel met kritieke systemen
Je hoeft niet altijd alles tegelijkertijd te implementeren.
Begin bijvoorbeeld met de vijf belangrijkste systemen.
Test deze.
Verbeter de procedure.
Breid daarna verder uit.
Bestaande disaster recovery leverancier vervangen
Heb je al een leverancier maar ben je niet tevreden?
Begin dan met een audit van de huidige situatie.
Controleer:
waar de back-ups staan;
welke systemen beschermd zijn;
hoeveel herstelpunten bestaan;
welke licenties worden gebruikt;
en welke documentatie beschikbaar is.
Stap niet over zonder herstelplan
Voorkom dat tijdens de migratie een periode ontstaat waarin onvoldoende bescherming bestaat.
Plan daarom:
oude omgeving;
nieuwe omgeving;
overlap;
validatie;
en uiteindelijke beëindiging
zorgvuldig.
Data migreren
Vraag hoe bestaande back-ups worden behandeld.
Moeten oude herstelpunten behouden blijven?
Kunnen deze worden gemigreerd?
Of blijft tijdelijk toegang tot de oude leverancier nodig?
Disaster recovery IT vinden via aanbesteding
Grotere organisaties kunnen een formele aanbesteding of RFP gebruiken.
Beschrijf daarin niet alleen technologie, maar vooral gewenste resultaten.
Bijvoorbeeld:
RTO;
RPO;
security;
testen;
rapportage;
support;
en compliance.
Vraag om scenario’s
Een goede manier om leveranciers te vergelijken is dezelfde scenario’s voor te leggen.
Bijvoorbeeld:
Scenario 1: server defect
Een belangrijke virtuele server valt volledig uit.
Wat gebeurt er?
Scenario 2: ransomware
Productie en meerdere accounts zijn gecompromitteerd.
Hoe wordt veilig hersteld?
Scenario 3: datacenter onbereikbaar
De primaire locatie is 24 uur niet beschikbaar.
Wat gebeurt er?
Scenario 4: database corrupt
De database blijkt al enkele uren beschadigd.
Welk herstelpunt wordt gebruikt?
Scenario 5: belangrijkste engineer afwezig
Kan recovery nog steeds worden uitgevoerd?
De antwoorden geven vaak meer inzicht dan een standaard verkooppresentatie.
Disaster recovery IT vinden: stappenplan
Stap 1: inventariseer de IT-omgeving
Maak duidelijk wat aanwezig is.
Stap 2: bepaal kritieke bedrijfsprocessen
Welke processen mogen nauwelijks uitvallen?
Stap 3: koppel systemen aan processen
Welke IT is daarvoor nodig?
Stap 4: bepaal RTO
Hoe snel moet ieder belangrijk systeem terug?
Stap 5: bepaal RPO
Hoeveel dataverlies is acceptabel?
Stap 6: beoordeel huidige back-ups
Wat is al geregeld?
Stap 7: bepaal ontbrekende onderdelen
Waar zitten de grootste risico’s?
Stap 8: zoek passende specialisten
Selecteer partijen met relevante technische ervaring.
Stap 9: controleer cases en expertise
Vraag naar vergelijkbare omgevingen.
Stap 10: bespreek ransomware
Vraag concreet hoe cyberrecovery werkt.
Stap 11: bespreek testen
Hoe wordt bewezen dat recovery werkt?
Stap 12: bespreek support
Wie helpt tijdens een calamiteit?
Stap 13: vraag meerdere voorstellen aan
Gebruik dezelfde uitgangspunten.
Stap 14: vergelijk scope
Wat is wel en niet inbegrepen?
Stap 15: vergelijk techniek
Past de architectuur bij RTO en RPO?
Stap 16: vergelijk security
Hoe worden back-ups en recovery beschermd?
Stap 17: vergelijk dienstverlening
Monitoring, beheer, support en tests.
Stap 18: controleer contracten
SLA, looptijd, verantwoordelijkheden en exit.
Stap 19: voer eventueel een proof of concept uit
Test de belangrijkste onderdelen.
Stap 20: voer een eerste recovery-test uit
Controleer vóór volledige ingebruikname of de oplossing daadwerkelijk werkt.
Checklist disaster recovery IT vinden
Gebruik onderstaande checklist bij het vergelijken van leveranciers.
Organisatie
Welke bedrijfsprocessen zijn kritiek?
Welke systemen ondersteunen deze processen?
Hoeveel downtime is acceptabel?
Hoeveel dataverlies is acceptabel?
Technologie
On-premises?
Cloud?
Hybride?
SaaS?
Microsoft 365?
Azure?
AWS?
Virtualisatie?
Leverancier
Ervaring met vergelijkbare omgevingen?
Relevante specialisten?
Duidelijk technisch team?
Goede bereikbaarheid?
Recovery
Duidelijke RTO?
Duidelijke RPO?
Recoveryvolgorde?
Applicatieafhankelijkheden?
Failover?
Failback?
Back-up
Meerdere kopieën?
Geografische scheiding?
Immutable mogelijkheden?
Offline of extra gescheiden kopie?
Security
MFA?
Gescheiden accounts?
Encryptie?
Logging?
Monitoring?
Clean recovery?
Ransomware
Hoe wordt een aanval afgehandeld?
Hoe wordt een veilige herstelkopie gekozen?
Hoe worden credentials vervangen?
Hoe wordt herinfectie voorkomen?
Testen
Restore-tests?
Applicatietests?
Volledige DR-tests?
Meetbare resultaten?
Rapportage?
Support
Kantooruren of 24/7?
Reactietijd?
Technische engineer beschikbaar?
Escalatieprocedure?
Documentatie
Recoveryplan?
Architectuur?
Contactgegevens?
Stappenplan?
Regelmatige updates?
Kosten
Implementatie?
Maandelijkse kosten?
Opslag?
Cloud?
Licenties?
Testkosten?
Recoverykosten?
Contract
SLA?
Contractduur?
Opzegtermijn?
Data-eigendom?
Exitstrategie?
Wanneer je deze punten duidelijk kunt beantwoorden, wordt het veel gemakkelijker om disaster recovery IT-leveranciers inhoudelijk te vergelijken.
Veelgestelde vragen over disaster recovery IT vinden
Waar kan ik disaster recovery IT vinden?
Disaster recovery-diensten worden aangeboden door onder andere gespecialiseerde DR-providers, MSP’s, IT-beheerbedrijven, cloudspecialisten en bepaalde cybersecuritybedrijven.
Hoe vind ik een goede disaster recovery specialist?
Kijk naar relevante technische ervaring, RTO/RPO-kennis, security, testprocedures, support en ervaring met vergelijkbare IT-omgevingen.
Is mijn huidige IT-beheerder geschikt?
Dat kan. Vraag wel concreet welke disaster recovery-diensten worden geleverd en hoe recovery wordt getest.
Wat moet ik aan een disaster recovery leverancier vragen?
Vraag minimaal naar RTO, RPO, back-ups, ransomware recovery, testprocedures, support, verantwoordelijkheden en kosten.
Wat is belangrijker: back-up of disaster recovery?
Beide zijn belangrijk. Back-up zorgt voor hersteldata, terwijl disaster recovery beschrijft en faciliteert hoe de volledige IT-dienstverlening wordt hersteld.
Moet een disaster recovery leverancier 24/7 bereikbaar zijn?
Dat hangt af van de bedrijfsvoering en gewenste hersteltijd. Voor organisaties die continu afhankelijk zijn van IT kan 24/7 technische ondersteuning belangrijk zijn.
Moet ik meerdere leveranciers vergelijken?
Dat is vaak verstandig, vooral bij grotere investeringen. Zorg wel dat iedere leverancier dezelfde uitgangspunten krijgt.
Hoe vergelijk ik disaster recovery offertes?
Vergelijk niet alleen prijs. Kijk ook naar beschermde systemen, RTO, RPO, opslag, security, support, tests, implementatie en recoverykosten.
Wat is DRaaS?
DRaaS staat voor Disaster Recovery as a Service. Hierbij wordt recovery-infrastructuur en eventueel aanvullende dienstverlening als dienst geleverd.
Is DRaaS geschikt voor kleine bedrijven?
Dat kan, afhankelijk van de IT-omgeving en bedrijfsimpact. Een volledig maatwerkplatform is echter niet voor iedere kleine organisatie noodzakelijk.
Kan disaster recovery volledig in de cloud?
Dat is voor veel workloads technisch mogelijk, maar de geschiktheid hangt af van infrastructuur, applicaties, netwerk en herstelvereisten.
Hoe weet ik of een leverancier recovery echt kan uitvoeren?
Vraag naar testprocedures, meetbare testresultaten, referentiecases en eventueel een proof of concept.
Moet ransomware onderdeel zijn van disaster recovery?
Cyberincidenten kunnen belangrijke herstelvoorzieningen noodzakelijk maken. Vraag daarom expliciet hoe de oplossing omgaat met gecompromitteerde systemen en back-ups.
Waarom zijn immutable back-ups interessant?
Ze kunnen helpen voorkomen dat hersteldata gedurende een ingestelde periode ongewenst wordt gewijzigd of verwijderd.
Is een lokale disaster recovery specialist beter?
Niet automatisch. Lokale aanwezigheid kan praktisch zijn, maar expertise, support en technische kwaliteit zijn belangrijker.
Hoeveel disaster recovery leveranciers moet ik vergelijken?
Er bestaat geen verplicht aantal. Een kleine shortlist van geschikte partijen kan voldoende zijn om oplossingen inhoudelijk te vergelijken.
Wat moet in een disaster recovery contract staan?
Onder andere scope, verantwoordelijkheden, SLA, support, kosten, data-eigendom, testafspraken en beëindigingsvoorwaarden moeten duidelijk zijn.
Moet ik eerst een disaster recovery scan laten uitvoeren?
Wanneer de huidige situatie of benodigde oplossing niet duidelijk is, kan een inventarisatie of scan een goede eerste stap zijn.
Wat is een rode vlag bij een disaster recovery leverancier?
Voorbeelden zijn geen aandacht voor RTO/RPO, nooit testen, onduidelijke verantwoordelijkheden, geen ransomwarestrategie of een oplossing die feitelijk alleen uit een eenvoudige back-up bestaat.
Kan ik eerst een gedeelte van mijn IT beschermen?
Ja. Je kunt beginnen met de meest kritieke systemen en de oplossing daarna gefaseerd uitbreiden.
Conclusie: disaster recovery IT vinden begint bij weten wat je werkelijk moet kunnen herstellen
Wie disaster recovery IT wil vinden, kan gemakkelijk beginnen met het vergelijken van leveranciers, software en prijzen.
Maar daarmee begin je eigenlijk aan de verkeerde kant.
Begin eerst bij je eigen organisatie.
Welke bedrijfsprocessen zijn kritisch?
Welke IT-systemen zijn daarvoor noodzakelijk?
Hoe lang mogen deze uitvallen?
Hoeveel recente gegevens mogen verloren gaan?
En wat gebeurt er wanneer niet één server, maar een groot gedeelte van de IT-omgeving wordt getroffen?
Met die informatie kun je veel gerichter naar een geschikte disaster recovery IT-partner zoeken.
Een goede specialist kijkt vervolgens verder dan alleen back-ups.
De partij onderzoekt:
systemen;
data;
afhankelijkheden;
netwerk;
identity;
cloud;
security;
RTO;
RPO;
en bedrijfsimpact.
Daarnaast moet duidelijk zijn hoe recovery daadwerkelijk wordt uitgevoerd.
Niet alleen op papier.
Maar in de praktijk.
Daarom zijn tests zo belangrijk.
Vraag een potentiële leverancier niet alleen:
“Hebben jullie disaster recovery?”
Vraag vooral:
Hoe bewijzen jullie dat onze omgeving na een ernstig incident daadwerkelijk binnen de afgesproken tijd kan worden hersteld?
Vraag ook wat gebeurt bij ransomware.
Waar staan de herstelkopieën?
Hoe zijn deze beschermd?
Welke accounts hebben toegang?
Hoe wordt een betrouwbare herstelversie geselecteerd?
En hoe voorkom je dat een besmette omgeving simpelweg opnieuw wordt gestart?
Vergelijk daarna meerdere oplossingen op dezelfde uitgangspunten.
Kijk naar:
techniek;
security;
testen;
support;
documentatie;
kosten;
contractvoorwaarden;
en ervaring.
Een goede disaster recovery IT-partner verkoopt uiteindelijk niet alleen opslagruimte of software.
De echte waarde zit in de zekerheid dat er vooraf is nagedacht over een ernstige verstoring en dat de herstelprocedure regelmatig wordt gecontroleerd.
Disaster recovery IT vinden betekent daarom vooral een partner en oplossing vinden die niet alleen beloven dat je data veilig staat, maar aantoonbaar kunnen laten zien hoe jouw organisatie haar kritieke IT na een calamiteit weer operationeel krijgt.