Wykorzystywanie AWS Backup do ochrony baz danych Amazon Aurora

Wiele organizacji korzysta z baz danych do obsługi aplikacji o dużym znaczeniu. Posiadanie kompleksowej strategii ochrony tych baz danych jest podstawą do spełnienia umów dotyczących poziomu usług biznesowych (SLA).

Optymalna strategia obejmuje wykorzystanie zarówno kopii zapasowych, jak i replikacji do ochrony baz danych w przypadku klęski żywiołowej, błędu ludzkiego lub zagrożenia cybernetycznego.

Klienci mogą używać AWS Backup jako scentralizowanego rozwiązania do organizowania kopii zapasowych dla wielu usług AWS, w tym baz danych Amazon Aurora. Używając AWS Backup jako silnika orkiestracji, klienci mogą ustanawiać zasady, monitorować swoje kopie zapasowe i replikować je na kontach lub regionach, pomagając zapewnić ich optymalną architekturę. AWS Backup posiada dodatkowe funkcje dzięki wykorzystaniu AWS Backup vault i AWS Backup Audit Manager. Dzięki magazynom kopii zapasowych AWS klienci mogą tworzyć niezmienną kopię danych, które można następnie replikować na inne konto lub w różnych regionach w zaszyfrowanym formacie przez wewnętrzną sieć AWS.

Za pomocą tego artykułu twórcy chcą pomóc Ci w zrozumieniu, dlaczego powinieneś używać AWS Backup, a także metodologii włączania AWS Backup do środowiska Amazon Aurora i strategii tworzenia kopii zapasowych. Dzięki AWS Backup masz możliwość oddzielenia kopii zapasowych od danych produkcyjnych, zwiększając bezpieczeństwo i wytrzymałość. Co więcej, dzięki magazynom kopii zapasowych możesz dodatkowo podzielić dane kopii zapasowej na różne konstrukcje logiczne, co może być korzystne w sytuacji, gdy nie chcesz jednocześnie zarządzać wszystkimi danymi kopii zapasowej.

Przypadki użycia

Ochrona obciążeń bazy danych za pomocą AWS Backup może odbywać się na różne sposoby, a w zależności od metodologii można osiągnąć różne poziomy ochrony, bezpieczeństwa i możliwości zarządzania. Na przykład prosta, codzienna migawka bazy danych, która jest przechowywana na tym samym koncie, co produkcyjna kopia bazy danych, może być łatwa w użyciu, gdy wymagane jest proste wycofanie zmian. Jednak nie robi zbyt wiele, aby zmniejszyć ryzyko, jakie wprowadziłby złośliwy atak lub katastrofa na dużą skalę. AWS Backup zapewnia tę możliwość, ale promień wybuchu jest po prostu zbyt duży dla wielu klientów. Klienci korzystają z baz danych AWS Backup for Amazon Aurora, aby sprostać szerokiej gamie zastosowań, w tym uproszczonemu zarządzaniu za pomocą centralnego narzędzia, przywracaniu operacyjnemu i bezpieczeństwu.

Uproszczone zarządzanie

AWS Backup obsługuje wiele usług AWS oprócz aplikacji innych firm. Dziś klienci mają takie same możliwości zarządzania kopiami zapasowymi, niezależnie od tego, czy tworzą kopie zapasowe pojedynczych zasobników Amazon Simple Storage Service (Amazon S3), czy też całej chmury VMWare Cloud w środowiskach AWS. Wiele organizacji decyduje się również na posiadanie scentralizowanego konta zapasowego, aby zawęzić promień wybuchu. To konto kopii zapasowej działa jako izolowane repozytorium danych kopii zapasowych wielu aplikacji. Zwykle, ze względu na zasadę „dostępu z najmniejszymi uprawnieniami”, właściciel aplikacji nie ma potrzeby bezpośredniego dostępu do swoich danych kopii zapasowej. Proces tworzenia kopii zapasowej jest zautomatyzowany i kontrolowany przez konto kopii zapasowej.

Odzyskiwanie operacyjne

Replikacja bazy danych do innego regionu zapewnia środki do odzyskiwania po awarii lub operacyjne. Oprócz replikowania kopii zapasowych, Aurora obsługuje również wbudowaną replikację w tym samym klastrze, co może zwiększyć zarówno wydajność, jak i dostępność. Jednak ta kopia dodatkowa jest zsynchronizowana z kopią podstawową, więc jeśli zostanie wprowadzona niechciana modyfikacja, zostanie ona zreplikowana do lokalizacji dodatkowej. Tworząc kopię zapasową baz danych, możesz zachować historyczną kopię danych. Ponadto korzystanie z magazynów AWS Backup umożliwia klientom tworzenie stałej kopii danych, która jest bezpiecznie przechowywana i egzekwowana przez zasady skonfigurowane przez klienta.

