Support Matrix for Azure PostgreSQL flexible server and elastic cluster vaulted backup (v2) (preview)

Azure Backup pozwala chronić elastyczne serwery Azure PostgreSQL oraz klastry elastyczne za pomocą fizycznych (dyskowych snapshotów) kopii zapasowych. Ten artykuł podsumowuje obsługiwane regiony, scenariusze, konfiguracje oraz ograniczenia doświadczenia v2.

Obsługiwane regiony dla Azure PostgreSQL flexible server oraz elastic cluster vaulted backup (v2)

Kopie zapasowe z archiwami są dostępne we wszystkich regionach publicznych z wyjątkiem Austria East, Belgium Central, Chile Central, Indonesia Central, Israel Northwest, Malaysia South, Malaysia West, Mexico Central, Qatar Central, South Central US 2, Southeast USA, Southeast US 3, Southeast US 5, Southwest US i West India.

Obsługiwane źródła danych i konfiguracje dla elastycznego serwera Azure PostgreSQL oraz elastycznej klastrowej vaultowanej kopii zapasowej (v2)

Poniższa tabela przedstawia obsługiwane źródła danych i konfiguracje dla elastycznego serwera Azure PostgreSQL oraz elastycznej klastrowej vaultowanej kopii zapasowej (v2):

Obsługiwane scenariusze kopii zapasowych dla Azure PostgreSQL flexible server oraz elastic cluster vaulted backup (v2)

Azure PostgreSQL flexible server oraz elastic cluster vaulted backup (v2) obsługują następujące scenariusze tworzenia kopii zapasowych:

• Cały serwer lub klaster jest zbackupowany. Nie jest obsługiwana kopia zapasowa poszczególnych baz danych.
• Obsługiwany jest klaster elastyczny do 8 węzłów.
• Pierwsza kopia zapasowa źródła danych to pełna kopia zapasowa; każda kolejna kopia jest stopniowa. Azure Backup automatycznie wykonuje początkową replikację, jeśli łańcuch snapshotów zostanie przerwany.
• Obsługiwane są harmonogramy kopii zapasowych dziennie lub tygodniowo, z minimalnym celem punktu odzyskania na poziomie jednego dnia.
• Retencja może być ustalana od 7 dni do 10 lat, z niezależnymi czasami utrzymania dla punktów codziennych, tygodniowych, miesięcznych i rocznych.
• Kopie zapasowe na żądanie (ad hoc) są obsługiwane po skonfigurowaniu ochrony.
• Obsługiwana jest jedna instancja kopii zapasowej dla każdego źródła danych. Nie jest obsługiwana wielokrotna ochrona tego samego serwera, więc serwer jest chroniony albo przez stos v1, albo przez stos v2, nigdy nie przez oba.
• Polityka kopii zapasowej powiązana z instancją kopii zapasowej może zostać zmieniona po skonfigurowaniu ochrony.
• Zadanie kopiowania kopii zapasowej jest oznaczane jako Udane, gdy snapshot zarządzanego dysku zostanie skopiowany do sejfu.
• Metadane punktów odzyskiwania, w tym wersja PostgreSQL, na której wykonano kopię zapasową, są widoczne na każdym punkcie odzyskiwania.
• Obsługiwane są kopie zapasowe WORM immutable. Gdy bezzmianność jest włączona i zablokowana w sejfie zapasowym, punkty odzyskiwania nie mogą być zmieniane, nadpisywane ani usuwane przed upływem skonfigurowanego okresu przechowywania, ani przez żadnego użytkownika, w tym administratora skarbca.

Wspierane scenariusze przywracania dla Azure PostgreSQL flexible server oraz elastic cluster vaulted backup (v2)

Azure PostgreSQL flexible server oraz elastic cluster vaulted backup (v2) wspierają następujące scenariusze przywracania:

• Przywrócenia są wykonywane jako Przywrócenie serwera do alternatywnej lokalizacji. Docelowy elastyczny serwer lub klaster elastyczny musi zostać utworzony przed uruchomieniem przywracania.
• Dane w nielogowanych tabelach nie są zachowywane i tracone podczas przywracania.
• Celem może być inna subskrypcja w obrębie tego samego tenanta.
• Obsługiwane jest przywracanie między regionami.
• Operacje przywracania z kopii zapasowych wykonanych na wersjach PostgreSQL, które nie są już wspierane, nie są gwarantowane.
• Przywracanie jest obsługiwane nawet po usunięciu źródła danych.
• Zadanie przywracania jest oznaczane jako Pomyślne dopiero wtedy, gdy cały punkt odzyskiwania został przywrócony.
• Punkt odzyskiwania pobrany na serwerze Premium SSD v1 przywraca się do celu Premium SSD v1. Punkt odzyskiwania pobrany na serwerze Premium SSD v2 przywraca się do celu Premium SSD v2.

