Checkpoint to nie kopia zapasowa: jak działają punkty kontrolne Hyper-V

Przed aktualizacją aplikacji administrator tworzy checkpoint maszyny wirtualnej, na wszelki wypadek. Aktualizacja się udaje, checkpoint zostaje. Po czterech miesiącach na woluminie z maszynami kończy się miejsce, kilka maszyn przechodzi w stan wstrzymania, a w katalogu z dyskami leży plik .avhdx o rozmiarze kilkuset gigabajtów, do którego trafiały wszystkie zapisy od dnia aktualizacji. Ktoś proponuje go usunąć, bo „to tylko checkpoint”.

Checkpoint (w polskim interfejsie: punkt kontrolny) w Hyper-V to narzędzie do szybkiego wycofania zmiany, a nie kopia zapasowa. Leży na tym samym magazynie co maszyna, zależy od jej dysku nadrzędnego i z każdą godziną kosztuje miejsce oraz wydajność. Ten wpis pokazuje, jak działa, kiedy ma sens i jak znaleźć checkpointy, które zostały za długo.

Jak działa checkpoint: łańcuch plików AVHDX

W chwili utworzenia checkpointu dysk VHDX maszyny przestaje być zapisywany. Hyper-V tworzy obok niego dysk różnicowy z rozszerzeniem .avhdx i od tej pory wszystkie zapisy trafiają do niego. Kolejny checkpoint tworzy kolejny plik AVHDX, którego rodzicem jest poprzedni. Maszyna pracuje na końcu łańcucha, a odczyt bloku, który nie był zmieniany, sięga do kolejnych poziomów aż do bazowego VHDX.

D:\Hyper-V\Virtual Hard Disks\
  srv-app-01.vhdx                                          120 GB   baza łańcucha, tylko odczyt
  srv-app-01_6F1C2A4E-1B7D-4C3A-9E55-0A1B2C3D4E5F.avhdx     38 GB   zmiany między checkpointem 1 a 2
  srv-app-01_9A8B7C6D-5E4F-4A3B-8C2D-1E0F9A8B7C6D.avhdx     11 GB   aktywny dysk, bieżące zapisy

Z tej budowy wynikają trzy konsekwencje:

• Miejsce. Każdy plik AVHDX rośnie z każdym zapisanym blokiem i może urosnąć do rozmiaru całego dysku. Gdy na woluminie zabraknie miejsca, Hyper-V wstrzymuje maszyny, których dyski na nim leżą (stan Paused-Critical), a nie tylko tę z checkpointem.
• Wydajność. Każdy dodatkowy poziom łańcucha to dodatkowa praca przy odczycie, a dane maszyny są rozproszone między kilka plików. Maszyny z intensywnym zapisem, takie jak bazy danych i serwery plików, odczuwają to najszybciej.
• Zależność. Plik AVHDX bez rodzica jest bezużyteczny. Uszkodzenie bazowego VHDX albo woluminu, na którym leży, niszczy jednocześnie maszynę i wszystkie jej checkpointy.

Checkpoint standardowy i produkcyjny

Hyper-V ma dwa rodzaje checkpointów, które różnią się tym, co zapisują i w jakim stanie zostawiają aplikacje.

Typ	Co zapisuje	Spójność aplikacji	Po przywróceniu
Standardowy (Standard)	dyski oraz stan pamięci i urządzeń maszyny	brak, aplikacja nie wie o checkpoincie	maszyna działa dalej od chwili utworzenia, z tymi samymi otwartymi połączeniami i transakcjami
Produkcyjny (Production)	dyski po zamrożeniu zapisów przez VSS w gościu Windows lub zamrożeniu systemu plików w gościu Linux	jak przy kopii zapasowej	maszyna startuje od wyłączenia, jak po odtworzeniu z kopii

