Kopia zapasowa i przywracanie na elastycznym serwerze Azure Database for PostgreSQL

Tworzenie kopii zapasowych jest istotną częścią każdej strategii ciągłości działania. Pomagają chronić dane przed przypadkowym uszkodzeniem lub usunięciem.

Usługa Azure Database for PostgreSQL automatycznie wykonuje regularne kopie zapasowe serwera. Następnie możesz wykonać odzyskiwanie do punktu w czasie (PITR) w okresie przechowywania, który określisz. Całkowity czas potrzebny na przywrócenie i odzyskanie danych zwykle zależy od rozmiaru danych oraz zakresu odzyskiwania, który należy wykonać.

Omówienie usługi Backup

Usługa Azure Database for PostgreSQL tworzy kopie zapasowe migawek plików danych i przechowuje je bezpiecznie w magazynie strefowo nadmiarowym lub lokalnie nadmiarowym, w zależności od regionu. Serwer tworzy również kopie zapasowe dzienników transakcji, gdy plik WAL jest gotowy do zarchiwizowania. Użyj tych kopii zapasowych, aby przywrócić serwer do dowolnego punktu w czasie w skonfigurowanym okresie przechowywania kopii zapasowych.

Domyślny okres przechowywania kopii zapasowych wynosi siedem dni, ale okres można przedłużyć do maksymalnie 35 dni. Wszystkie kopie zapasowe są szyfrowane za pośrednictwem 256-bitowego szyfrowania AES dla danych przechowywanych w spoczynku.

Nie można eksportować tych plików kopii zapasowych ani używać ich do tworzenia serwerów spoza Azure Database for PostgreSQL wystąpienia serwera elastycznego. W tym celu można użyć narzędzi PostgreSQL pg_dump i pg_restore/psql.

Częstotliwość wykonywania kopii zapasowych

Kopie zapasowe w elastycznych wystąpieniach serwera usługi Azure Database for PostgreSQL są oparte na migawkach. Pierwsza migawka kopii zapasowej jest planowana natychmiast po utworzeniu serwera. Kopie zapasowe snapshotów są obecnie tworzone raz dziennie. Jeśli nie wprowadzisz żadnych dalszych modyfikacji żadnych baz danych na serwerze po utworzeniu ostatniej kopii zapasowej migawki, system tymczasowo zawiesza kopie zapasowe migawek. Gdy tylko zmodyfikujesz dowolną bazę danych na serwerze, system natychmiast przechwytuje najnowsze zmiany. Pierwsza migawka to pełna kopia zapasowa, a kolejne migawki to różnicowe kopie zapasowe.

Kopie zapasowe dziennika transakcji są wykonywane z różną częstotliwością, w zależności od obciążenia i tego, kiedy plik WAL jest wypełniony i gotowy do archiwizacji. Ogólnie opóźnienie RPO (cel punktu odzyskiwania) może wynosić do pięciu minut.

Opcje nadmiarowości kopii zapasowej

Usługa Azure Database for PostgreSQL przechowuje wiele kopii kopii zapasowych, aby chronić dane przed zaplanowanymi i nieplanowanymi zdarzeniami. Te zdarzenia mogą obejmować przejściowe awarie sprzętu, awarie sieci lub zasilania oraz klęski żywiołowe. Nadmiarowość kopii zapasowych pomaga zapewnić, że baza danych spełnia jej cele dostępności i trwałości, nawet jeśli wystąpią awarie.

Usługa Azure Database for PostgreSQL oferuje trzy opcje:

• Magazyn kopii zapasowych nadmiarowy między strefami: Azure Database for PostgreSQL automatycznie wybiera tę opcję w regionach, które obsługują strefy dostępności. Podczas przechowywania kopii zapasowych w magazynie kopii zapasowych strefowo nadmiarowych usługa przechowuje trzy kopie danych w strefie dostępności, w której jest hostowany serwer. Ponadto usługa replikuje dane do innej strefy dostępności w celu zapewnienia dodatkowej ochrony.

  Ta opcja zapewnia dostępność danych kopii zapasowych w różnych strefach dostępności i ogranicza replikację danych do kraju lub regionu w celu spełnienia wymagań dotyczących przechowywania danych. Zapewnia co najmniej 99,9999999999% (12 dziewiątek) trwałości obiektów kopii zapasowej w skali roku.