Bezpieczeństwo

Integracja AWS Backup z Amazon Aurora umożliwia klientom tworzenie stałych kopii ich danych. Te kopie można następnie zreplikować na inne konto lub do innego regionu w celu izolacji. Dodatkowo, korzystając z magazynów AWS Backup, klienci mogą egzekwować zasady bezpieczeństwa dla kopii zapasowych baz danych. Wspomniany artykuł stanowi cenne źródło informacji podczas przygotowywania strategii zarządzania tożsamością i dostępem AWS (IAM), ponieważ odnosi się ona do używania zasad kontroli usług jako barier ochronnych.

Amazon Aurora obsługuje szyfrowanie bazy danych i migawek za pomocą klucza zarządzanego przez klienta lub klucza zarządzanego AWS. Gdy źródłowa baza danych jest zaszyfrowana, jej migawki również są szyfrowane. Migawki klastra Aurora są automatycznie szyfrowane przy użyciu tego samego klucza szyfrowania, który został użyty do zaszyfrowania źródłowego klastra Amazon Aurora. AWS Backup dodaje dodatkową warstwę ochrony, szyfrując migawkę, która ma być replikowana w regionach przy użyciu klucza usługi zarządzania kluczami AWS (KMS) regionu docelowego. Jest to ulepszenie każdej strategii bezpieczeństwa, ponieważ Twoje klucze nie mogą zostać przejęte i ponownie użyte w różnych regionach.

Dzięki centralnemu zarządzaniu danymi kopii zapasowych klienci mają możliwość oddzielenia roli ochrony danych i związanych z nią uprawnień od tradycyjnej administracji bazami danych. Pomaga to również organizacjom stosować zasady „najmniej uprzywilejowanego dostępu” do zarządzania danymi kopii zapasowych. Wreszcie, oprogramowanie ransomware jest bardzo poważnym problemem dla prawie wszystkich organizacji cyfrowych, a AWS Backup może pomóc w zabezpieczeniu środowiska AWS przed oprogramowaniem ransomware. AWS Backup Vault dodatkowo pomaga poprawić ogólny stan bezpieczeństwa Twojej organizacji przed oprogramowaniem ransomware.

Zgodność

Konto kopii zapasowej powinno również być w stanie kontrolować wymagania dotyczące przechowywania danych i write-once oraz ready-many (WORM). AWS Backup Vault Lock zapewnia tę możliwość i może nawet sprawić, że dane kopii zapasowej będą niezmienne dla administratorów kopii zapasowych.

Możliwość przywracania można udostępnić właścicielom aplikacji lub oddzielnym zespołom w sposób samoobsługowy i zautomatyzowany. Daje to zespołom bezpieczeństwa możliwość rozdzielania ról i uprawnień oraz delegowania obowiązków, ograniczając wpływ błędu ludzkiego. Bardziej szczegółowe dane dotyczące zgodności można znaleźć na dedykowanej stronie zgodności AWS dla AWS Backup, a także na rosnącej liczbie usług AWS i stale rozszerzających się ramach regulacyjnych.

Aby jeszcze bardziej zmniejszyć promień wybuchu, klienci AWS mogą ulepszyć swoją strategię tworzenia kopii zapasowych, replikując kopie zapasowe do regionu pomocniczego, chroniąc się przed regionalnymi katastrofami. We wszystkich przypadkach ważne jest, aby mieć przemyślaną strategię w odniesieniu do struktury AWS Organizations. Najlepsze praktyki dotyczące zakładania kont w organizacjach AWS można znaleźć w sekcji Best Practices for Organizational Units with AWS Organizations.

Na koniec możesz kontrolować i raportować zgodność procesów tworzenia kopii zapasowych za pomocą AWS Backup Audit Manager. AWS Backup Audit Manager dostarcza szczegółowe dane kopii zapasowych do AWS Audit Manager, dzięki czemu klienci mogą łatwo tworzyć kontrole i struktury w celu zbierania dowodów i przedstawiania dowodów kopii zapasowych.

Docelowy punkt odzyskiwania i czas odzyskiwania

Podstawowym elementem odzyskiwania bazy danych jest zrozumienie celów czasu odzyskiwania (RTO) i celów punktu odzyskiwania (RPO). Te krytyczne cele odzyskiwania po awarii (DR) powinny doprowadzić bazy danych do trybu online i do punktu, w którym utrata danych będzie minimalna lub żadna. RPO dotyczy utraty danych. Wskazuje liczbę minut lub godzin, przez jaką organizacja może tolerować utratę danych, zanim przekroczony zostanie znośny próg. Z drugiej strony RTO określa, jak szybko Twoja baza danych będzie dostępna wkrótce po zdarzeniu. Zapoznaj się z filarem niezawodności Well-Architected Framework, ponieważ bardziej szczegółowo definiuje on RTO i RPO. Ponadto przejrzyj blog AWS na temat architektury odzyskiwania po awarii (DR) w AWS, część I: Strategie odzyskiwania w chmurze, aby uzyskać więcej informacji na temat architektur referencyjnych umożliwiających osiągnięcie RTO i RPO.