Checkpoint standardowy przywraca maszynę „w biegu”, co dla bazy danych lub kontrolera domeny oznacza powrót do stanu, o którym reszta środowiska nic nie wie. Checkpoint produkcyjny wymaga działających w gościu usług integracji odpowiedzialnych za kopie (VSS). Typ ustawia się dla każdej maszyny:

# Production: produkcyjny, a gdy się nie uda, standardowy
# ProductionOnly: produkcyjny albo błąd, bez cichego przejścia na standardowy
# Standard: zawsze standardowy; Disabled: checkpointy wyłączone
Set-VM -Name srv-app-01 -CheckpointType ProductionOnly

Wartość domyślna Production po cichu tworzy checkpoint standardowy, jeśli produkcyjny się nie powiedzie. Dla serwerów z bazami danych i kontrolerów domeny lepszy jest ProductionOnly: nieudany checkpoint jest widoczny jako błąd, a nie jako checkpoint innego typu, niż zakładano.

Usuwanie to scalanie

Usunięcie checkpointu w Menedżerze Hyper-V lub przez Remove-VMSnapshot nie kasuje pliku od razu. Hyper-V scala zawartość AVHDX z dyskiem nadrzędnym i dopiero potem usuwa plik. W obecnych wersjach Hyper-V scalanie odbywa się przy działającej maszynie, a jego postęp widać w Menedżerze Hyper-V. Scalanie pliku o rozmiarze kilkuset gigabajtów trwa i mocno obciąża magazyn, dlatego checkpoint trzymany miesiącami usuwa się w oknie serwisowym, a nie w godzinach pracy.

# Scala zmiany z dyskiem nadrzędnym, maszyna działa dalej
Remove-VMSnapshot -VMName srv-app-01 -Name 'przed-aktualizacja-JK-usunac-do-2026-08-13'

Checkpointy na kontrolerach domeny

Kontroler domeny od Windows Server 2012, działający na hypervisorze obsługującym identyfikator VM-GenerationID, wykrywa przywrócenie checkpointu. Po przywróceniu identyfikator generacji maszyny się zmienia, więc kontroler resetuje swój identyfikator wywołania (invocationID), porzuca bieżącą pulę RID i pobiera zmiany od partnerów replikacji. To chroni przed USN rollback, czyli sytuacją, w której pozostałe kontrolery ignorują zmiany z przywróconego, bo uważają, że już je widziały.

To nadal nie jest kopia. Checkpoint leży na tym samym magazynie co kontroler. Przywrócony kontroler i tak dostanie od partnerów wszystkie późniejsze zmiany, w tym usunięcia, więc checkpoint nie odzyska omyłkowo usuniętego obiektu. Przy jedynym kontrolerze w domenie przywrócenie checkpointu oznacza utratę wszystkich zmian od chwili jego utworzenia. Kopią katalogu jest kopia stanu systemu, opisana w Kopia Active Directory i odtwarzanie lasu.

Checkpointy typu Recovery po zadaniach kopii

Oprogramowanie do kopii maszyn wirtualnych w Windows Server 2016 i nowszych tworzy w trakcie zadania checkpoint typu Recovery, a po zakończeniu go scala. Jeśli zadanie zostanie przerwane, checkpoint może zostać. Następne zadanie tworzy kolejny i po kilku tygodniach maszyna ma łańcuch kilkunastu plików AVHDX, których nikt świadomie nie utworzył. Checkpointy tego typu nie zawsze są widoczne w Menedżerze Hyper-V, dlatego szuka się ich przez PowerShell.

Pozostałość usuwa się dopiero po upewnieniu się, że żadne zadanie kopii tej maszyny nie jest w toku, i po naprawieniu przyczyny w systemie kopii. Inaczej po kilku dniach łańcuch odrośnie:

# Uruchamiać tylko, gdy żadne zadanie kopii tej maszyny nie jest w toku
Get-VMSnapshot -VMName srv-app-01 -SnapshotType Recovery | Remove-VMSnapshot

