Database en SQL
CRM
Data & BI
ERP & Business Processes

Wat is het verschil tussen failover en back-up?

Beschadigde serverrack naast identieke herstelde twin in minimalistische datacentergang met symmetrische belichting en koele grijsblauwe tinten.

Wat is het verschil tussen failover en back-up?

Failover en back-up zijn twee verschillende beveiligingslagen voor je data en systemen. Een failover zorgt ervoor dat je systeem automatisch blijft draaien bij een storing, terwijl een back-up een kopie van je data bewaart die je kunt terugzetten na dataverlies. Beide zijn onmisbaar, maar ze beschermen je tegen heel verschillende problemen. In dit artikel beantwoorden we de meest gestelde vragen over failover en back-up, zodat je weet welke oplossing jouw situatie vereist.

Wanneer heb je failover nodig en wanneer een back-up?

Je hebt failover nodig wanneer continuïteit de hoogste prioriteit heeft: als een paar minuten downtime al grote schade aanricht voor je klanten of bedrijfsprocessen. Een back-up is nodig wanneer je bescherming wilt tegen dataverlies, zoals bij een menselijke fout, een corrupte database of een ransomware-aanval. De meeste organisaties hebben beide nodig, maar om verschillende redenen.

Denk aan een webshop die 24 uur per dag bestellingen verwerkt. Als de databaseserver uitvalt, wil je dat een tweede server direct het werk overneemt. Dat is failover. Maar als een medewerker per ongeluk een tabel leeggooit, heb je aan die automatische overname niets. Dan heb je een back-up nodig om de situatie van gisteren terug te zetten. Beide scenario’s zijn realistisch en komen regelmatig voor.

Hoe werkt failover precies?

Failover is een mechanisme waarbij een secundair systeem automatisch de taken overneemt van een primair systeem zodra dat uitvalt. Dit gebeurt in de meeste gevallen binnen seconden tot enkele minuten, zonder dat gebruikers het merken. De secundaire omgeving draait parallel aan de primaire en ontvangt voortdurend een kopie van alle wijzigingen.

Bij databases zoals SQL Server of Azure SQL spreek je over technieken als Always On Availability Groups of geo-redundante replica’s. De primaire database schrijft elke transactie synchroon of asynchroon naar een replica. Bij een storing detecteert het systeem automatisch dat de primaire node niet meer bereikbaar is en promoveert de replica tot nieuwe primaire database.

Het verschil met een back-up is cruciaal: bij failover verlies je vrijwel geen data, want de replica is bijna altijd actueel. Bij een back-up herstel je altijd naar een moment in het verleden, wat betekent dat transacties na het laatste back-upmoment verloren kunnen gaan.

Hoe werkt een back-up en hoe snel kun je herstellen?

Een back-up is een momentopname van je data op een specifiek tijdstip, opgeslagen op een aparte locatie. Bij herstel laad je die opgeslagen kopie terug in je systeem. Hoe snel dat gaat, hangt af van de omvang van je database, de herstelstrategie en de locatie van de back-up.

Er zijn drie gangbare typen back-ups:

  • Volledige back-up: een complete kopie van de database, het meest tijdrovend om te maken en te herstellen.
  • Differentiële back-up: alleen de wijzigingen sinds de laatste volledige back-up, sneller dan een volledige back-up.
  • Transactie-logback-up: legt elke individuele transactie vast, waardoor je kunt herstellen tot op de minuut nauwkeurig.

In de praktijk kan herstel van een grote database uren duren. Dat is de reden dat een back-up geen vervanging is voor failover als je hoge beschikbaarheid nodig hebt. Een back-up beschermt je data, maar garandeert geen snelle hervatting van je dienstverlening.

Wat zijn de kosten van failover versus een back-up?

Failover is aanzienlijk duurder dan een back-up, omdat je in feite twee volledige omgevingen draait die permanent gesynchroniseerd worden. Een back-up vereist alleen opslagcapaciteit en een herstelplan, wat relatief goedkoop is. De kostenverhouding hangt sterk af van de schaal en complexiteit van je omgeving.