RTO i RPO powinny uwzględniać minimalne przestoje i utratę danych. Istnieją jednak kompromisy do rozważenia. Na przykład im niższe RTO i RPO, tym większe są koszty i zapotrzebowanie operacyjne. Jednak wyższy RTO i RPO może wydłużyć czas odzyskiwania i spowodować większą utratę danych. Dlatego należy wziąć pod uwagę cele RTO i RPO, które są odpowiednie dla obciążenia i biznesowych umów SLA.

Określając harmonogram tworzenia kopii zapasowych, należy rozważyć tworzenie kopii zapasowej bazy danych okresowo i tak często, jak to konieczne, aby zminimalizować konsekwencje utraty danych. Amazon Aurora automatycznie tworzy kopię zapasową woluminu bazy danych i zachowuje dane przywracania przez okres przechowywania kopii zapasowej. W przypadku automatycznych kopii zapasowych okres przechowywania wynosi domyślnie 1 dzień, ale okres przechowywania można dostosować od 1 do 35 dni podczas tworzenia lub modyfikowania klastra Aurora DB. Aby zachować kopie zapasowe przez dłuższy czas, wykonaj migawki bazy danych w woluminie klastra. Migawka pozwoli w razie potrzeby utworzyć nowy klaster DB.

Rozpoczynanie pracy

Aby rozpocząć korzystanie z AWS Backup po raz pierwszy, przejdź do usługi AWS Backup i wybierz Utwórz plan kopii zapasowej w konsoli AWS. Masz możliwość zbudowania nowego planu od podstaw lub stworzenia planu przy użyciu formatu JSON. Natomiast klienci powinni zaprojektować plan, który najlepiej pasuje do ich przypadku użycia. Dla uproszczenia tej demonstracji autorzy użyją wcześniej utworzonego szablonu. Wybierz Daily-35day-Retention i nadaj nazwę swojemu planowi tworzenia kopii zapasowych.

Rysunek 1: Utwórz plan kopii zapasowej, zaczynając od szablonu lub budując nowy plan od podstaw.

Następnie możesz wybrać istniejącą regułę kopii zapasowej, która umożliwia dostosowanie harmonogramu, okna tworzenia kopii zapasowej i zasad cyklu życia. Alternatywnie możesz utworzyć nową regułę kopii zapasowej, a także nowy magazyn kopii zapasowej, który będzie z nią powiązany.

Jeśli tworzysz nowy magazyn, upewnij się, że używasz odpowiedniego klucza szyfrowania.

Rysunek 2: Dodaj regułę kopii zapasowej, definiując harmonogram tworzenia kopii zapasowych, okno tworzenia kopii zapasowej i reguły cyklu życia.

Jak dotąd nic z tego nie było specyficzne dla Twojego klastra Aurora, więc ten plan tworzenia kopii zapasowych można ponownie wykorzystać dla dowolnych zasobów, do których zdecydujesz się zastosować go w przyszłości. Po utworzeniu planu tworzenia kopii zapasowych wybierz w konsoli opcję Przypisz zasoby. Na tym etapie możesz wybrać przypisanie wszystkich zgodnych zasobów na swoim koncie do swojego planu tworzenia kopii zapasowych w celu zapewnienia ogólnej ochrony w tym samym planie. Mimo to, w tym przypadku użycia autorzy wybrali konkretnie Aurorę i udostępnili swój identyfikator klastra.

Rysunek 3: Przypisz zasoby do planu tworzenia kopii zapasowych.

Na koniec potwierdź przypisanie, wybierając Przydziel zasoby. Po powrocie do pulpitu AWS Backup powinieneś być w stanie potwierdzić wszystkie te nowe konstrukcje. Pamiętaj, że jeśli nowa reguła tworzenia kopii zapasowych powoduje, że domyślna reguła DailyBackups jest niepotrzebna, możesz ją usunąć lub zmodyfikować w sekcji Plany tworzenia kopii zapasowych w konsoli.

Kluczowe czynniki

Aurora obsługuje zarówno silniki PostgreSQL, jak i MySQL, a klienci powinni wybrać odpowiedni silnik w oparciu o ich unikalne przypadki użycia i zbiory umiejętności. Aurora została zaprojektowana w celu zapewnienia ponad 99,99% dostępności dla produkcyjnych baz danych przy użyciu kombinacji sześciu zreplikowanych kopii danych DB w trzech strefach dostępności. Z perspektywy ochrony danych klienci mogą uzyskać te same korzyści scentralizowanego zarządzania, które zapewnia AWS Backup, niezależnie od wybranego silnika.