Kiedy checkpoint ma sens

Checkpoint jest dobrym narzędziem w jednym scenariuszu: przed konkretną zmianą, której skutki da się ocenić w ciągu godzin. Aktualizacja systemu, nowa wersja aplikacji, zmiana konfiguracji, która może uniemożliwić start. Po weryfikacji zmiany checkpoint się usuwa.

Pytanie	Checkpoint	Kopia zapasowa
Gdzie leży	na tym samym woluminie co maszyna	na innym systemie i nośniku, poza lokalizacją lub offline
Przetrwa awarię magazynu lub hosta	nie	tak
Przetrwa ransomware z uprawnieniami na hoście	nie	tylko kopia niezmienna lub offline
Typowy czas życia	godziny, najwyżej kilka dni	tygodnie i miesiące według retencji
Koszt utrzymania	rośnie z każdym zapisem i każdą godziną	stały, w osobnym magazynie
Do czego służy	szybkie wycofanie konkretnej zmiany	odtworzenie po awarii, utracie danych lub ataku

Nazwa checkpointu powinna mówić, kto go utworzył, po co i do kiedy ma zostać usunięty. Domyślna nazwa w rodzaju „srv-app-01 - (11.08.2026 - 09:14:02)” po miesiącu nie mówi nic nikomu:

Checkpoint-VM -Name srv-app-01 -SnapshotName 'przed-aktualizacja-JK-usunac-do-2026-08-13'

Sprawdź u siebie

Wszystkie checkpointy na hoście z ich wiekiem w dniach. W klastrze pracy awaryjnej zamiast samego Get-VM użyj Get-VM -ComputerName (Get-ClusterNode).Name:

Get-VM | Get-VMSnapshot |
    Select-Object VMName, Name, SnapshotType, CreationTime,
        @{ Name = 'WiekDni'; Expression = { [int]((Get-Date) - $_.CreationTime).TotalDays } } |
    Sort-Object CreationTime |
    Format-Table -AutoSize

Dobry wynik: pusta lista albo checkpointy sprzed kilku dni z nazwą wskazującą zmianę. Zły wynik: wiek liczony w tygodniach, domyślne nazwy z datą albo pozycje typu Recovery.

Maszyny, których dyski pracują na plikach różnicowych:

Get-VM | Get-VMHardDiskDrive |
    Where-Object Path -like '*.avhdx' |
    Select-Object VMName, ControllerType, Path

Każdy wiersz to maszyna z aktywnym checkpointem. Maszyna, która pracuje na pliku AVHDX, a nie ma żadnego checkpointu w wyniku Get-VMSnapshot, zwykle oznacza nieudane scalanie i wymaga ostrożnej analizy, a nie usuwania plików.

Łańcuch dysków jednej maszyny z rozmiarami plików:

$path = (Get-VMHardDiskDrive -VMName srv-app-01 | Select-Object -First 1).Path
while ($path) {
    $vhd = Get-VHD -Path $path
    [pscustomobject]@{
        Plik = Split-Path $vhd.Path -Leaf
        Typ  = $vhd.VhdType
        GB   = [math]::Round($vhd.FileSize / 1GB, 1)
    }
    $path = $vhd.ParentPath
}

Dobry wynik to jeden wiersz z typem Fixed lub Dynamic. Każdy wiersz typu Differencing to jeden poziom łańcucha, a suma rozmiarów pokazuje, ile miejsca zajmują checkpointy.

Pozostałości po zadaniach kopii i ustawiony typ checkpointów:

Get-VM | Get-VMSnapshot -SnapshotType Recovery | Select-Object VMName, Name, CreationTime
Get-VM | Select-Object Name, CheckpointType

Checkpoint Recovery starszy niż ostatnie udane zadanie kopii tej maszyny to pozostałość do wyjaśnienia. Wartość Standard przy serwerze z bazą danych lub kontrolerze domeny oznacza ustawienie do zmiany.