Azure Site Recovery beschermt nu ook fysieke servers en VMware, zonder migratie naar de cloud

Microsoft maakt Azure Site Recovery sinds half oktober beschikbaar voor fysieke servers en VMware-machines die via Azure Arc zijn aangesloten. Daarmee krijgt apparatuur die nooit naar de cloud verhuist alsnog een herstelplan in Azure, zonder dat je ze migreert.

Veel organisaties hebben nog altijd apparatuur draaien die nooit naar de cloud is verhuisd. Een fysieke server in een serverruimte die een specifiek pakket aanstuurt, een VMware-cluster dat de afgelopen jaren is afgeschreven, of een systeem dat om contractuele of technische redenen simpelweg op locatie moet blijven. Voor die machines was een goed uitgewerkt rampenherstelplan tot voor kort omslachtig: een losse DR-site optuigen, dure replicatiesoftware inrichten, of alsnog een migratietraject starten dat niemand eigenlijk wilde.

Op 14 oktober kondigde Microsoft aan dat Azure Site Recovery algemeen beschikbaar is voor Windows-machines die via Azure Arc zijn aangesloten, zowel VMware-virtuele machines als fysieke servers. Dat is meer dan een technische voetnoot. Het betekent dat apparatuur die op locatie blijft staan, alsnog een cloudgebaseerd uitwijkplan kan krijgen, met dezelfde beheerlaag die je waarschijnlijk al voor andere systemen gebruikt.

Wat er op 14 oktober precies veranderde

Azure Site Recovery bestaat al jaren en repliceert virtuele machines naar Azure, zodat je bij een storing op de oorspronkelijke locatie kunt failoveren naar een kopie in de cloud. Tot voor kort was de ondersteuning voor machines buiten Azure beperkt en vaak via een apart configuratiepad geregeld. De nieuwe release koppelt die bescherming direct aan Azure Arc: zodra een fysieke server of VMware-machine als Arc-resource is geregistreerd, kun je er Site Recovery-bescherming op zetten zoals je dat ook bij een Azure-VM zou doen.

Het resultaat is een kortere lijn tussen beheer en herstel. Je ziet de machine in dezelfde Azure-portal waar je haar al volgt voor inventaris, patchstatus en beleid, en je kunt er vanuit hetzelfde scherm een replicatieplan aan koppelen.

De rol van Azure Arc in dit verhaal

Azure Arc projecteert resources die buiten Azure draaien, op locatie, bij een andere provider of in een ander datacenter, als beheerobject in Azure. Je krijgt inventaris, beleidsregels en monitoring zonder dat de machine zelf verhuist. Veel organisaties gebruiken Arc inmiddels voor governance op hun fysieke serverpark, vaak zonder dat er al een concreet herstelplan achter hangt.

Met deze update wordt diezelfde Arc-verbinding ook de basis voor noodherstel. Je hoeft geen tweede agent of apart platform te leren: de machine die je al via Arc beheert, kan met een paar extra stappen ook gerepliceerd worden naar een Azure-regio naar keuze. Voor IT-teams die Arc al gebruiken voor beheer is de stap naar herstel daardoor klein.

Voor welke organisaties dit relevant is

Dit raakt vooral organisaties die bewust niet volledig naar de cloud zijn gegaan. Denk aan een vestiging met een lokale fileserver die om latency-redenen op locatie moet blijven, een productieomgeving met apparatuur die aan specifieke hardware is gekoppeld, of een sector waar regelgeving eist dat bepaalde data fysiek in Nederland blijft staan op eigen infrastructuur. Ook organisaties die recent in fysieke servers hebben geïnvesteerd en een volledige cloudmigratie financieel nog niet kunnen verantwoorden, hebben hier baat bij.

Voor deze groep was het DR-vraagstuk vaak het sluitstuk dat bleef liggen. Een eigen tweede locatie optuigen kost tijd en geld die niet in verhouding staan tot het risico, waardoor het onderwerp jaar na jaar werd doorgeschoven. Een cloudgebaseerd herstelpunt dat aansluit op infrastructuur die je toch al via Arc beheert, verlaagt die drempel aanzienlijk.

Hoe de implementatie er in de praktijk uitziet

De stappen volgen grotendeels het bestaande Arc-traject. Eerst installeer je de Arc-agent op de fysieke server of de VMware-machine, zodat deze als beheerde resource in Azure verschijnt. Daarna schakel je Site Recovery in voor die resource en kies je een doelregio in Azure. Vervolgens stel je een recovery plan op: welke machines horen bij elkaar, in welke volgorde moeten ze opstarten, en welke netwerkconfiguratie hoort bij de failover-omgeving.

De kosten zijn doorgaans lager dan een fysieke tweede locatie, omdat je tijdens normaal bedrijf vooral voor opslag van de gerepliceerde data betaalt en pas bij een echte of geteste failover voor volledige rekenkracht. Dat laatste punt is cruciaal: een herstelplan dat nooit getest is, is in de praktijk geen herstelplan. Plan een jaarlijkse of halfjaarlijkse failover-test in, buiten kantooruren, en behandel die test net zo serieus als een echte storing.

Wat dit niet oplost

De eerste replicatie van een fysieke server met veel data kost tijd en bandbreedte, zeker als de internetverbinding op die locatie niet voor dit doel is gedimensioneerd. Houd daar rekening mee in de planning, en overleg met je internetprovider als het om een grotere hoeveelheid data gaat. De ondersteuning geldt bovendien op dit moment voor Windows-machines; voor Linux-systemen op locatie moet je nog naar een ander scenario kijken.

Site Recovery is daarnaast geen vervanging voor een goede back-upstrategie. Het beschermt tegen het wegvallen van een locatie, niet tegen een losse verkeerde verwijdering of ransomware die zich al in de omgeving heeft genesteld voordat je failovert. De twee horen samen te werken: back-up voor herstel van data op een specifiek moment, Site Recovery voor het overeind houden van de dienst als de locatie zelf uitvalt.

Voor organisaties die al Azure Arc gebruiken voor beheer van hun fysieke of VMware-omgeving is dit een logische volgende stap: het dichten van het laatste gat in het herstelplan, zonder dat er een migratieproject voor nodig is. Wil je weten of jouw serveromgeving hiervoor in aanmerking komt, of hulp bij het opzetten en testen van een recovery plan? Zarioh denkt met je mee over een cloudstrategie die past bij de infrastructuur die je al hebt.