Strategie tworzenia kopii zapasowych dla Amazon DynamoDB

Jednym z najważniejszych pytań podczas omawiania baz danych jest „Jak będziemy tworzyć kopie zapasowe i przywracać nasze dane?” Kopie zapasowe są centralnym elementem każdej strategii odzyskiwania po awarii i są przede wszystkim zarządzane przez Recovery Point Objective (RPO) i Recovery Time Objective (RTO). Chcesz mieć pewność, że Twoja strategia tworzenia kopii zapasowych spełnia Twoje potrzeby przy minimalnym nakładzie administracyjnym, nie zakłóca działalności biznesowej i jest opłacalna? W tym artykule autorzy przeglądają różne strategie tworzenia kopii zapasowych, których możesz użyć z Amazon DynamoDB, oraz najlepsze przypadki użycia dla każdej z nich.

Odzyskiwanie DynamoDB do punktu w czasie

Odzyskiwanie do punktu w czasie DynamoDB (PITR) to w pełni zarządzana funkcja ciągłego tworzenia kopii zapasowych wbudowana w DynamoDB. Po włączeniu PITR umożliwia przywrócenie tabeli do dowolnego punktu w czasie w ciągu ostatnich 35 dni z dokładnością do sekundy. Kopie zapasowe PITR są na poziomie systemu i są przechowywane na koncie zarządzanym przez AWS. Nawet jeśli Twoje konto zostanie przejęte, nieautoryzowany użytkownik nie może usunąć tej kopii zapasowej. Możesz włączyć PITR z konsoli zarządzania AWS, zestawów SDK AWS lub interfejsu wiersza poleceń AWS (AWS CLI), jak w poniższym przykładzie:

aws dynamodb update-continuous-backups --table-name <SOURCE-TABLE> -—point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

Należy pamiętać, że po włączeniu PITR nie działa wstecz. Najwcześniejszy dostępny punkt przywracania to czas, w którym aktywowano PITR.

Chociaż PITR umożliwia przywrócenie tabeli do punktu w czasie za pomocą konsoli DynamoDB lub interfejsu wiersza poleceń AWS (AWS CLI), niektóre ustawienia na poziomie tabeli źródłowej nie są automatycznie stosowane do nowo utworzonej tabeli. Obejmują one automatyczne skalowanie, strumienie, czas wygaśnięcia (TTL) i inne. Zapoznaj się z sekcją Automate update of table settings on restored Amazon DynamoDB table, aby uzyskać rozwiązanie sterowane zdarzeniami, które automatycznie zastosuje ustawienia tabeli Amazon DynamoDB do przywróconej tabeli przy użyciu szablonów AWS CloudFormation.

PITR znacznie minimalizuje ryzyko utraty danych i jest przydatny w przypadku obciążeń wrażliwych na utratę danych, ponieważ chroni przed przypadkowym usunięciem i zapisem w tabeli. Szczegółowość na sekundę ułatwia osiągnięcie rygorystycznych RPO. Patrząc na alternatywy, takie jak zaplanowane kopie zapasowe, można odzyskać tylko do ostatniego punktu kopii zapasowej, co może oznaczać wiele godzin utraty danych. Aby zapoznać się z omówieniem PITR, zapoznaj się z Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR).

Kopie zapasowe DynamoDB na żądanie

Kopie zapasowe na żądanie pozwalają nakazać DynamoDB inicjowanie tworzenia kopii zapasowych całej tabeli bez wpływu na wydajność tabeli. Możesz przywrócić poszczególne kopie zapasowe do nowych tabel za pomocą interfejsów API usługi lub konsoli. Podczas przywracania do nowej tabeli DynamoDB pozwala zachować lub zmienić ustawienia, takie jak globalne indeksy pomocnicze (GSI), lokalne indeksy dodatkowe (LSI) lub ustawienia szyfrowania.

Aby utworzyć kopię zapasową na żądanie, możesz użyć konsoli, AWS SDK dla wybranego języka programowania lub AWS CLI. Poniżej znajduje się podstawowy przykład polecenia AWS CLI do tworzenia kopii zapasowej na żądanie:

aws dynamodb create-backup --table-name <SOURCE-TABLE> --backup-name <BACKUP-NAME>

