Architectuur van Veeam Backup and Replication

De architectuur van Veeam Backup & Replication bestaat uit een besturingslaag, transportcomponenten en opslagdoelen. Door deze functies bewust te scheiden, kan een omgeving groeien zonder dat één server tegelijk planning, dataverplaatsing en langdurige bewaring moet dragen. De juiste indeling hangt af van workloadvolume, veranderingssnelheid, back-upvenster, hersteldoelen en storingsdomeinen.

Wie eerst een overzicht van Veeam Backup and Replication wil, kan de hoofdpagina gebruiken als startpunt. In deze handleiding gaat het uitsluitend om de technische samenhang en de ontwerpbeslissingen achter een beheersbare installatie.

De back-upserver als regisseur

De Veeam-back-upserver bewaart configuratie, plant taken en coördineert componenten. Hij hoeft niet alle back-updata zelf te verwerken. In een kleine proefomgeving kunnen meerdere rollen samenkomen, maar in productie leidt een gescheiden ontwerp meestal tot duidelijkere capaciteit, onderhoud en beveiliging. Beperk interactieve toegang en geef beheerders alleen de rechten die bij hun taak horen.

De configuratiedatabase bevat informatie over jobs, infrastructuur en sessies. Zij is niet hetzelfde als de repository met herstelpunten. Bescherm de configuratie daarom afzonderlijk en leg vast hoe een nieuwe managementserver toegang krijgt tot bestaande repositories. Een herstelplan dat alleen VM-back-ups noemt, maar de beheerlaag vergeet, maakt een calamiteit onnodig traag.

Proxies verwerken het dataverkeer

Een proxy haalt gegevens bij de bron op, verwerkt blokken en stuurt de back-upstroom naar een repository. Het gekozen transportpad beïnvloedt snelheid en belasting. Plaats proxies dicht genoeg bij bron en netwerk, reserveer voldoende CPU en geheugen en voorkom dat alle taken op hetzelfde moment om dezelfde verbinding concurreren.

Meer proxies betekenen niet automatisch hogere prestaties. De bronopslag, repository, netwerkroute en het aantal gelijktijdige taken vormen samen één keten. Meet waar wachttijd ontstaat voordat u capaciteit toevoegt. Een proxy die grotendeels idle is terwijl een repository de schrijfsnelheid begrenst, lost met extra instanties niets op.

Repositories bepalen de herstelbasis

De repository bewaart back-upbestanden en metadata. Selecteer opslag niet alleen op prijs per terabyte. Kijk naar sequentiële schrijfsnelheid, random leesgedrag bij granulair herstel, foutdomein, beheerrechten, retentie en de mogelijkheid om gegevens onveranderlijk te maken. Houd ook rekening met synthetische bewerkingen en periodieke gezondheidscontroles.

Een hardened Linux repository kan de blootstelling verkleinen door beperkte services en immutable herstelpunten. Onveranderlijk betekent echter niet onkwetsbaar. Fysieke toegang, firmware, rootbeheer, netwerkpaden en retentie-instellingen blijven onderdeel van het dreigingsmodel. Gebruik gescheiden credentials en laat de repository niet vertrouwen op dezelfde beheeridentiteit als de productieomgeving.

Schaalbare opslaglagen

Een Scale-out Backup Repository groepeert meerdere performance extents tot één logische opslagpool. Dat vereenvoudigt taaktoewijzing en capaciteitsgroei. Plaats extents met vergelijkbare eigenschappen in dezelfde operationele klasse en begrijp wat er gebeurt wanneer één extent tijdelijk niet beschikbaar is.

Capacity tier en archive tier kunnen gegevens naar objectopslag verplaatsen volgens beleid. Bepaal vooraf welke herstelacties extra downloadtijd of kosten veroorzaken. Objectopslag is geen excuus om lokale capaciteit zonder marge te plannen. Maak groeiprognoses voor volledige back-ups, incrementele wijzigingen, retentie en tijdelijke merge-operaties.

Mount-, gateway- en transportrollen

Bij herstel kunnen aanvullende services nodig zijn om back-upinhoud te publiceren of objectopslag te bereiken. Plaats gateway- en mountfuncties op systemen met passende netwerktoegang en capaciteit. Documenteer firewallroutes in beide richtingen en test naamresolutie, certificaten en tijdsynchronisatie voordat een noodsituatie ontstaat.

De snelste herstelroute is vaak niet gelijk aan het dagelijkse back-uppad. Instant Recovery vraagt andere I/O-eigenschappen dan het wegschrijven van incrementele blokken. Meet daarom afzonderlijk hoe lang inventarisatie, mount, opstart en uiteindelijke migratie duren.

Ontwerp voor storingsdomeinen

Plaats niet alle beheer-, proxy- en opslagrollen in hetzelfde cluster dat ze moeten beschermen. Een storing in virtualisatie, identiteit of netwerk kan anders zowel productie als herstelpad uitschakelen. Voorzie een minimale beheerroute die onafhankelijk genoeg is om repositories te benaderen en kritieke workloads terug te zetten.

Leg per component eigenaar, configuratiebron, afhankelijkheden en herstelvolgorde vast. Neem DNS, tijd, certificaten, database, encryptiesleutels en serviceaccounts mee. Test een gecontroleerde herbouw van de beheerlaag en bevestig dat bestaande herstelpunten daarna zichtbaar en bruikbaar zijn.

Capaciteit op basis van meetgegevens

Bereken repositoryruimte uit gebruikte brondata, dagelijkse wijziging, compressie, retentie en volledige back-upfrequentie. Voeg marge toe voor groei, onderhoud en onverwachte pieken. Voor proxies zijn gelijktijdige taken, datavolume en transportmodus relevanter dan alleen het totale aantal virtuele machines.

Een architectuur is af wanneer zij niet alleen vandaag snel genoeg is, maar ook uitlegbaar blijft. Gebruik een diagram met componenten, vertrouwensgrenzen en datastromen. Koppel daarna iedere technische keuze aan RPO, RTO, beveiliging of operationele eenvoud. Zo kan een volgende beheerder het ontwerp beoordelen zonder verborgen aannames.