
Wat is het verschil tussen een hot site en een cold site bij disaster recovery?

Als IT-manager of operations directeur ken je de situatie: een kritiek systeem valt uit op een ongelegen moment. De vraag is niet óf dat ooit voorkomt, maar hoe snel je daarna weer operationeel bent. Een hot site is een volledig ingerichte, direct beschikbare uitwijklocatie waarmee je organisatie binnen minuten of uren weer kan draaien. Een cold site is een kale locatie met alleen de fysieke infrastructuur, zonder actieve systemen of data, waarbij herstel dagen tot weken kan duren. De keuze tussen beide hangt sterk af van hoe snel jouw organisatie weer up and running moet zijn na een verstoring en hoeveel budget er beschikbaar is voor bedrijfscontinuïteit.
Welke herstelstrategie past bij welk type organisatie?
De juiste herstelstrategie hangt af van hoe kritiek de digitale bedrijfsprocessen zijn, hoe groot de organisatie is en hoeveel uitvaltijd acceptabel is. Een organisatie die volledig afhankelijk is van realtime transacties of klantsystemen heeft een andere aanpak nodig dan een bedrijf waar een paar uur uitval geen directe omzetschade oplevert.
Globaal zijn er drie profielen te onderscheiden:
- Hoge kritikaliteit: Organisaties in financiële dienstverlening, logistiek of e-commerce waarbij elke minuut uitval direct invloed heeft op inkomsten of klanttevredenheid. Hier past een hot site of een cloudgebaseerde actief-actief oplossing.
- Gemiddelde kritikaliteit: Middelgrote organisaties met een mix van kritieke en minder kritieke systemen. Een warm site of hybride cloudstrategie biedt hier een goede balans tussen kosten en herstelsnelheid.
- Lagere kritikaliteit: Organisaties waarbij processen tijdelijk handmatig kunnen worden uitgevoerd of waarbij klanten een langere uitvaltijd accepteren. Een cold site of uitgebreide back-upstrategie kan hier volstaan.
Belangrijk is dat de herstelstrategie niet alleen op technische criteria wordt gebaseerd. Regelgeving zoals NIS2 stelt eisen aan de weerbaarheid van organisaties in bepaalde sectoren. Een goed doordachte strategie koppelt technische maatregelen aan bedrijfsdoelstellingen en compliance-eisen.
Wat is de rol van RTO en RPO bij de keuze tussen hot en cold site?
Twee begrippen zijn bepalend bij de keuze tussen een hot site en een cold site: RTO en RPO. RTO staat voor Recovery Time Objective en geeft aan hoe snel systemen weer beschikbaar moeten zijn na een verstoring. RPO staat voor Recovery Point Objective en geeft aan hoeveel dataverlies acceptabel is, uitgedrukt in tijd — bijvoorbeeld: mag de herstelde omgeving werken met data van vier uur geleden, of moet alles up-to-date zijn?
Een hot site is ontworpen voor een lage RTO en een lage RPO. Systemen draaien al of kunnen binnen minuten worden geactiveerd, en data wordt continu gesynchroniseerd. Een cold site heeft een hogere RTO en een hogere RPO: het opbouwen van de omgeving kost tijd, en data moet worden teruggezet vanuit back-ups die mogelijk al uren of dagen oud zijn.
De praktische vertaling is als volgt: als jouw organisatie een RTO van twee uur hanteert, is een cold site geen realistische optie. Als een RTO van 48 uur acceptabel is en dataverlies van een dag geen noemenswaardige gevolgen heeft, is een cold site een kostenefficiënte keuze. Het bepalen van RTO en RPO per applicatie of bedrijfsproces is dan ook de eerste stap in elke serieuze herstelplanning.
Hoeveel duurder is een hot site ten opzichte van een cold site?
Een hot site is aanzienlijk duurder dan een cold site, met kostenverschillen die kunnen oplopen tot een factor vijf of meer, afhankelijk van de omvang en complexiteit van de omgeving. De hogere kosten komen voort uit de continue beschikbaarheid van hardware, licenties, netwerkcapaciteit en onderhoud.
De kostencomponenten van een hot site omvatten onder andere:
- Aanschaf of huur van volledige hardwareinfrastructuur op de uitwijklocatie
- Continue softwarelicenties voor alle systemen die gespiegeld worden
- Replicatietechnologie voor realtime datasynchronisatie
- Beheer en monitoring van de uitwijklocatie
- Periodieke tests en onderhoud om de site operationeel te houden
Een cold site vraagt voornamelijk om huurkosten voor de locatie en basisinfrastructuur zoals stroom en netwerkaansluitingen. De hardware hoeft pas te worden aangeschaft of geactiveerd op het moment van een verstoring, wat de doorlopende kosten laag houdt maar de hersteltijd verlengt.
Voor veel middelgrote organisaties is de keuze voor een hot site financieel uitdagend. Cloudgebaseerde disaster recovery oplossingen bieden hier steeds vaker een praktisch alternatief dat de voordelen van een hot site combineert met lagere vaste kosten.
Wat is een warm site en hoe verhoudt die zich tot hot en cold?
Een warm site is een uitwijklocatie die gedeeltelijk is ingericht met hardware en basisinfrastructuur, maar waarbij systemen nog niet actief draaien en data niet realtime wordt gesynchroniseerd. Herstel via een warm site duurt doorgaans enkele uren tot een dag, wat het positioneert tussen de snelheid van een hot site en de lage kosten van een cold site.
Bij een warm site is de hardware al aanwezig en geconfigureerd, maar moeten systemen nog worden opgestart en moet data worden teruggezet vanuit recente back-ups. Dit maakt de hersteltijd korter dan bij een cold site, maar langer dan bij een hot site waar alles al operationeel is.
Voor veel organisaties is een warm site een pragmatische middenweg. De infrastructuurkosten zijn lager dan bij een hot site omdat er geen continue replicatie of actieve systemen nodig zijn, terwijl de herstelsnelheid acceptabel is voor processen met een RTO van enkele uren tot een dag. In de praktijk zien we dat organisaties met meerdere applicaties soms kiezen voor een combinatie: kritieke systemen via een hot of cloudgebaseerde oplossing, minder kritieke systemen via een warm site aanpak.
Hoe test je of je disaster recovery site echt werkt?
Een disaster recovery site werkt alleen als die regelmatig en realistisch wordt getest. Een plan dat nooit getest is, is geen plan maar een aanname. De meest effectieve manier om te testen is een volledige failover simulatie waarbij systemen daadwerkelijk worden overgezet naar de uitwijklocatie en medewerkers vanuit die omgeving werken.
Er zijn meerdere niveaus van testen, van eenvoudig naar uitgebreid:
- Documentatiecheck: Verifieer of procedures, contactlijsten en configuratiedocumenten actueel zijn.
- Tabletop oefening: Bespreek het herstelscenario met het team zonder systemen aan te raken, om gaten in het proces te identificeren.
- Technische test: Zet systemen over naar de uitwijklocatie zonder de productieomgeving te onderbreken, en controleer of data intact is en applicaties functioneren.
- Volledige failover test: Simuleer een uitval en herstel volledig via de uitwijklocatie, inclusief communicatie naar gebruikers en klanten.
Een veelgemaakte fout is dat organisaties alleen de technische kant testen en vergeten te controleren of medewerkers weten wat ze moeten doen. Een goede Minimum Viable Company aanpak helpt hierbij: door vooraf te bepalen welke processen, systemen en mensen minimaal operationeel moeten zijn, wordt de test concreter en relevanter.
Wanneer is een cloudgebaseerde DR-oplossing beter dan een fysieke site?
Een cloudgebaseerde disaster recovery oplossing is in veel situaties een goede keuze ten opzichte van een fysieke hot of cold site, vooral wanneer flexibiliteit, schaalbaarheid en kostenefficiëntie belangrijk zijn. Cloud DR maakt het mogelijk om alleen te betalen voor capaciteit die daadwerkelijk wordt gebruikt bij een verstoring, in plaats van continu hardware beschikbaar te houden.
Cloud DR heeft duidelijke voordelen ten opzichte van fysieke sites in de volgende situaties:
- De organisatie werkt al grotendeels in de cloud of met SaaS-applicaties
- De IT-omgeving groeit snel en fysieke capaciteitsplanning is moeilijk
- Er is geen budget of personeel voor het beheer van een eigen uitwijklocatie
- Geografische spreiding is gewenst zonder te investeren in meerdere datacenters
- Snelle schaalbaarheid bij een verstoring is een vereiste
Een fysieke site behoudt zijn waarde wanneer de organisatie werkt met on-premise systemen die moeilijk te virtualiseren zijn, wanneer datatransfer naar de cloud te traag is voor de vereiste RPO, of wanneer wet- en regelgeving beperkingen stelt aan de opslag van data buiten de eigen infrastructuur. In de praktijk kiezen steeds meer organisaties voor een hybride aanpak waarbij cloudgebaseerde DR wordt gecombineerd met lokale back-ups voor de meest kritieke systemen.
Hoe OpenSight helpt met disaster recovery en cyberweerbaarheid
Wij helpen organisaties om disaster recovery niet als een losstaand technisch project te benaderen, maar als een integraal onderdeel van hun digitale weerbaarheid. Dat betekent dat we samen met jouw organisatie kijken naar de werkelijke situatie, de kritieke processen en de herstelcapaciteit die echt nodig is. Concreet doen we dat door:
- Het bepalen van realistische RTO en RPO per applicatie en bedrijfsproces
- Het in kaart brengen van de Minimum Viable Company: welke systemen zijn minimaal nodig om operationeel te blijven?
- Het adviseren over de juiste combinatie van hot, warm, cold of cloudgebaseerde DR-oplossingen
- Het implementeren en beheren van technische oplossingen via ons Cyber Resilience Platform
- Het testen van herstelplannen zodat je weet dat ze echt werken wanneer je er gebruik van maakt
Bij OpenSight gaat het altijd over mensen, processen én technologie samen. Disaster recovery is daar geen uitzondering op. Wil je weten hoe jouw organisatie er nu voor staat en welke stappen de meeste impact hebben? Vraag een risk assessment aan en ontdek waar de grootste verbeterpunten liggen.
Related Articles
- Hoe weet je of je cyberverzekering ook incident response dekt?
- Waarom is communicatie tijdens een IT-storing net zo belangrijk als techniek?
- Hoe lang duurt herstel zonder een business continuity strategie?
- Wat is de rol van een IT-manager tijdens een grote systeemverstoring?
- Hoe weet je of je organisatie klaar is voor een onverwachte IT-uitval?