• Lokalnie nadmiarowy magazyn kopii zapasowych: Azure Database for PostgreSQL automatycznie wybiera tę opcję dla regionów, które nie obsługują jeszcze stref dostępności. W przypadku przechowywania kopii zapasowych w magazynie kopii zapasowych lokalnie nadmiarowych usługa przechowuje wiele kopii kopii zapasowych w tym samym centrum danych.

  Ta opcja pomaga chronić dane przed awariami stojaka serwera i stacji dysków. Zapewnia co najmniej 99,999999999% (11 dziewiątek) trwałość obiektów kopii zapasowych przez rok.

  Domyślnie usługa ustawia magazyn kopii zapasowych jako lokalnie nadmiarowy dla serwerów z wysoką dostępnością (HA) w tej samej strefie lub bez konfiguracji wysokiej dostępności.

• Georedundantna pamięć masowa kopii zapasowych: Można wybrać tę opcję podczas tworzenia serwera. W przypadku przechowywania kopii zapasowych w magazynie kopii zapasowych geograficznie nadmiarowych oprócz trzech kopii danych przechowywanych w regionie, w którym jest hostowany serwer, usługa replikuje dane do sparowanego geograficznie regionu.

  Ta opcja umożliwia przywrócenie serwera w innym regionie w przypadku awarii. Zapewnia również co najmniej 99,99999999999999 procent (16 dziewiątek) trwałości obiektów kopii zapasowych w ciągu roku.

  Nadmiarowość geograficzna jest obsługiwana w przypadku serwerów hostowanych w dowolnym z sparowanych regionów platformy Azure.

Przenoszenie z innych opcji magazynowania kopii zapasowych do georedundantnego magazynu kopii zapasowych

Georedundantne przechowywanie można skonfigurować tylko dla kopii zapasowej podczas tworzenia serwera. Po udostępnieniu serwera nie można zmienić opcji redundancji pamięci kopii zapasowych.

Przechowywanie kopii zapasowej

Serwer zachowuje kopie zapasowe na podstawie ustawionego okresu przechowywania. Możesz wybrać okres przechowywania z zakresu od 7 (domyślnie) do 35 dni. Ustaw okres przechowywania podczas tworzenia serwera lub zmień go później. Serwer zachowuje kopie zapasowe nawet dla zatrzymanych serwerów.

Okres przechowywania kopii zapasowych określa, jak daleko wstecz można wykonać przywrócenie do określonego punktu w czasie (PITR) z dostępnych kopii zapasowych. Okres przechowywania kopii zapasowej można również wziąć pod uwagę jako okno odzyskiwania z perspektywy przywracania.

Magazyn kopii zapasowych przechowuje wszystkie kopie zapasowe wymagane do wykonania PITR w okresie przechowywania kopii zapasowych. Jeśli na przykład ustawisz okres przechowywania kopii zapasowej na 7 dni, okno odzyskiwania to ostatnie 7 dni. W tym scenariuszu magazyn kopii zapasowych zachowuje wszystkie dane i dzienniki wymagane do przywrócenia i odzyskania serwera w ciągu ostatnich 7 dni.

Koszt magazynu kopii zapasowych

Usługa Azure Database for PostgreSQL zapewnia do 100 procent aprowizowanego magazynu serwera jako magazyn kopii zapasowych bez dodatkowych kosztów. Płacisz za dodatkowy magazyn kopii zapasowych używany w gigabajtach miesięcznie.

Jeśli na przykład aprowizujesz serwer z 250 gibibajtami (GiB) magazynu, uzyskasz 250 GiB pojemności magazynu kopii zapasowych bez dodatkowych opłat. Jeśli dzienne użycie kopii zapasowej wynosi 25 GiB, możesz mieć do 10 dni bezpłatnego magazynu kopii zapasowych. Płacisz za użycie magazynu kopii zapasowych, które przekracza 250 GiB zgodnie z definicją w modelu cenowym.

W przypadku skonfigurowania serwera przy użyciu geograficznie nadmiarowej kopii zapasowej dane kopii zapasowej są również kopiowane do sparowanego regionu Azure. Dlatego rozmiar kopii zapasowej jest dwukrotnie większy niż rozmiar lokalnej kopii zapasowej. Rozliczenia są obliczane jako (2 x rozmiar lokalnej kopii zapasowej) — aprowizowany rozmiar magazynu) x cena @ gigabajty miesięcznie.

Użyj metryki Magazyn kopii zapasowych Używany w portalu Azure, aby monitorować magazyn kopii zapasowych używany przez serwer. Miara Użycia Pamięci Kopii Zapasowej reprezentuje całkowitą ilość pamięci używanej przez wszystkie zachowane kopie zapasowe baz danych oraz kopie zapasowe dzienników, zgodnie z ustawionym okresem przechowywania dla serwera.

