Det rette beskyttelsesniveau afhænger af det nedbrud, virksomheden skal kunne klare. Backup giver en datatilstand, der kan gendannes. Lokal høj tilgængelighed kan afbøde en værtsfejl. Et andet sted udvider beskyttelsen ud over det oprindelige fejldomæne, men kræver egen kapacitet, netværk og øvet omskiftning. Ingen løsning erstatter den forretningsmæssige accept af applikationen.
Både gendannelsestesten og forskellen mellem Proxmox HA og backup er allerede selvstændige emner. Her vælger vi den kombination af backup, lokal erstatning og geografisk adskilt nøddrift, der passer til en tjeneste og et fejldomæne. Den offentlige platformoversigt erstatter heller ikke dette applikationsperspektiv.
Fastlæg først forretningsprocessen og to tidsmål
Vores udtrykkeligt fiktive eksempel er et ERP med applikations-VM, database og fakturafiler. Ved tab af hele driftsstedet vil fagafdelingen behandle ordrer igen inden fire timer og højst miste 15 minutters konsistente forretningsdata. Det er mål for RTO og RPO, ikke et DAXS-løfte eller målte værdier. En enkelt værtsfejl kan have et kortere mål; en fejlagtigt slettet transaktion kræver derimod et ældre, uændret gendannelsespunkt.
Forretningskonsekvensanalysen skal derfor vurdere værtsfejl, tab af driftssted og beskadigede eller slettede data særskilt. Tjenesten er først tilbage, når login, databasehandling og tilhørende filvedhæftning virker i nøddrift. Strøm, lokalt netværk, DNS, identitet, nøgler og eksterne grænseflader er afhængigheder. Mangler én del, giver en startet erstatningsserver endnu ikke brugbar drift.
Tre beskyttelsesniveauer med forskellige grænser
| Niveau | Hvad det kan levere | Hvad der stadig mangler |
|---|---|---|
| A · Backup og gendannelse | Separate backups gør det muligt at vende tilbage til en kontrolleret datatilstand; applikationen gendannes, når et målsystem er til rådighed. | Erstatningskapacitet, gendannelsestid og forretningsmæssig konsistens bestemmer RTO. Uden et klargjort mål efter tab af stedet kan fire timer ikke loves pålideligt. |
| B · Lokal redundans plus backup | Flere værter med korrekt dimensioneret lager, quorum og netværk kan starte en VM på andre ressourcer efter en værtsfejl. | Fælles strøm, brandsektion eller adgang til stedet er stadig et fejldomæne. Slettede eller beskadigede data kan replikeres; separat backup er fortsat nødvendig. |
| C · Andet driftssted plus backup | Geografisk adskilt, forberedt nødkapacitet med replikerede applikationsdata kan dække tab af stedet, hvis omskiftning og forretningsproces er øvet. | Replikeringsforsinkelse, fælles identitetstjenester, forbindelser, nøgler og fejl ved failover kan betyde, at målet på 15 minutter/fire timer ikke nås. Her kræves også separate backups. |
Lokal HA kan dermed håndtere en værtsfejl, men giver ikke automatisk disaster recovery for hele stedet. Microsoft skelner udtrykkeligt mellem redundans og replikering på den ene side og backup på den anden: en replikeret fejl eller sletning er stadig en fejl. AWS beskriver backup/restore, pilot light, warm standby og aktive modeller på flere steder med stigende indsats. Disse cloudmønstre er beslutningslogik, ikke generelle RPO/RTO-værdier for det antagne eget ERP.
Samme omfang: en åben tre- og femårsberegning
Hvert niveau sammenligner den samme ERP-tjeneste i produktion og det samme separate basisprogram for backup. Den eksisterende produktionsplatform indgår derfor ikke i nogen variant. Backuprunbook og testgrundlag kræver én gang 24 persontimer; årligt antages 3.600 € til ekstern backup/lager, 12 × 4 persontimers drift og to gendannelsesøvelser à 16 persontimer. Den frit antagne fulde timesats er 80 € pr. persontime: én gang 1.920 €, årligt 3.600 + (48 + 32) × 80 = 10.000 €. Det er ikke leverandørpriser.
Niveau B tilføjer én gang 60 persontimer til design og accept af værter/lager/netværk og årligt illustrerende 7.800 € ekstra lokal kapacitet inklusive energi og support, 12 × 4 yderligere driftstimer og to HA-øvelser à otte ekstra persontimer. C tilføjer i stedet én gang 96 persontimer til sted-, data- og omskiftningsdesign og årligt 18.000 € forberedt nødkapacitet og netværk, 3.600 € dataoverførsel, 12 × 8 ekstra driftstimer og to stedøvelser à 24 ekstra persontimer. Øvelsestimer er summer for hele holdet; den fælles backupbasis tælles kun én gang pr. variant.
| Niveau | Engangsudgift | Årligt | 3 år | 5 år |
|---|---|---|---|---|
| A · Backup/gendannelse | 24 × 80 = 1.920 € | 10.000 € basis | 31.920 € | 51.920 € |
| B · Lokal redundans | 1.920 + 60 × 80 = 6.720 € | 10.000 + 7.800 + 3.840 + 1.280 = 22.920 € | 75.480 € | 121.320 € |
| C · Andet driftssted | 1.920 + 96 × 80 = 9.600 € | 10.000 + 18.000 + 3.600 + 7.680 + 3.840 = 43.120 € | 138.960 € | 225.200 € |
Følsomhed: Koster den forberedte kapacitet på andet sted 500 € mere om måneden, stiger C med 6.000 € årligt: til 156.960 € over tre eller 255.200 € over fem år. Før indkøb skal reservedele, skatter, faktiske tilbud på forbindelser og steder, licensrettigheder, drift ud over de antagne timer og omkostninger ved et reelt nedbrud medregnes. Ingen variant lover besparelser eller garanteret genstart.
Træf beslutningen gennem testen
For det antagne mål på fire timer/15 minutter ved tab af driftssted kan A og B ikke stå alene, før et andet brugbart sted med data, identitet og netadgang er klar. C er kun en kandidat: holdet skal måle replikering, database-/filkonsistens, adgang, omskiftningsbeslutning, kapacitet under belastning og tilbagevenden i et reelt testvindue. Accepterer fagafdelingen længere nøddrift med manuel ordreoptagelse, kan en billigere vej være tilstrækkelig. Det skal besluttes udtrykkeligt, dokumenteres og øves.
DAXS kan kortlægge tjenesten og afhængighederne, definere den mindste forretningsmæssigt brugbare nøddrift og sammenligne tre varianter med faktiske tilbud og restore-/failoverresultater. Kontakt DAXS.
Kilder: Microsoft Learn: redundans, replikering og backup · AWS Well-Architected: disaster-recoverystrategier · Proxmox VE: HA- og backupfunktioner.
