Uit de praktijk

Noodbedrijf en disaster recovery: welk beschermingsniveau loont?

Back-up, lokale hoge beschikbaarheid of een tweede locatie? Een fictief ERP toont foutdomeinen, RPO/RTO-grenzen en open kosten over drie en vijf jaar.

Infrastructuur
DAXS-logo boven een back-upsymbool en twee afzonderlijke locatiesymbolen.

Het juiste beschermingsniveau hangt af van de uitval die een bedrijf moet kunnen doorstaan. Een back-up biedt een herstelbare gegevensstand. Lokale hoge beschikbaarheid kan een hoststoring opvangen. Een tweede locatie breidt de bescherming buiten het oorspronkelijke foutdomein uit, maar vraagt eigen capaciteit, netwerken en geoefende omschakeling. Geen van deze routes vervangt de functionele acceptatie van de applicatie.

De hersteltest en het verschil tussen Proxmox HA en back-up zijn al aparte onderwerpen. Hier kiezen we welke combinatie van back-up, lokale vervanging en geografisch gescheiden noodbedrijf past bij een dienst en een foutdomein. Ook het openbare platformoverzicht vervangt deze applicatiegerichte benadering niet.

Bepaal eerst het bedrijfsproces en twee tijdsdoelen

Ons uitdrukkelijk fictieve voorbeeld is een ERP met applicatie-VM, database en factuurbestanden. Bij uitval van de hele locatie wil de afdeling binnen vier uur weer orders verwerken en maximaal 15 minuten consistente bedrijfsgegevens verliezen. Dit zijn doelen voor RTO en RPO, geen toezegging van DAXS of gemeten waarden. Een enkele hoststoring kan een korter doel hebben; een per ongeluk verwijderde transactie vraagt juist een ouder, ongewijzigd herstelpunt.

De business-impactanalyse moet hostuitval, locatie-uitval en beschadigde of verwijderde gegevens apart beoordelen. Een dienst is pas terug als aanmelden, een databasehandeling en de bijbehorende bijlage in noodbedrijf werken. Stroom, locatienetwerk, DNS, identiteit, sleutels en externe koppelingen zijn afhankelijkheden. Als een onderdeel ontbreekt, levert een gestarte vervangende server nog geen bruikbare bedrijfsvoering.

Drie beschermingsniveaus met verschillende grenzen

Bescherming voor hetzelfde fictieve ERP, steeds met aparte back-up
Niveau Wat het kan bieden Wat nog openstaat
A · Back-up en herstel Aparte back-ups maken terugkeer naar een gecontroleerde gegevensstand mogelijk; de applicatie wordt hersteld zodra een doelsysteem beschikbaar is. Vervangende capaciteit, hersteltijd en functionele consistentie bepalen de RTO. Bij locatieverlies is zonder gereedstaande herstelplek geen betrouwbare vieruurstoezegging mogelijk.
B · Lokale redundantie plus back-up Meerdere hosts met passend ontworpen opslag, quorum en netwerk kunnen na een hoststoring een VM op andere middelen starten. Gedeelde stroom, brandcompartimenten of locatietoegang blijven een foutdomein. Verwijderingen of beschadigingen kunnen worden gerepliceerd; aparte back-up blijft nodig.
C · Tweede locatie plus back-up Geografisch gescheiden, voorbereide noodcapaciteit met gerepliceerde applicatiegegevens kan locatieverlies opvangen, mits omschakeling en bedrijfsproces zijn geoefend. Replicatieachterstand, gedeelde identiteitsdiensten, verbindingen, sleutels en mislukte failover kunnen het doel van 15 minuten/vier uur onhaalbaar maken. Ook hier zijn aparte back-ups nodig.

Lokale HA kan dus een antwoord zijn op een hoststoring, maar biedt niet automatisch disaster recovery voor de hele locatie. Microsoft onderscheidt redundantie en replicatie nadrukkelijk van back-up: een gerepliceerde fout of verwijdering blijft een fout. AWS beschrijft back-up/restore, pilot light, warm standby en actieve meerlocatiemodellen als strategieën met toenemende inspanning. Deze cloudpatronen bieden een beslislogica, geen universele RPO/RTO-waarden voor het hier veronderstelde eigen ERP.