Odzyskiwanie punktu w czasie

W wystąpieniu serwera elastycznego Azure Database for PostgreSQL wykonywanie przywracania do punktu w czasie skutkuje utworzeniem nowego serwera, który znajduje się w tym samym regionie co serwer źródłowy, ale możesz wybrać strefę dostępności. Jest on tworzony przy użyciu konfiguracji serwera źródłowego dla warstwy cenowej, generowania obliczeń, liczby rdzeni wirtualnych, rozmiaru magazynu, okresu przechowywania kopii zapasowych i opcji nadmiarowości kopii zapasowych.

Pliki fizyczne bazy danych są najpierw przywracane z kopii zapasowych wykonanych w formie migawek do lokalizacji danych na serwerze. Odpowiednia kopia zapasowa wykonana wcześniej niż żądany punkt w czasie jest automatycznie wybierana i przywracana. Następnie proces odzyskiwania rozpoczyna się przy użyciu plików WAL w celu zapewnienia spójnego stanu bazy danych.

Załóżmy na przykład, że kopie zapasowe są wykonywane o godzinie 11:00 co noc. Jeśli punkt przywracania wynosi 15 sierpnia o godzinie 10:00, zostanie przywrócona codzienna kopia zapasowa 14 sierpnia. Baza danych zostanie odzyskana do godziny 10:00 z 15 sierpnia przy użyciu kopii zapasowej dziennika transakcji od 14 sierpnia 11:00 do 15 sierpnia 10:00.

Aby przywrócić serwer bazy danych, zobacz dowolny z następujących elementów:

• Przywróć do najnowszego punktu przywracania.
• Przywróć do niestandardowego punktu przywracania.
• Przywracanie do pełnej kopii zapasowej (szybkie przywracanie).
• Przywracanie do sparowanego regionu (przywracanie geograficzne).

Funkcja PITR jest przydatna w takich scenariuszach jak w następujących sytuacjach:

• Użytkownik przypadkowo usuwa dane, tabelę lub bazę danych.
• Aplikacja przypadkowo zastępuje dobre dane z nieprawidłowymi danymi z powodu wady aplikacji.
• Chcesz sklonować serwer na potrzeby testowania, programowania lub weryfikacji danych.

Korzystając z ciągłej kopii zapasowej dzienników transakcji, można przywrócić do ostatniej transakcji. Możesz wybrać między następującymi opcjami przywracania:

• Najnowszy punkt przywracania (teraz): jest to opcja domyślna, która przywraca serwer do najnowszego punktu w czasie.

• Punkt przywracania niestandardowy: ta opcja umożliwia wybranie dowolnego punktu w czasie w okresie przechowywania zdefiniowanym dla tego elastycznego wystąpienia serwera Azure Database for PostgreSQL. Domyślnie jest automatycznie wybierana najnowsza godzina w formacie UTC. Wybór automatyczny jest przydatny, jeśli chcesz przywrócić do ostatniej zatwierdzonej transakcji do celów testowych. Opcjonalnie możesz wybrać inne dni i godziny.

• Szybki punkt przywracania: ta opcja przywraca serwer w najszybszym czasie w okresie przechowywania zdefiniowanym dla ich Azure Database for PostgreSQL wystąpienia serwera elastycznego. Najszybsze przywracanie jest możliwe, bezpośrednio wybierając znacznik czasu z listy kopii zapasowych. Ta operacja przywracania tworzy serwer i po prostu przywraca pełną kopię zapasową w postaci migawki. Nie wymaga to żadnego odzyskiwania dzienników, co sprawia, że jest to szybkie. Wybierz znacznik czasu kopii zapasowej późniejszy niż najwcześniejszy moment przywracania, aby przywracanie zakończyło się pomyślnie.

Czas wymagany do odzyskania przy użyciu najnowszych i niestandardowych opcji punktu przywracania różni się w zależności od czynników, takich jak ilość dzienników transakcji do przetworzenia od ostatniej kopii zapasowej i łączna liczba baz danych, które są odzyskiwane jednocześnie w tym samym regionie. Całkowity czas odzyskiwania zwykle trwa od kilku minut do kilku godzin.

Jeśli skonfigurujesz serwer w sieci wirtualnej, możesz przywrócić do tej samej sieci wirtualnej lub do innej sieci wirtualnej. Nie można jednak przywrócić dostępu publicznego. Podobnie, jeśli serwer został skonfigurowany z dostępem publicznym, nie można przywrócić dostępu do prywatnej sieci wirtualnej.