Klienci mają możliwość tworzenia planu tworzenia kopii zapasowych za pomocą JSON i AWS Backup CLI i mogą stosować podobne zasady wielokrotnego użytku, niezależnie od tego, czy tworzą kopie zapasowe danych z Aurora, czy coraz większej liczby innych usług obsługiwanych przez AWS Backup.

Podczas programowego raportowania zadań tworzenia kopii zapasowych można korzystać z metod takich jak observer solution, aby zautomatyzować dostarczanie i wizualizację stanu kopii zapasowej. Należy zauważyć, że kopie zapasowe utworzone za pomocą AWS Backup mają nazwy kończące się na awsbackup:AWS-Backup-job number. Jest to przydatne do odróżnienia tych danych od tradycyjnych migawek Aurora. Aby uzyskać dodatkowe informacje dotyczące AWS Backup, zobacz AWS Backup Developer Guide. AWS Backup for Aurora nie zapewnia jeszcze możliwości tworzenia przyrostowych kopii zapasowych, więc każda kopia zapasowa w Twoim planie będzie kopią pełną.

Wreszcie, wielu klientów decyduje się również na użycie AWS Backup Audit Manager, aby zapewnić automatyczne raportowanie i audyty ich środowisk kopii zapasowych. Jest to dodatkowy ważny czynnik w utrzymaniu zgodności.

Ograniczenia

Kompatybilność między Aurora i AWS Backup jest obecnie dostępna we wszystkich regionach AWS z wyjątkiem Chin i nie wszystkie funkcje AWS Backup są jeszcze obsługiwane podczas ochrony klastrów Aurora. Porównaj szczegóły w AWS Backup Developer Guide.

W chwili pisania tego artykułu Aurora umożliwia wykonywanie kopii zapasowych między regionami lub między kontami, ale nie obu. W przypadku migawek Aurora AWS Backup obsługuje tylko automatyzację kopii między kontami lub między regionami ze względu na sposób, w jaki te usługi tworzą swoje klucze szyfrowania. Stworzono osobny artykuł, aby pokazać klientom, jak zautomatyzować kopiowanie migawek z jednego konta AWS na inne konto w tym samym regionie AWS i kopiować kopię zapasową do innego regionu na koncie docelowym. Amazon EventBridge ułatwia zautomatyzowanie tego w jednym procesie. Migawki klastra Aurora są już szyfrowane automatycznie przy użyciu tego samego klucza szyfrowania, który był używany w oryginalnym klastrze Aurora. Migawki niezaszyfrowanych klastrów Aurora również nie są szyfrowane. Jest to łatwe do wyegzekwowania za pomocą narzędzi takich jak AWS Config. Nie ma niezależnego zarządzania szyfrowaniem AWS Backup dla Aurora, ale ważne jest, aby rozważyć swoją strategię szyfrowania, jeśli będziesz korzystać z udostępniania danych między rolami i kontami.

Wcielając strategię kopii zapasowej AWS z natywnymi funkcjami kopii zapasowej Aurora, należy wziąć pod uwagę, że inicjowanie zadań kopii zapasowej z konsoli RDS może powodować konflikty, które spowodują, że zadanie kopii zapasowej wygaśnie przed błędami ukończenia. Prostym rozwiązaniem tego problemu jest zwiększenie długości okna kopii zapasowej z poziomu AWS Backup.

Porządkowanie

Aby uniknąć przyszłych opłat, wykonaj następujące kroki, aby usunąć przykładowe zasoby:

1. Usuń źródłowy klaster Aurora DB i instancje DB, jeśli utworzyłeś je na potrzeby tego artykułu. Aby uzyskać instrukcje, zobacz Aurora User Guide.
2. Usuń plany tworzenia kopii zapasowych i punkty odzyskiwania. Aby uzyskać instrukcje, zobacz Oczyszczanie zasobów.

Wnioski

W tym artykule omówiono najczęstsze powody, dla których klienci używają AWS Backup do ochrony baz danych Aurora. Przeprowadzono również procedurę konfigurowania pierwszej kopii zapasowej baz danych oraz rozważania, o których należy pamiętać w przypadku kopii zapasowych baz danych. Klienci powinni opracować strategię obejmującą zarówno tworzenie kopii zapasowych, jak i replikację, aby spełnić szeroki zakres umów dotyczących poziomu usług biznesowych. Klienci mogą tworzyć bardziej odporne architektury, które obejmują automatyzację, szczegółowe rozdzielenie obowiązków i odtwarzalne zasady, które można monitorować i audytować.

Aby dowiedzieć się więcej o AWS Backup, zapoznaj się z dokumentacją AWS Backup. 

źródło: AWS