Wymagania docelowe do przywracania

Docelowy elastyczny serwer lub klaster elastyczny musi spełniać wszystkie następujące kryteria, które Azure Backup waliduje przed rozpoczęciem operacji przywracania:

• Serwer lub klaster musi być pusty.
• Serwer lub klaster nie może znajdować się na poziomie obliczeniowym Burstable'a.
• Docelowy serwer lub klaster musi używać tej samej głównej wersji PostgreSQL co serwer źródłowy w momencie wykonywania kopii zapasowej. Przywracanie nie udaje się, jeśli wersje się nie zgadzają.
• Docelowy serwer lub klaster musi mieć taki sam rozmiar dysku jak serwer źródłowy. Przywracanie kończy się niepowodzeniem, jeśli docelowy dysk jest mniejszy niż rozmiar dysku źródłowego, mimo że punkt odzyskiwania zajmuje mniej miejsca na docelowym dysku.
• Serwer lub klaster nie może mieć skonfigurowanej wysokiej dostępności.
• Serwer lub klaster nie może mieć skonfigurowanej geo-repliki i nie może być samym geo-repliką.
• Serwer lub klaster musi znajdować się w tym samym regionie co sejf zapasowy.

Ograniczenia dla Azure PostgreSQL flexible server i elastic cluster vaulted backup (v2)

Doświadczenie v2 ma następujące ograniczenia:

• Nie jest obsługiwana kopia zapasowa i przywracanie na poziomie przedmiotów. Nie możesz zrobić kopii zapasowej ani przywrócić pojedynczej bazy danych, tabeli czy obiektu.
• Tier obliczeniowy Burstable nie jest obsługiwany. Konfiguracja kopii zapasowej na serwerze Burstable kończy się niepowodzeniem z powodu błędu użytkownika. Najpierw skaluj serwer do poziomu General Purpose lub Memory Optimized.
• PostgreSQL 14 i wcześniejsze nie są obsługiwane. Konfiguracja kopii zapasowej zawodzi dla serwerów korzystających z tych wersji. Musisz zaktualizować do obsługiwanej wersji głównej przed skonfigurowaniem kopii zapasowej lub kontynuować ochronę serwera za pomocą v1.
• Kopia zapasowa jest obsługiwana tylko dla serwerów głównych. Nie da się skonfigurować kopii zapasowej do odczytu replik ani geo-replik. Jeśli spróbujesz skonfigurować kopię zapasową dla repliki, operacja kończy się błędem użytkownika.
• Cel jednodniowego punktu odzyskania (RPO) nie jest gwarantowany we wszystkich scenariuszach. Początkowa kopia zapasowa i późniejsza replikacja przenoszą całą zawartość dysku i mogą trwać więcej niż jeden dzień w przypadku dużych serwerów i klastrów. Kopie zapasowe mogą również przekraczać jeden dzień dla serwerów z dużą dzienną liczbą odrzutów danych lub serwerów korzystających z Premium SSD v2.
• Przeniesienie chronionego przedmiotu z wersji 1 do wersji 2 to jeden ze sposobów. Aby wrócić do v1, zatrzymaj ochronę i przekonfiguruj kopię zapasową na stosie v1.
• Konfiguracja kopii zapasowej nie stosuje się automatycznie do nowego serwera głównego po planowanym geo-failoverze. Istniejąca konfiguracja kopii zapasowej pozostaje powiązana z poprzednim serwerem głównym, a jego kopie zapasowe zaczynają zawodzić po awaryjnym przełączeniu. Aby chronić nowy główny serwer, skonfiguruj kopię zapasową na tym serwerze.

Następny krok

• O Azure PostgreSQL flexible server i elastic cluster vaulted backup (v2) (preview).

Treści powiązane

• Support matrix for Azure Database for PostgreSQL - Flexible Server (v1)..