Gelijkwaardige scope: een open drie- en vijfjaarsberekening

Elk niveau vergelijkt dezelfde productie-ERP-dienst en hetzelfde aparte basisprogramma voor back-up. De bestaande productieomgeving is daarom in geen enkele optie meegerekend. Eenmalig zijn 24 persoonuren nodig voor back-uprunbook en testbasis; jaarlijks veronderstellen we 3.600 € voor externe back-up/opslag, 12 × 4 persoonuren beheer en twee hersteloefeningen van elk 16 persoonuren. Het vrij aangenomen integrale tarief is 80 € per persoonuur: eenmalig 1.920 €, jaarlijks 3.600 + (48 + 32) × 80 = 10.000 €. Dit zijn geen leveranciersprijzen.

Niveau B voegt eenmalig 60 persoonuren toe voor ontwerp en acceptatie van hosts/opslag/netwerk, en jaarlijks 7.800 € aan fictieve extra lokale capaciteit inclusief energie en support, 12 × 4 extra beheeruren en twee HA-oefeningen van elk acht extra persoonuren. Niveau C voegt in plaats daarvan eenmalig 96 persoonuren toe voor locatie-, data- en omschakelontwerp, en jaarlijks 18.000 € voor voorbereide noodcapaciteit en netwerk, 3.600 € voor gegevensoverdracht, 12 × 8 extra beheeruren en twee locatieoefeningen van elk 24 extra persoonuren. Oefenuren zijn teamtotalen; de gezamenlijke back-upbasis telt per optie maar eenmaal mee.

Gelijke ERP- en back-upscope, ander aanvullend beschermingsdomein
Niveau Eenmalig Jaarlijks 3 jaar 5 jaar
A · Back-up/herstel 24 × 80 = 1.920 € 10.000 € basis 31.920 € 51.920 €
B · Lokale redundantie 1.920 + 60 × 80 = 6.720 € 10.000 + 7.800 + 3.840 + 1.280 = 22.920 € 75.480 € 121.320 €
C · Tweede locatie 1.920 + 96 × 80 = 9.600 € 10.000 + 18.000 + 3.600 + 7.680 + 3.840 = 43.120 € 138.960 € 225.200 €

Gevoeligheid: Kost de voorbereide tweede-locatiecapaciteit 500 € per maand meer, dan stijgt niveau C met 6.000 € per jaar: naar 156.960 € over drie of 255.200 € over vijf jaar. Voeg vóór aanschaf reserveonderdelen, belastingen, echte verbindings- en locatieoffertes, licentierechten, beheer buiten de aangenomen uren en kosten van werkelijke uitval toe. Geen optie belooft besparing of gegarandeerd herstel.

Beslis op basis van de test

Voor het veronderstelde doel van vier uur/15 minuten bij locatie-uitval volstaan A en B niet zelfstandig zolang geen andere bruikbare plek met data, identiteit en netwerktoegang klaarstaat. C is slechts een kandidaat: het team moet replicatiestand, database-bestandsconsistentie, toegang, omschakelbesluit, capaciteit onder belasting en terugkeer in een echte testperiode meten. Als de afdeling langer noodbedrijf met handmatige orderinname accepteert, kan een goedkopere route volstaan. Dat moet expliciet worden besloten, vastgelegd en geoefend.

DAXS kan de dienst en afhankelijkheden in kaart brengen, minimaal bruikbaar noodbedrijf vaststellen en de drie opties met echte offertes en restore-/failoverresultaten vergelijkbaar maken. Neem contact op met DAXS.

Bronnen: Microsoft Learn: redundantie, replicatie en back-up · AWS Well-Architected: disaster-recoverystrategieën · Proxmox VE: HA- en back-upfuncties.