Voor failover reken je op extra serverkosten, licenties voor de replica-omgeving en de beheertijd om synchronisatie en automatische detectie goed in te richten. In een cloudomgeving zoals Azure zijn deze kosten transparanter en schaalbaar, maar ze zijn er altijd.

Een back-upoplossing kost relatief weinig in opslag, maar de echte kosten zitten in de hersteltijd. Als je systeem uren of dagen uitstaat terwijl je herstelt, zijn de indirecte kosten al snel groter dan de investering in een goede failoveroplossing zou zijn geweest. De juiste keuze hangt dus af van wat downtime jouw organisatie per uur kost.

Kunnen failover en back-up elkaar vervangen?

Nee, failover en back-up kunnen elkaar niet vervangen. Ze beschermen tegen fundamenteel verschillende risico’s en vullen elkaar aan. Failover beschermt tegen hardwarestoringen en infrastructuuruitval. Een back-up beschermt tegen dataverlies door menselijke fouten, softwarebugs of kwaadaardige aanvallen zoals ransomware.

Een failoverconfiguratie repliceert elke wijziging naar de secundaire omgeving, inclusief fouten. Als iemand per ongeluk een tabel verwijdert, is die fout binnen seconden ook aanwezig op de replica. Je failover helpt je dan niet, want beide omgevingen bevatten dezelfde fout. Alleen een back-up van voor het incident kan de situatie herstellen.

Omgekeerd biedt een back-up geen continuïteit. Als je server crasht en je hebt alleen een back-up, ben je afhankelijk van hersteltijd die uren kan duren. Een organisatie met strenge beschikbaarheidseisen kan dat niet accepteren. De conclusie is simpel: een robuuste datastrategie bevat altijd beide lagen.

Welke oplossing past bij jouw organisatie?

De keuze hangt af van twee factoren: hoeveel downtime je kunt accepteren (de Recovery Time Objective, RTO) en hoeveel dataverlies je kunt tolereren (de Recovery Point Objective, RPO). Hoe lager beide waarden, hoe meer je moet investeren in een gecombineerde oplossing met failover én frequente back-ups.

Een kleine organisatie met een interne applicatie die niet bedrijfskritisch is, kan toe met dagelijkse back-ups en een herstelplan. Een organisatie die financiële transacties verwerkt of klantdata realtime bijhoudt, heeft vrijwel altijd een failoveroplossing nodig naast een back-upstrategie.

Stel jezelf de volgende vragen:

  • Wat kost een uur downtime mijn organisatie?
  • Hoeveel data mag ik maximaal verliezen bij een incident?
  • Heb ik wettelijke verplichtingen rondom dataveiligheid en beschikbaarheid?
  • Hoe snel moet mijn systeem weer operationeel zijn na een storing?

De antwoorden op deze vragen bepalen welke combinatie van maatregelen logisch is voor jouw situatie.

Hoe wij helpen met failover en databescherming

Wij bij Brander Company helpen organisaties om hun databaseomgeving zo in te richten dat zowel continuïteit als databescherming geborgd zijn. Of je nu werkt met SQL Server, Azure SQL, Oracle of PostgreSQL, wij beoordelen jouw huidige situatie en adviseren een strategie die past bij jouw RTO en RPO.

Wat wij voor jou doen:

  • Inrichten en testen van failoverconfiguraties zoals Always On Availability Groups of Azure geo-redundantie
  • Opzetten van een gelaagde back-upstrategie met volledige, differentiële en transactie-logback-ups
  • Continu monitoren van je databaseomgeving op prestaties en beschikbaarheid van databases, 24/7
  • Proactief ingrijpen zodra problemen dreigen, voordat ze impact hebben op jouw processen
  • Heldere documentatie en herstelplannen zodat je altijd weet wat er gebeurt

Wil je weten hoe jouw huidige omgeving scoort op beschikbaarheid en databescherming? Neem contact met ons op voor een vrijblijvend gesprek.

Frequently Asked Questions

Wat is een goede RTO en RPO voor een gemiddeld bedrijf?