Georedundantna kopia zapasowa i odtwarzanie

Aby włączyć geograficznie nadmiarową kopię zapasową w okienku Obliczenia i magazyn w witrynie Azure Portal, zobacz Tworzenie bazy danych Azure Database for PostgreSQL.

Po skonfigurowaniu serwera z geograficznie redundantną kopią zapasową, można go przywrócić do geograficznie sparowanego regionu. Aby uzyskać więcej informacji, zapoznaj się z obsługiwanymi regionami dla kopii zapasowej z geograficzną redundancją.

Podczas konfigurowania serwera z geograficznie nadmiarową kopią zapasową dane kopii zapasowej i dzienniki transakcji są kopiowane do sparowanego regionu asynchronicznie za pomocą replikacji danych. Po utworzeniu serwera poczekaj co najmniej godzinę przed zainicjowaniem przywracania geograficznego. Ten okres oczekiwania umożliwia replikację pierwszego zestawu danych kopii zapasowej do sparowanego regionu.

Później dzienniki transakcji i codzienne kopie zapasowe są asynchronicznie kopiowane do sparowanego regionu. W transmisji danych może wystąpić do jednej godziny opóźnienia. Dlatego podczas przywracania należy się spodziewać do jednej godziny RPO (cel punktu odzyskiwania). Możesz przywrócić tylko do ostatnio dostępnych danych kopii zapasowej, które są dostępne w sparowanym regionie. Obecnie funkcja PITR dla kopii zapasowych z nadmiarowością geograficzną nie jest dostępna.

Szacowany czas odzyskiwania serwera (RTO - cel czasu odzyskiwania) zależy od czynników, takich jak rozmiar bazy danych, czas ostatniego wykonania kopii zapasowej bazy danych oraz ilość danych do przetworzenia przez WAL do momentu odebrania ostatniej kopii zapasowej. Ogólny czas odzyskiwania zwykle trwa od kilku minut do kilku godzin.

Podczas przywracania geograficznego można zmienić konfiguracje serwera, które obejmują ustawienia sieci wirtualnej i możliwość usunięcia geograficznie nadmiarowej kopii zapasowej z przywróconego serwera. Zmiana innych konfiguracji serwera — takich jak zasoby obliczeniowe, magazyn lub warstwa cenowa (z możliwością zwiększania wydajności, ogólnego przeznaczenia lub zoptymalizowana pod kątem pamięci) — nie jest obsługiwana podczas przywracania geograficznego.

Aby uzyskać więcej informacji, zobacz Przywracanie do sparowanego regionu (przywracanie geograficzne).

Przywracanie i sieciowanie

Odzyskiwanie punktu w czasie

Jeśli skonfigurujesz serwer źródłowy z siecią dostępu publicznego , możesz przywrócić tylko dostęp publiczny.

Jeśli skonfigurujesz serwer źródłowy z siecią wirtualną dostępu prywatnego , możesz przywrócić do tej samej sieci wirtualnej lub do innej sieci wirtualnej. Nie można przeprowadzać PITR pomiędzy dostępem publicznym a prywatnym.

Przywracanie geograficzne danych

Jeśli skonfigurujesz serwer źródłowy z siecią dostępu publicznego , możesz przywrócić tylko dostęp publiczny. Ponadto należy zastosować reguły zapory po zakończeniu operacji przywracania.

W przypadku skonfigurowania serwera źródłowego przy użyciu sieci wirtualnej z dostępem prywatnym można przywrócić tylko do innej sieci wirtualnej, ponieważ sieci wirtualne nie mogą obejmować regionów. Nie można wykonać przywracania geograficznego, gdy dostęp jest zarówno publiczny, jak i prywatny.

Zadania po przywróceniu

Po przywróceniu serwera wykonaj następujące zadania, aby przywrócić użytkownikom i aplikacjom normalne działanie:

• Jeśli nowy serwer zastąpi oryginalny serwer, przekieruj klientów i aplikacje klienckie na nowy serwer. Zmień nazwę serwera w ciągu połączenia, aby wskazać nowy serwer.

• Wartości wszystkich parametrów na oryginalnym serwerze nie są automatycznie stosowane do nowego serwera. Upewnij się, że skonfigurujesz ponownie wszystkie parametry na nowym serwerze zgodnie z wymaganiami tego nowego serwera.

• Upewnij się, że dla połączeń użytkowników obowiązują odpowiednie reguły zapory na poziomie serwera, prywatne punkty końcowe i reguły sieci wirtualnej. Te reguły nie są kopiowane z oryginalnego serwera.

