Usługa Azure Backup. Skuteczne tworzenie kopii zapasowych w chmurze
Wyobraźmy sobie sytuację, w której musimy zaimplementować backupy dla maszyn wirtualnych w chmurze dla całej organizacji. Jedno podejście wymagałoby zakupu osobnego serwera, licencji na oprogramowanie do zarządzania backupami oraz zapewnienia wystarczającej ilości miejsca na dane. Dodatkowo dochodzi kwestia odpowiedniego zabezpieczenia serwera. W takim procesie łatwo o błędy m.in. w zakresie źle oszacowanej liczby dysków do przechowywania danych, problemów z bezpieczeństwem czy dostępnością. Na szczęście na platformie Azure istnieją usługi, które mogą pomóc przejść przez procedurę backupu bez większych trudności: Azure Backup oraz Azure Disaster Recovery.


Czytaj dalej, a dowiesz się jak przeprowadzić udany backup w chmurze bez obaw o:
- Złe oszacowanie rozmiaru danych i zakup nieodpowiedniej liczby dysków;
- Brak odpowiedniego zabezpieczenia serwera i ochronę danych;
- Problemy z dostępnością krytycznych aplikacji w przypadku awarii;
- Rosnące koszty backupów.
Backup w chmurze Microsoft Azure
Na początek zastanówmy się, czym w zasadzie jest Azure Backup?
Jest to usługa, która po prostej konfiguracji będzie automatycznie wykonywała kopie zapasowe i zapisywała je w chmurze Microsoft Azure (a w razie potrzeby będzie je również odzyskiwała). W ten sposób zabezpieczyć możemy praktycznie każdy zasób na platformie Microsoft Azure, który przechowuje dane — począwszy od maszyn wirtualnych po bazy SQL czy PostgreSQL.
Co więcej, za pomocą usługi możemy również wykonywać backupy maszyn działających on-premise, czyli serwerów fizycznych. Mamy też możliwość przechowywania kopii zapasowych specyficznych plików lub folderów, znajdujących się na maszynach lub usługach takich jak Azure Blobs oraz Azure Files.
Azure Backup
Na przykładzie maszyn wirtualnych działa to w następujący sposób: po wybraniu, które z nich mają zostać objęte backupem, a następnie skonfigurowaniu, jak często ma być on wykonywany oraz jak długo mają być przechowywane kopie zapasowe, automatycznie na maszynach instalowany jest agent Azure Backup. Odpowiada on za wymianę informacji między maszynami a Azure Backup Vault. Skarbcem, w którym przechowywane są nasze zaszyfrowane dane.
Warto zwrócić uwagę na to, że Azure Backup wykonuje backupy różnicowe: pierwszy z nich zajmie dość dużo czasu i pamięci, ale pozostałe — jeśli nie są to kopie zapasowe przechowywane w ramach retencji — będą zawierać tylko informacje, co zostało zmienione od ostatniej kopii. Pozwala to zaoszczędzić miejsce w naszym Backup Vault (co będzie ważne, gdy dojdziemy do kosztów).
Azure Backup Vault
A teraz trochę o wspomnianym wcześniej Azure Backup Vault. Jest to usługa, która służy za „centrum” do spraw backupowania i przywracania kopii zapasowych. To z jego poziomu, jeśli mamy odpowiednie uprawnienia nadane przez RBAC (ang. Role-Based Access Control), możemy konfigurować aspekty takie jak: co ma być poddane backupowi oraz jak często, jak długo mamy przechowywać kopie zapasowe i migawki*, a także monitorować status wykonywania backupów oraz generować raporty.
*Migawki, czyli ang. snapshots – mechanizm pozwalający na wykorzystanie usługi Azure Backup Instant Restore, która w bardzo krótkim czasie umożliwia przywrócenie środowiska do stanu, w jakim znajdowało się w momencie wykonania migawki.
Replikacja danych w chmurze
Możemy również zdecydować, w jaki sposób dane mają być replikowane. Ogólnie na platformie Microsoft Azure mamy trzy stopnie replikacji:
- LRS (ang. locally redundant storage) – replikacja danych do innych macierzy w obrębie jednego centrum danych (ang. data center). Jeśli awarii ulegnie pojedyncze data center, nasze dane mogą być zagrożone.
- ZRS (ang. zone-redundant storage) – replikacja danych w obrębie trzech tzw. Azure Availability Zones w obrębie jednego rejonu. Nasze dane są bezpieczne, jeśli awarii ulegnie jedno data center, ale mogą być zagrożone w przypadku awarii obejmującej cały region.
- GRS (ang. geo-redundant storage) – replikacja danych do innego rejonu niż główny. W przypadku awarii obejmującej cały rejon, nasze dane wciąż są bezpieczne.
Oczywiście dla niektórych usług nie wszystkie stopnie replikacji są dostępne, a niektóre mają jeszcze dodatkowe możliwości (np. retencję Read-Only, pozwalającą na praktycznie niezakłócony dostęp do danych w sytuacji awarii głównej kopii).
Jaki stopień replikacji wybrać?
Powyższe stopnie replikacji uszeregowane zostały od tej najmniej bezpiecznej do tej zapewniającej największe bezpieczeństwo. Co nie oznacza, że replikacja LRS nie jest bezpieczna – wybór stopnia replikacji zależy od rodzaju danych, z jakimi mamy do czynienia (np. czy są to dane finansowe dla banku, czy też telemetria aplikacji na środowisku deweloperskim) oraz tego, jak krytyczna jest dla nas aplikacja z nich korzystająca. Nawet w przypadku wyboru LRS, nasze dane będą bezpieczniejsze niż przy wykorzystaniu prostej architektury backupowej na naszych serwerach on-premise.
Jak włączyć backupowanie w chmurze Azure?
Aby zaprezentować, jak łatwo można włączyć backupy dowolnego serwera (bez żadnej wiedzy technicznej), można posłużyć się poniższą krótką instrukcją.
- Wybieramy maszynę wirtualną, na której chcemy włączyć backupy. Przechodzimy do sekcji „Backup” w lewym blade.
- Jeśli backupy są już włączone, w tym miejscu wyświetli nam się lista ostatnio wykonywanych zadań oraz ogólny status backupu (rys. 1). W innym przypadku pojawi się menu, jak na rys. 2 i rys. 3.
- Podczas włączania backupu mamy kilka opcji. Skupiają się one wokół:
- Recovery Services Vault (RSV) – usługi, która zajmuje się wykonywaniem zadań backupów i przechowywania kopii zapasowych. W ramach włączenia backupu na dowolnej maszynie mamy opcję utworzenia nowego RSV lub wykorzystania istniejącego. W ramach tworzenia musimy podać nazwę RSV oraz grupę zasobów, w której te będzie się znajdowało.
- Polityki – zbioru zasad, według którego tworzone będą kopie zapasowe. To tutaj określimy, jak często mają one być wykonywane oraz jak długo przechowywane. Dodatkowo mamy możliwość wyboru typu polityki (standardowego lub ulepszonego). Ulepszony typ polityki pozwala przede wszystkim na wielokrotne tworzenie kopii zapasowych w ciągu jednego dnia. Możemy wykorzystać istniejącą już politykę lub utworzyć nową z własnymi ustawieniami.
- Dysków – wyboru dysków, które mają być objęte tworzeniem kopii zapasowych. Przydatna opcja w przypadku, kiedy chcemy zaoszczędzić wiedząc, że na jednym z dysków nie znajdują się dane krytyczne.
- Po wybraniu konfiguracji wybieramy opcję „Enable Backup”, aby włączyć tworzenie nowych kopii zapasowych w chmurze.






