KVM – kopia zapasowa online maszyny wirtualnej

Ludzi dzielimy na tych, którzy robią kopię zapasową i tych, którzy jeszcze nic nie utracili. Humorystycznie rzecz ujmując są też tacy, którym tylko się wydaje, że robią kopię zapasową (dlatego warto sprawdzić od czasu do czasu czy kopia się robi i czy da się ją odtworzyć). Warto robić zarówno kopię zapasową samych plików (jak kod strony i bazy danych) jak i całej maszyny wirtualnej.

Dlaczego opłaca się robić obie rzeczy?

– kopia zapasowa plików pozwala szybko odtworzyć plik z kopii kiedy go np. przypadkowo usuniemy

– kopia zapasowa całej wirtualnej maszyny pozwala nam oszczędzić czas na konfigurację serwera w przypadku, kiedy lokalny dysk ulega awarii (w tym te połączone w system RAID 1,5,6, 10 etc).

Należy pamiętać, że systemy RAID chronią nas, kiedy padnie jeden dysk (lub więcej – zależnie od konfiguracji). Jednak w przypadku uszkodzenia większej ilości dysków, kontrolera RAID czy płyty głównej oznaczać może to dla nas utratę danych. Dlatego też system RAID to nie jest kopia zapasową i tą warto wykonywać na niezależną maszynę (czy też np. taśmę).

Skoro w wirtualizacji dysk twardy dla hipervisora jest zwykłym plikiem, dlaczego by go po prostu nie skopiować? Tutaj niestety występuje problem na jaki możemy się natknąć podczas robienia kopii plikowej – plik będzie ciągle w użyciu i cały czas jest modyfikowany. Możemy oczywiście zatrzymać maszynę wirtualną i skopiować plik bez problemu. I o ile na środowisku developerskim możemy sobie na to pozwolić, to w przypadku serwerów, które muszą działać cały czas, jest to problematyczne. Należy tutaj pamiętać, że pliki dysków zazwyczaj zajmują ponad 100GB i kopiowanie takiego pliku nawet po sieci 1Gbps trwa długo.

Na nasze szczęście tutaj wirtualizacja daje nam dodatkowe możliwości. W naszym przypadku można mieć ciastko i zjeść ciastko 🙂 Aby wykonać kopię zapasową bez zatrzymania maszyny, wykorzystamy mechanizm nazwany snapshotem. Snapshot jest migawką systemu. W dowolnym momencie możemy zatrzymać czas 🙂 Oczywiście nie dosłownie. Chodzi o to, że wszystkie zmiany na dysku wirtualnej maszyny są zapisywane w jednym pliku. W momencie zrobienia snapshota tworzony jest nowy plik, na którym zapisywane są wszystkie zmiany względem oryginalnego. To daje nam możliwość powrotu do zawartości dysku sprzed zrobienia snapshota. Daje nam to też dodatkowy atut w przypadku kopii zapasowej – plik sprzed snapshota staje się plikiem, na którym nic się nie zmienia. Możemy go więc spokojnie skopiować, gdy wszystko się dzieje w innym pliku i maszyna cały czas działa. Kiedy skończymy kopiować plik odwracamy zmianę i łączymy plik snapshota z pierwotnym plikiem. Całość przedstawiona poniżej.

 

W praktyce jest to dość proste i wymaga kilku poleceń

1. Sprawdzamy jaki plik jest używany jako dysk dla naszej wirtualnej maszyny

virsh domblklist vm1

gdzie vm1 to nazwa naszej maszyny wirtualnej (jeżeli nie znamy nazwy polecenie „virsh list” nam pomoże)

Przykładowy wynik:

Target     Source
------------------------------------------------
vda        /volume1/images/base.qcow2 

2. Robimy plik snapshota

 virsh snapshot-create-as --domain vm1 vm1-backup \
    --diskspec vda,file=/sciezka_do_pliku_snapshota.qcow2 \
    --disk-only --atomic 

3. Kopiowanie pliku na serwer backupu

Tutaj zależy od naszego systemu backupowego. Kopiujemy plik, który jest wynikiem polecenia nr 1

(w naszym przykładzie /volume1/images/base.qcow2). Przykładowo

scp /volume1/images/base.qcow2 backup@backup-server:~

4. Połączenie pliku oryginalnego z plikiem snapshota

virsh blockcommit vm1 vda --active --verbose --pivot

Gdzie vm1 to nazwa naszej wirtualnej maszyny

5. Usunięcie pliku snapshota.qcow2

rm sciezka_do_pliku_snapshota.qcow2