Wiele obciążeń wymaga wykonywania zaplanowanych kopii zapasowych o określonej godzinie każdego tygodnia lub dnia, co na pierwszy rzut oka może nie wydawać się cechą kopii zapasowych na żądanie. Aby uzyskać zaplanowane kopie zapasowe DynamoDB, możesz skorzystać z AWS Backup, w pełni zarządzanej i scentralizowanej usługi ochrony danych. Możesz użyć AWS Backup do tworzenia i zarządzania harmonogramami tworzenia kopii zapasowych dla tabel DynamoDB. AWS Backup umożliwia tworzenie kopii zapasowych między kontami, które zapewniają dodatkową ochronę, umożliwiając kopiowanie kopii zapasowych na inne konta AWS. Ponadto, jeśli posiadasz kopie zapasowe, które muszą być przechowywane przez długi czas ze względu na wymagania dotyczące zgodności, możesz skorzystać z cold storage, aby obniżyć koszty.

Poniżej przedstawiono kilka scenariuszy, które dobrze pasują do tworzenia kopii zapasowych na żądanie:

• Zgodność z przepisami wymaga przechowywania danych przez ponad 35 dni, na przykład przechowywanie danych przez 7 lat zgodnie z wymaganiami amerykańskiej Komisji Papierów Wartościowych i Giełd.
• Musisz skopiować tabelę między kontami AWS, takimi jak konto deweloperskie lub testowe.
• Chcesz skopiować lub przenieść swoje dane do innego regionu AWS.

Jak wybrać między PITR a kopiami zapasowymi na żądanie?

Rozważmy kilka różnych obciążeń DynamoDB:

• Obciążenie 1 – tabela DynamoDB, która zasila aplikację internetową, przy czym RPO wynosi 45 minut, a wymagania dotyczące przechowywania danych wynoszą 30 dni.
• Obciążenie 2 – tabela DynamoDB, która zasila aplikację usług finansowych z RPO wynoszącym 15 minut i wymogiem zgodności dotyczącym przechowywania danych przez 7 lat.
• Obciążenie 3 – tabela DynamoDB, która napędza aplikację badawczą. Dane w tabeli są niezmienne, ponieważ służą jako tabela przeglądowa do obsługi przebiegów symulacji przeprowadzanych przez aplikację badawczą. Ponieważ dane są niezmienne, nie ma RPO, ale odtworzenie danych jest drogie, więc nadal wymagana jest kopia zapasowa.

Przy pierwszym obciążeniu PITR może spełnić wszystkie wymagania dotyczące tworzenia kopii zapasowych. Ponieważ PITR ma szczegółowość na sekundę i 35-dniowy okres przechowywania, wymagania 45-minutowego RPO i 30-dniowego okresu przechowywania są łatwo spełnione. Drugie obciążenie jest nieco bardziej skomplikowane. Włączenie PITR spełni wymogi RPO, ale nie 7-letniego wymogu przechowywania. Tutaj możesz użyć AWS Backup w połączeniu z PITR, aby spełnić to wymaganie. Możesz użyć AWS Backup, aby zaplanować tworzenie kopii zapasowych na żądanie i przechowywać je przez 7 lat, przechowując je w cold storage, aby zaoszczędzić na kosztach. Trzecie obciążenie można wykonać za pomocą pojedynczej kopii zapasowej na żądanie, ponieważ dane są niezmienne.

Z tych przykładów możesz wyłuskać kilka ogólnych wskazówek:

• W przypadku większości tabel, zwłaszcza tych o niskim wymogu RPO, należy używać PITR.
• Jeśli masz niski RPO, ale musisz przechowywać kopie dłużej niż 35 dni, użyj kopii zapasowych na żądanie z AWS Backup w połączeniu z PITR.

Wnioski

W tym artykule poznałeś różne metody tworzenia kopii zapasowych tabel DynamoDB, które pomogą Ci spełnić wymagania dotyczące kopii zapasowych i zgodności. Aby dowiedzieć się więcej, zapoznaj się z sekcjami Working with On-Demand backup and restore oraz Working with point-in-time-recovery.

Autorzy zachęcają do wykorzystania tego artykułu jako punktu wyjścia do oceny strategii tworzenia kopii zapasowych DynamoDB i zapraszają do pozostawienia pytań lub uwag w sekcji komentarzy.

Źródło: AWS