Koszty Azure Backup i tworzenia kopii zapasowych w chmurze
Teraz przejdźmy do sedna sprawy, czyli kosztów. Przy szacowaniu kosztów usługi Azure Backup należy wziąć pod uwagę przede wszystkim rozmiar przechowywanych danych oraz stopień replikacji. Im więcej danych chcemy przechowywać, tym więcej musimy zapłacić. A im bardziej krytyczne są to dla nas dane, płacimy większą lub mniejszą stawkę (bazując na rodzaju replikacji).
Strategia backupowania a koszty
Warto przy tym zwrócić uwagę, że przedłużenie czasu przechowywania kopii zapasowej może radykalnie zwiększyć rozmiar przechowywanych danych, a co za tym idzie również i koszty. Wybór odpowiedniej strategii backupowania jest więc kluczowy, jeśli chcemy, aby nasze środowisko Azure było zoptymalizowane pod względem wydatków.
Największe korzyści Azure Backup
Największą zaletą, porównując Azure Backup do klasycznych sposobów tworzenia kopii zapasowych, jest właśnie koszt usługi – generowany wyłącznie za rzeczywiście wykorzystywane miejsce (co sprawia, że jest to najbardziej ekonomiczny wybór :)). Tym samym nie musimy tworzyć szacunków, jak duże muszą być nasze maszyny odpowiedzialne za backupy czy ile instancji wymagane jest, aby w przewidzianym czasie stworzyć kopie zapasowe wszystkich pozostałych maszyn.
Ta odpowiedzialność przenoszona jest na dostawcę chmury, a z naszej strony pozostaje tylko jasne określenie wymagań. Nie musimy również stresować się opcjami zabezpieczania danych (wbudowane szyfrowanie zapewni ich bezpieczeństwo) ani koniecznością dokupowania kolejnych maszyn.
Zabezpieczenie aplikacji. Disaster Recovery
Projektując lub tworząc rozwiązania, może okazać się, że niektóre aplikacje są dla nas krytyczne, a tym samym musimy zapewnić ich wysoką dostępność (czy to ze względu na wymagania klienta, skalę aplikacji, wizerunek i działania firmy czy też odpowiedzialność za życie lub zdrowie użytkowników). Tego typu rozwiązania należy zabezpieczyć przed niespodziewanymi zdarzeniami. Tylko jak?
Zaplanowanie i wdrożenie odpowiedniego zabezpieczenia naszej aplikacji to właśnie Disaster Recovery, czyli sposób postępowania w przypadku awarii.
Disaster Recovery w chmurze
W chmurze mamy kilka opcji wprowadzenia usługi Disaster Recovery. Jedną z nich jest wdrożenie własnego rozwiązania, polegającego na wykorzystaniu Load Balancerów i kilku zapasowych instancji naszej aplikacji. W przypadku awarii Load Balancer powinien automatycznie zacząć przekierowywać cały ruch użytkowników do działających instancji.