• Skaluj w górę lub w dół zasoby obliczeniowe przywróconego serwera zgodnie z potrzebami.

• Upewnij się, że obowiązują odpowiednie identyfikatory logowania i uprawnienia na poziomie bazy danych.

• Skonfiguruj odpowiednie alerty.

• Jeśli przywrócony serwer źródłowy został skonfigurowany z wysoką dostępnością i chcesz skonfigurować przywrócony serwer o wysokiej dostępności, wykonaj następujące kroki.

• Jeśli serwer źródłowy, z którego przywrócono, został skonfigurowany z replikami do odczytu i chcesz skonfigurować repliki do odczytu na przywróconym serwerze, postępuj zgodnie z instrukcjami w temacie Tworzenie repliki do odczytu.

Kopie zapasowe na żądanie

Twoje elastyczne wystąpienie serwera Azure Database for PostgreSQL automatycznie generuje migawki woluminów pamięci masowej całego serwera bazy danych, obejmujące wszystkie bazy danych, w ramach zaplanowanych backupów. Ponadto możesz utworzyć kopię zapasową na żądanie zawsze wtedy, gdy jest to konieczne. Ta opcja jest idealna w scenariuszach, takich jak przygotowanie do potencjalnie ryzykownej operacji lub okresowe odświeżanie poza zwykłym harmonogramem tworzenia kopii zapasowych.

Tworzenie kopii zapasowych na żądanie oprócz zaplanowanych automatycznych kopii zapasowych. Okno przechowywania kopii zapasowych określa czas przechowywania tych kopii zapasowych. Kopie zapasowe na żądanie można usuwać w dowolnym momencie, jeśli nie są już potrzebne. Aby zainicjować tworzenie kopii zapasowej na żądanie, wybierz wystąpienie bazy danych, którego kopię zapasową chcesz utworzyć, i określ nazwę kopii zapasowej. Te kopie zapasowe są przechowywane obok automatycznych kopii zapasowych, ale tylko użytkownicy mogą usuwać kopie zapasowe na żądanie. Usługa zarządza automatycznymi kopiami zapasowymi i zachowuje je w celu spełnienia wymagań dotyczących przechowywania kopii zapasowych.

Aby uzyskać więcej informacji, zobacz Wykonywanie kopii zapasowych na żądanie.

Ograniczenia

• Warstwa obliczeniowa serwera Burstable nie obsługuje funkcji kopii zapasowej na żądanie.
• Warstwa magazynowania SSDv2 nie obsługuje funkcji tworzenia kopii zapasowych na żądanie.
• Możesz utworzyć maksymalnie siedem kopii zapasowych na żądanie dla jednego wystąpienia elastycznego serwera. Okno przechowywania kopii zapasowych określa czas przechowywania tych kopii zapasowych.

Długoterminowe przechowywanie

Usługi Azure Backup i Azure Database for PostgreSQL zapewniają korporacyjne rozwiązanie do długoterminowego tworzenia kopii zapasowych dla wystąpień serwera elastycznego usługi Azure Database for PostgreSQL, umożliwiające przechowywanie kopii zapasowych nawet przez 10 lat. Długoterminowe przechowywanie (LTR) można używać niezależnie lub obok rozwiązania do automatycznego tworzenia kopii zapasowych oferowanego przez Azure Database for PostgreSQL, co zapewnia okres przechowywania do 35 dni. Automatyczne kopie zapasowe są fizycznymi kopiami zapasowymi dostosowanymi do odzyskiwania operacyjnego, szczególnie w przypadku przywracania z najnowszych kopii zapasowych. Długoterminowe kopie zapasowe pomagają spełnić wymagania dotyczące zgodności, są bardziej szczegółowe i są tworzone jako kopie zapasowe logiczne przy użyciu natywnego pg_dump. Oprócz długoterminowego przechowywania rozwiązanie oferuje następujące możliwości:

• Kontrolowane przez klienta, zaplanowane i tworzone na żądanie kopie zapasowe na poziomie poszczególnych baz danych.
• Centralne monitorowanie wszystkich operacji i zadań.
• Kopie zapasowe są przechowywane w oddzielnych domenach zabezpieczeń i błędów. W przypadku naruszenia zabezpieczeń serwera źródłowego lub subskrypcji kopie zapasowe pozostaną bezpieczne w magazynie kopii zapasowych (na zarządzanych kontach magazynu usługi Azure Backup).
• Korzystanie z pg_dump zapewnia większą elastyczność przywracania danych w różnych wersjach bazy danych.
• Magazyny usługi Azure Backup obsługują funkcje niezmienialności i miękkiego usuwania (wersja zapoznawcza), które chronią Twoje dane.
• Obsługa kopii zapasowych LTR dla serwerów z obsługą CMK (klucza zarządzanego przez klienta).

