Hyper-V Backup og Secure DMZ-servere: En veiledning for hvordan du gjør det

Fra et sikkerhetssynspunkt er et sikkert alternativ som brukes for eksempel av VPS-vertsleverandører som vi jobber med, å DMZ de virtuelle virtuelle, ikke hyper-v-verten.

Ved DMZ-ing vMs i stedet for verten, kan du få tilgang til og sikkerhetskopiere verten som vanlig og har bare VMs utsatt for utsiden. Angripere får ikke lett tilgang til verten fra VM. Bare Hyper-V-integrasjonstjenestene ville potensielt og teoretisk tillate noe skadelig programvare kanskje å snakke med verten; Microsoft har imidlertid sikret dette ganske bra så langt.

Alle strategier, inkludert ovennevnte har sine egne fordeler og ulemper:

Legge til en ny sikkerhetskopi NAS i det interne LAN og åpne porten mellom DMZ Hyper-V Server for sikkerhetskopier

I så fall tar angriperen over verten og kan gjøre hva han vil, inkludert å skade sikkerhetskopienheten. Forresten, ransomware gjør dette også. Det kan finne nettverkstilgang aksjer og skade alle filer der også.

Legge til en ny NAS i DMZ. Pro: du trenger ikke endre noe i brannmuren

I så fall ulempen er angriperen kan få full tilgang til verten, alle virtuelle maskiner på den, og alle sikkerhetskopier av det, slik at du potensielt med ingenting å gjenopprette fra i tilfelle et angrep.

Hvis du DMZ alle virtuelle maskiner ved hjelp av statiske IP-adresser, er risikoen begrenset til de interne for hver VM. Ulempen er at du må DMZ alle virtuelle maskiner separat, men verten vil forbli på det interne nettverket og beskyttet som den er, inkludert sikkerhetskopier etc.

Et annet sikkerhets "triks" er å sette opp en isolert virtuell svitsj og feste et eget NIC for de DMZ VMs slik at virtuelle maskiner har ingen måte å snakke med det interne nettverket, inkludert verten. Det ville gi deg et annet lag av sikkerhet i tilfelle noen hacks inn i VM.

Prøv denne backup-løsningen for å beskytte hyper-v-servere og virtuelle maskiner til en lav pris.

Hyper-V CSV-sikkerhetskopiering: Hva må vurderes for VM-sikkerhetskopier?

Følgende punkter bør observeres når du sikkerhetskopierer virtuelle Hyper-V-maskiner til CSV-er.

1. Den nyeste versjonen av BackupChain bør brukes
2. Alle VM-filer må lagres på samme CSV-
3. Sikkerhetskopien skal bare gjøres via Hyper-V-fanen. Komplett serverbildesikkerhetskopiering må ikke inneholde CSV-volumer; det bør bare inkludere systemet OS og eventuelt datadisker.
4. Hvis det er sannsynlig at virtuelle maskiner vil bli flyttet til andre noder, bør funksjonen for automatisk valg brukes i stedet for å velge VMs fra listen En fartsgrense aktiveres når klyngealternativet angis når oppgaven opprettes. Dette kan økes eller slås av hvis du er sikker på at CSV-administrasjonstrafikken er 100 % isolert og ikke kan påvirkes av sikkerhetskopieringstrafikk og andre dataoverføringer. Ellers kan det hende at hjerteslagene ikke kommer i tide og Hyper-V slår helt av noden

Som med alle Hyper-V-sikkerhetskopier, avhengig av verten og gjestoperativsystemet, kan det hende at Hyper-V "glir inn" et lite kontrollpunkt kort tid før sikkerhetskopien, som slettes umiddelbart etter init-fasen. Denne kontrollpunktfilen vises i sikkerhetskopimappene som * . Avhdx. I tillegg finner du også andre AVHD / X i sikkerhetskopimappene hvis VM har andre sjekkpunkter.

Vi anbefaler at sjekkpunkter ikke brukes, og hvis du bruker dem, bør de bare brukes i kort tid. Når du bruker sjekkpunkter, er det også noen ulemper og risikoer å vurdere. Detaljert gjenoppretting i BackupChain fungerer bare på VHD / X basis. Sjekkpunkter kan ikke inspiseres med denne funksjonen, det vil si at en fullstendig gjenoppretting er mer sannsynlig nødvendig hvis de ønskede filene ikke finnes i hoved-VHD-filen. Når du oppretter et kontrollpunkt i Hyper-V, fryses VHD (og tidligere kontrollpunkter er også) og en ny AVHD/X opprettes. Alle endringer i VM vil i fremtiden bli skrevet til AVHD på sektorbasis. Når du sletter kontrollpunktet, må innholdet i AVHDene slås sammen med den overordnede VHD,som kan ta en stund.

Ulempene er høyere kompleksitet og langsommere verter og nettverkstilgang. Risiko er mulig tap av data, det var allerede flere feil i Hyper-V som førte til fullstendig tap. Noen risikable faser har blitt værende, for eksempel fletteprosessen når et kontrollpunkt slettes, eller når VHD-referanser konfigureres når kontrollpunkter opprettes. Hvis systemet for eksempel er sikkerhetskopiert eller det er strømbrudd, er minnet på CSV-filen også separat og i tillegg påvirket, er det fare for dataødekraft. Microsoft har selvfølgelig forbedret VHDX-formatet for å redusere risikoen, men virtuelle harddisker er absolutt ikke 100% beskyttet mot korrupsjon fra alle årsaker.