Drugą opcją jest wykorzystanie rozwiązań oferowanych przez dostawców chmurowych. W przypadku platformy Azure jednym z takich rozwiązań jest Azure Site Recovery (w skrócie ASR).
Rozwiązanie działa na podobnej zasadzie, co opisywany wyżej przykład, ale pozwala zaoszczędzić na kosztach działania infrastruktury, jak również na kosztach stworzenia działającego systemu Disaster Recovery. Rozwiązanie nie jest ograniczone tylko do środowisk chmurowych, możemy je również połączyć ze środowiskiem działającym on-premise.
Azure Site Recovery
Azure Site Recovery działa w następujący sposób:
- Wykrycie awarii — na podstawie zdefiniowanych metryk ASR wykrywa wystąpienie awarii. Tymi metrykami może być np. brak odpowiedzi serwera lub negatywna odpowiedź podczas zapytania o stan zdrowia.
- Uruchomienie planu odzyskiwania — po wykryciu awarii ASR automatycznie wdraża zdefiniowany wcześniej plan odzyskiwania. Plan określa, które maszyny wirtualne mają powstać oraz w jakiej kolejności mają się uruchomić.
- Replikacja danych — ASR może na bieżąco replikować dane do chmury. Po uruchomieniu planu odzyskiwania dane te mogą być wykorzystywane przez nowo powstałe maszyny.
- Przełączenie na nowo powstałe środowisko — po utworzeniu zaplanowanych instancji maszyn wirtualnych, użytkownicy zostają przełączeni do korzystania ze środowiska powstałego w ramach Azure Site Recovery.
Zalety Azure Site Recovery
Wspomnianą wcześniej główną zaletą ASR są koszty infrastruktury. Za maszyny wirtualne płacimy tylko, kiedy te są uruchomione, a uruchomienie następuje w momencie awarii i trwa podczas jej naprawy. Oczywiście są pewne stałe koszty, takie jak opłaty za przesył danych i ich przechowywanie lub — w specyficznych przypadkach — za licencje.
Dodatkowo administratorzy mogą na bieżąco otrzymywać raporty ze statusu ASR w przypadku awarii, a także monitorować jego stan, jeśli taka awaria nie występuje. Istnieje również możliwość przeprowadzania procedur DRP, bez wpływu na środowisko produkcyjne.
Studium przypadku: migracja i backup 80 maszyn wirtualnych
Jeden z naszych klientów posiadał rozległą infrastrukturę działającą on-premise, liczącą około 80 maszyn wirtualnych. W ramach projektu migracji do chmury przygotowaliśmy szereg artefaktów, w tym specyfikacje backupu na różnych chmurach – więcej przeczytasz o tym w case study: Kompleksowy audyt gotowości wyjścia do chmury dla towarzystwa ubezpieczeniowego.
Ostatecznie, porównując dostępnych dostawców chmurowych, klient zdecydował się na wybranie chmury Azure. W ramach migracji przeniesione zostały również backupy do Azure Backup oraz skorzystano z usługi Azure Disaster Recovery dla bardziej krytycznych systemów.
Konfiguracja tworzenia kopii zapasowych została taka sama jak na on-premise. Wszystkie maszyny były backupowane codziennie o godzinie 00:00.
Dzięki zastosowaniu usługi Azure Disaster Recovery, praca, potrzebna do zagwarantowania szybkiego przywrócenia maszyny w razie awarii była minimalna. Wystarczyła odpowiednia konfiguracja sieciowa oraz prosta konfiguracja w portalu Azure.
Efekty. Ciągłość działania w chmurze
Porównując do poprzedniego stanu, czasy wykonywania testów DRP spadły ze średniego czasu 121 min do 33 min dla tych samych serwerów. Była to znacząca poprawa czasu odzyskiwania maszyn wirtualnych, co było jednym z celów klienta. W przypadku awarii jednej z krytycznych dla organizacji aplikacji ta automatycznie wróciłaby do działania w ciągu kilkunastu minut od zdarzenia.
Podsumowanie
Korzystając z wybranej chmury, warto zaznajomić się z narzędziami lub usługami natywnymi. Często są one o wiele szybsze w konfiguracji od standardowego podejścia, polegającego na własnoręcznym wdrażaniu usług w naszej infrastrukturze on-premise lub na maszynach wirtualnych działających w chmurze. Niosą one za sobą również gamę innych korzyści: zgodność z wymaganymi normami, przeniesienie odpowiedzialności na dostawcę czy też wsparcie w rozwiązywaniu problemów.
Usługi takie jak Azure Backup lub Azure Disaster Recovery pozwalają na efektywniejsze zarządzanie chmurą i szybkie odzyskiwanie danych, ale nie są oczywiście lekarstwem na wszystkie dolegliwości. Należy poznać i zrozumieć limity i przypadki użycia tych rozwiązań, a każdy przypadek stosowania powinien być omawiany osobno, pod względem jego specyfiki.