Ograniczenia i zagadnienia

• Przetestuj kopię zapasową LTR i przywróć ją natychmiast po konfiguracji, aby upewnić się, że spełniają one wymagania biznesowe.
• Przywracanie LTR jest obecnie dostępne tylko jako Przywracanie jako pliki na kontach magazynu, z funkcją Przywróć jako serwer zaplanowaną na przyszłość.
• LTR tworzy kopie zapasowe wszystkich baz danych w elastycznych wystąpieniach serwera i nie można wybrać pojedynczych baz danych do konfiguracji LTR.
• Kopia zapasowa LTR nie jest obsługiwana w replikach, ale można ją wykonywać na serwerach podstawowych.
• Maksymalny obsługiwany rozmiar bazy danych dla kopii zapasowych długoterminowego przechowywania wynosi 1 TiB.
• Kopie zapasowe LTR można zaplanować co tydzień, co miesiąc lub co rok. Dzienny harmonogram tworzenia kopii zapasowych nie jest obecnie obsługiwany.
• Kopie zapasowe LTR nie obsługują tabel zawierających wiersz o długości BYTEA przekraczającej 500 MB.
• Podczas przywracania ról dla użytkowników Microsoft Entra upewnij się, że włączono uwierzytelnianie Microsoft Entra i że zalogowano się jako administrator Microsoft Entra w celu utworzenia dodatkowych użytkowników. Próba utworzenia ról Entra jako zwykłego użytkownika powoduje błędy.

Aby uzyskać więcej informacji na temat wykonywania długoterminowej kopii zapasowej, zobacz przewodnik z instrukcjami.

Najczęściej zadawane pytania

Pytania dotyczące kopii zapasowej

• Jak platforma Azure obsługuje tworzenie kopii zapasowych serwera?

  Domyślnie Azure Database for PostgreSQL umożliwia automatyczne tworzenie kopii zapasowych całego serwera (obejmujące wszystkie utworzone bazy danych) z domyślnym okresem przechowywania przez siedem dni. Automatyczne kopie zapasowe obejmują codzienną przyrostową migawkę bazy danych. Pliki dziennika (WAL) są stale archiwizowane w usłudze Azure Blob Storage.

• Czy mogę skonfigurować automatyczne kopie zapasowe, aby przechowywać dane na dłuższą metę?

  Nie. Obecnie usługa Azure Database for PostgreSQL obsługuje okres przechowywania maksymalnie 35 dni. Użyj ręcznych kopii zapasowych na potrzeby długoterminowego przechowywania przy użyciu Azure Backup.

• Jak mogę ręcznie utworzyć kopię zapasową wystąpień serwera elastycznego usługi Azure Database for PostgreSQL?

  Możesz ręcznie utworzyć migawkę fizyczną za pomocą funkcji tworzenia kopii zapasowej na żądanie. Można również tworzyć kopie zapasowe logiczne przy użyciu narzędzia PostgreSQL pg_dump. Aby zapoznać się z przykładami, zobacz Migrowanie bazy danych usługi Azure Database for PostgreSQL przy użyciu zrzutu i przywracania.

• Jakie są okna kopii zapasowej serwera? Czy mogę je dostosować?

  Platforma Azure zarządza oknami kopii zapasowych i nie można ich dostosować. Pierwsza pełna kopia zapasowa w postaci migawki jest zaplanowana bezpośrednio po utworzeniu serwera. Kolejne kopie zapasowe migawek są przyrostowe i są wykonywane raz dziennie.

• Czy moje kopie zapasowe są szyfrowane?

  Tak. Wszystkie dane wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL, kopie zapasowe i pliki tymczasowe tworzone podczas wykonywania zapytań są szyfrowane za pośrednictwem 256-bitowego szyfrowania AES (Advanced Encryption Standard). Szyfrowanie magazynu jest zawsze włączone i nie można go wyłączyć.

• Czy mogę przywrócić pojedynczą bazę danych lub kilka baz danych na serwerze?

  Przywracanie pojedynczej bazy danych lub kilku baz danych lub tabel nie jest bezpośrednio obsługiwane. Można jednak przywrócić cały serwer na nowy serwer, a następnie usunąć tabele lub bazy danych, których nie potrzebujesz na nowym serwerze.