Er bestaat geen universele standaard, maar als vuistregel geldt: een RTO van minder dan 4 uur en een RPO van minder dan 1 uur worden in veel sectoren als acceptabel beschouwd voor bedrijfskritische systemen. Voor financiële instellingen of e-commerceplatforms liggen die waarden vaak veel lager, soms onder de minuut. Begin met het berekenen wat een uur downtime jouw organisatie kost, dan wordt snel duidelijk welke investering gerechtvaardigd is.

Hoe vaak moet ik mijn back-ups testen om zeker te zijn dat ze werken?

Een back-up die nooit getest is, is geen betrouwbare back-up. Voer minimaal eens per kwartaal een hersteltest uit waarbij je daadwerkelijk data terugzet in een testomgeving en controleert of alles correct functioneert. Voor kritieke systemen is maandelijks of zelfs wekelijks testen aan te raden. Veel organisaties ontdekken pas tijdens een echte crisis dat hun back-ups corrupt of onvolledig zijn, wat dan precies het moment is waarop je dat niet wilt ontdekken.

Beschermt failover mij ook tegen ransomware?

Nee, failover biedt geen bescherming tegen ransomware. Omdat een failoverconfiguratie alle wijzigingen in real-time repliceert naar de secundaire omgeving, wordt ook de versleuteling door ransomware direct doorgezet naar de replica. Voor bescherming tegen ransomware heb je back-ups nodig die op een geïsoleerde, niet-direct-gekoppelde locatie worden bewaard, bij voorkeur met immutable storage zodat de back-ups zelf niet overschreven of versleuteld kunnen worden.

Wat is het verschil tussen een warme, koude en hete failover?

Bij een hete failover (hot standby) draait de secundaire omgeving volledig gesynchroniseerd en kan overname binnen seconden plaatsvinden, zonder dataverlies. Bij een warme failover (warm standby) is de replica actief maar minder frequent gesynchroniseerd, waardoor overname enkele minuten duurt en beperkt dataverlies mogelijk is. Een koude failover (cold standby) betekent dat de secundaire omgeving uitstaat en pas opgestart moet worden bij een storing, wat de goedkoopste maar ook de langzaamste optie is met de meeste kans op dataverlies.

Kan ik in de cloud goedkoper een failoveroplossing opzetten dan on-premises?

In veel gevallen wel, omdat cloudproviders zoals Azure, AWS en Google Cloud ingebouwde geo-redundantie en beheerde failoverservices aanbieden zonder dat je zelf hardware hoeft aan te schaffen of te beheren. Je betaalt op basis van gebruik, wat de instapdrempel verlaagt. Het nadeel is dat de kosten op lange termijn kunnen oplopen bij hoge datavolumes of veel transacties, dus een goede kostenanalyse vooraf blijft essentieel.

Hoe lang moet ik mijn back-ups bewaren?

De bewaartermijn hangt af van wettelijke verplichtingen, bedrijfsbeleid en het type data. Voor financiële en medische data gelden in Nederland vaak wettelijke minimumtermijnen van zeven jaar of langer. Technisch gezien is een gelaagde aanpak verstandig: dagelijkse back-ups bewaar je één tot vier weken, wekelijkse back-ups één tot drie maanden, en maandelijkse back-ups minimaal één jaar. Houd er rekening mee dat langere bewaartermijnen ook hogere opslagkosten met zich meebrengen.

Wat moet er minimaal in een herstelplan staan?

Een goed herstelplan beschrijft stap voor stap wie wat doet bij een incident, inclusief contactpersonen, verantwoordelijkheden en escalatieprocedures. Verder bevat het de exacte technische stappen voor het terugzetten van back-ups of activeren van failover, de locatie van back-upbestanden en toegangsgegevens, en de criteria om te bepalen wanneer een situatie als 'hersteld' wordt beschouwd. Zorg er ook voor dat het plan offline beschikbaar is, want als je systemen down zijn, heb je geen toegang tot een digitaal document dat alleen in die systemen staat.

Related Articles