• Czy mój serwer jest dostępny, gdy trwa tworzenie kopii zapasowej?

  Tak. Kopie zapasowe to operacje online korzystające z migawek. Operacja migawki trwa tylko kilka sekund i nie zakłóca obciążeń produkcyjnych, aby zapewnić wysoką dostępność serwera.

• Czy podczas konfigurowania okna obsługi serwera należy uwzględnić okno tworzenia kopii zapasowej?

  Nie. Kopie zapasowe są wyzwalane wewnętrznie w ramach usługi zarządzanej i nie mają wpływu na okno obsługi.

• Gdzie są przechowywane automatyczne kopie zapasowe i jak mogę zarządzać ich przechowywaniem?

  Instancja elastycznego serwera w Azure Database for PostgreSQL automatycznie tworzy kopie zapasowe serwera i je przechowuje:

  • Nadmiarowa pamięć magazynowa z podziałem na strefy w regionach, gdzie obsługiwanych jest wiele stref.
  • Lokalnie redundantna pamięć masowa w regionach, które nie obsługują jeszcze wielu stref.
  • Sparowany region, jeśli skonfigurujesz geograficznie redundantną kopię zapasową.

  Nie można wyeksportować tych plików kopii zapasowych, ponieważ są one przechowywane na kontach magazynu zarządzanego Microsoft. Masz dostęp tylko do odczytu, aby przywrócić te pliki, ale nie można ich modyfikować ani usuwać. Pliki kopii zapasowej są automatycznie usuwane po okresie przechowywania.

  Możesz użyć kopii zapasowych, aby przywrócić serwer tylko do punktu w czasie. Domyślny okres przechowywania kopii zapasowych wynosi siedem dni. Opcjonalnie możesz skonfigurować przechowywanie kopii zapasowych do 35 dni.

• W przypadku geograficznie nadmiarowej kopii zapasowej jak często kopia zapasowa jest kopiowana do sparowanego regionu?

  Podczas konfigurowania serwera z geograficznie nadmiarową kopią zapasową dane kopii zapasowej są przechowywane na koncie magazynu geograficznie nadmiarowego. Konto magazynowe kopiuje pliki danych do sparowanego regionu, kiedy wykonywana jest codzienna kopia zapasowa na serwerze podstawowym. Kopie zapasowe plików WAL są tworzone, gdy są gotowe do zarchiwizowania.

  Dane kopii zapasowej są asynchronicznie kopiowane w sposób ciągły do sparowanego regionu. W przypadku odbierania danych kopii zapasowej można spodziewać się maksymalnie jednej godziny opóźnienia.

• Czy mogę przeprowadzić PITR w regionie zdalnym?

  Nie. Dane są odzyskiwane do ostatniej dostępnej kopii zapasowej danych w lokalizacji zdalnej.

• W jaki sposób kopie zapasowe są wykonywane na serwerach z włączoną wysoką dostępnością?

  Kopie zapasowe woluminów danych w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL są tworzone za pośrednictwem migawek przyrostowych dysku zarządzanego z serwera podstawowego. Kopia zapasowa WAL jest wykonywana z serwera podstawowego lub serwera zapasowego.

• Jak sprawdzić, czy kopie zapasowe są wykonywane na moim serwerze?

  Najlepszym sposobem sprawdzania kopii zapasowych jest okresowe wykonywanie przywracania do punktu w czasie (PITR) i upewnienie się, że kopie zapasowe są prawidłowe oraz możliwe do przywrócenia. Operacje tworzenia kopii zapasowych lub pliki nie są widoczne dla użytkowników końcowych.

• Gdzie mogę zobaczyć użycie kopii zapasowej?

  W witrynie Azure Portal w obszarze Monitorowanie wybierz pozycję Metryki. W Wykorzystanym miejscu na kopie zapasowe można monitorować całkowite użycie kopii zapasowych.

• Co się stanie z moimi kopiami zapasowymi w przypadku usunięcia serwera?

  Jeśli usuniesz serwer, wszystkie kopie zapasowe należące do serwera również zostaną usunięte i nie można ich odzyskać. Aby chronić zasoby serwera przed przypadkowym usunięciem lub nieoczekiwanymi zmianami po wdrożeniu, administratorzy mogą używać blokad zarządzania.

• W jaki sposób kopie zapasowe są przechowywane dla zatrzymanych serwerów?

  Dla zatrzymanych serwerów nie są wykonywane żadne nowe kopie zapasowe. Usługa zachowuje wszystkie starsze kopie zapasowe (w oknie przechowywania) w momencie zatrzymania serwera do momentu ponownego uruchomienia serwera. Następnie przechowywanie kopii zapasowych dla aktywnego serwera jest zarządzane przez okno przechowywania.

• W jaki sposób są naliczane opłaty i wystawiane rachunki za moje kopie zapasowe?

  Usługa Azure Database for PostgreSQL zapewnia do 100 procent aprowizowanego magazynu serwera jako magazyn kopii zapasowych bez dodatkowych kosztów. Płacisz za dodatkowy używany magazyn kopii zapasowych, który jest naliczany w gigabajtach miesięcznie, zgodnie z definicją w modelu cenowym.

  Opcja okresu przechowywania kopii zapasowych i nadmiarowości kopii zapasowych wybrana wraz z działaniami transakcyjnymi na serwerze ma bezpośredni wpływ na łączny magazyn kopii zapasowych i rozliczenia.

• Jak są naliczane opłaty za zatrzymany serwer?

  Podczas gdy wystąpienie serwera jest zatrzymane, nie są wykonywane żadne nowe kopie zapasowe. Płacisz za aprowizowany magazyn i magazyn kopii zapasowych (kopie zapasowe przechowywane w określonym oknie przechowywania).

  Bezpłatny magazyn kopii zapasowych jest ograniczony do rozmiaru aprowizowanej bazy danych. Płacisz za wszelkie nadmiarowe dane kopii zapasowej zgodnie z ceną kopii zapasowej.

• Skonfigurowałem swój serwer z wysoką dostępnością z redundancją strefową. Czy wykonasz dwie kopie zapasowe i czy zostanie naliczona opłata podwójnie?

  Nie. Niezależnie od tego, czy są to serwery HA, czy serwery inne niż HA, usługa utrzymuje tylko jeden zestaw kopii zapasowych. Płacisz tylko raz.

Pytania dotyczące przywracania

• Jak mogę przywrócić mój serwer?

  Platforma Azure obsługuje PITR dla wszystkich serwerów. Możesz przywrócić do najnowszego punktu przywracania lub niestandardowego punktu przywracania przy użyciu portalu Azure, Azure CLI i interfejsu API.

  Aby przywrócić serwer z ręcznych kopii zapasowych przy użyciu narzędzi takich jak pg_dump, możesz najpierw utworzyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL, a następnie przywrócić bazy danych do serwera przy użyciu pg_restore.

• Czy mogę przywrócić do innej strefy dostępności w tym samym regionie?

  Tak. Jeśli region obsługuje wiele stref dostępności, kopia zapasowa jest przechowywana na koncie magazynu strefowo nadmiarowego, aby można było przywrócić do innej strefy.

• Jak długo trwa PITR? Dlaczego przywracanie trwa tak długo?

  Operacja przywracania danych z migawki nie zależy od rozmiaru danych. Jednak czas procesu odzyskiwania, podczas którego odtwarzane są dzienniki transakcji (transakcje do ponownego odtworzenia), może się różnić w zależności od kopii zapasowej poprzedzającej żądaną datę i godzinę oraz liczby dzienników do przetworzenia. Ten warunek ma zastosowanie zarówno do przywracania w tej samej strefie, jak i przywracania danych do innej strefy.

• Czy gdy przywracam serwer z włączoną wysoką dostępnością, serwer ten jest automatycznie skonfigurowany na wysoką dostępność?

  Nie. Serwer jest przywracany jako pojedyncze wystąpienie elastycznego serwera Azure Database for PostgreSQL. Po zakończeniu przywracania można opcjonalnie skonfigurować serwer z wysoką dostępnością.

• Skonfigurowano serwer w sieci wirtualnej. Czy mogę przywrócić do innej sieci wirtualnej?

  Tak. W momencie przywracania wybierz inną sieć wirtualną do przywrócenia.

• Czy mogę przywrócić publiczny serwer dostępu do sieci wirtualnej lub odwrotnie?

  Nie. Usługa Azure Database for PostgreSQL obecnie nie obsługuje przywracania serwerów w dostępie publicznym i prywatnym.

• Jak mogę śledzić moją operację przywracania?

  Obecnie nie ma możliwości śledzenia operacji przywracania. Możesz monitorować dziennik aktywności, aby sprawdzić, czy operacja jest w toku, czy zakończona.

Treści powiązane

• Przywróć do najnowszego punktu przywracania.
• Przywróć do niestandardowego punktu przywracania.
• Przywracanie do pełnej kopii zapasowej (szybkie przywracanie).
• Przywracanie do sparowanego regionu (przywracanie geograficzne).