Udostępnij za pośrednictwem

Kopia zapasowa i przywracanie na elastycznym serwerze Azure Database for PostgreSQL

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Kopie zapasowe stanowią istotną część każdej strategii ciągłości działania. Pomagają chronić dane przed przypadkowym uszkodzeniem lub usunięciem.

Serwer elastyczny usługi 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 przywracania i odzyskiwania zwykle zależy od rozmiaru danych i ilości odzyskiwania do wykonania.

Omówienie usługi Backup

Serwer elastyczny usługi Azure Database for PostgreSQL tworzy kopie zapasowe 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. Za pomocą tych kopii zapasowych można przywrócić serwer do dowolnego punktu w czasie w skonfigurowanym okresie przechowywania kopii zapasowych.

Domyślny okres przechowywania kopii zapasowych wynosi 7 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.

Tych plików kopii zapasowych nie można eksportować ani używać do tworzenia serwerów spoza serwera elastycznego usługi Azure Database for PostgreSQL. W tym celu można użyć narzędzi PostgreSQL pg_dump i pg_restore/psql.

Częstotliwość wykonywania kopii zapasowych

Kopie zapasowe w wystąpieniach serwera elastycznego 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 żadne dalsze modyfikacje nie zostaną wprowadzone do żadnych baz danych na serwerze po utworzeniu ostatniej kopii zapasowej migawki, kopie zapasowe migawek są tymczasowo zawieszone. Gdy tylko jakakolwiek baza danych na serwerze zostanie zmodyfikowana, natychmiast zostanie wykonana nowa migawka, aby uchwycić 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 rzecz biorąc, opóźnienie RPO (cel punktu odzyskiwania) może wynosić do 5 minut.

Opcje nadmiarowości kopii zapasowej

Usługa Azure Database for PostgreSQL Flexible Server przechowuje wiele kopii zapasowych, aby chronić Twoje dane przed zdarzeniami planowanymi i nieplanowanymi. 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 — serwer elastyczny oferuje trzy opcje:

  • Magazyn kopii zapasowych z nadmiarowością strefową: Ta opcja jest automatycznie wybierana dla regionów obsługujących strefy dostępności. Gdy kopie zapasowe są przechowywane w magazynie kopii zapasowych strefowo nadmiarowych, trzy kopie danych są przechowywane w strefie dostępności, w której jest hostowany serwer. Ponadto dane są replikowane 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/regionu w celu spełnienia wymagań dotyczących rezydencji danych. Ta opcja zapewnia co najmniej 99,999999999999% (12 dziewiątek) trwałość obiektów kopii zapasowych w ciągu roku.

  • Lokalnie nadmiarowy magazyn kopii zapasowych: ta opcja jest automatycznie wybierana dla regionów, które nie obsługują jeszcze stref dostępności. Gdy kopie zapasowe są przechowywane w lokalnie nadmiarowym magazynie kopii zapasowych, wiele kopii kopii zapasowych jest przechowywanych 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 magazyn kopii zapasowych dla serwerów z wysoką dostępnością w tej samej strefie lub bez konfiguracji wysokiej dostępności jest ustawiony na lokalną redundancję.

  • Georedundantna pamięć masowa kopii zapasowych: Można wybrać tę opcję podczas tworzenia serwera. Gdy kopie zapasowe są przechowywane w geograficznie nadmiarowym magazynie kopii zapasowych, oprócz trzech kopii danych przechowywanych w regionie, w którym jest hostowany serwer, dane są replikowane 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ść obiektów kopii zapasowych przez rok.

    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

Kopie zapasowe są zachowywane na podstawie okresu przechowywania ustawionego dla serwera. Możesz wybrać okres przechowywania z zakresu od 7 (domyślnie) do 35 dni. Okres przechowywania można ustawić podczas tworzenia serwera lub zmienić go w późniejszym czasie. Kopie zapasowe są zachowywane nawet dla zatrzymanych serwerów.

Okres przechowywania kopii zapasowej określa przedział czasu, z którego można pobrać pitr przy użyciu dostępnych kopii zapasowych. Okres przechowywania kopii zapasowej można również traktować jako okno odzyskiwania z perspektywy przywracania.

Wszystkie kopie zapasowe niezbędne do wykonania odzyskiwania danych do określonego punktu w czasie (PITR) w okresie przechowywania kopii zapasowych są przechowywane w magazynie kopii zapasowych. Jeśli na przykład okres przechowywania kopii zapasowej jest ustawiony na 7 dni, okno odzyskiwania to ostatnie 7 dni. W tym scenariuszu są zachowywane wszystkie dane i dzienniki wymagane do przywrócenia i odzyskania serwera w ciągu ostatnich 7 dni.

Koszt magazynu kopii zapasowych

Serwer elastyczny usługi Azure Database for PostgreSQL zapewnia do 100 procent aprowizowanego magazynu serwera jako magazyn kopii zapasowych bez dodatkowych kosztów. Wszystkie dodatkowe używane magazyny kopii zapasowych są naliczane w gigabajtach miesięcznie.

Jeśli na przykład aprowizujesz serwer z 250 gibibajtami (GiB) magazynu, masz 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. Użycie magazynu kopii zapasowych przekraczające 250 GiB jest rozliczane zgodnie z modelem cenowym.

Jeśli serwer został skonfigurowany przy użyciu geograficznie nadmiarowej kopii zapasowej, dane kopii zapasowej są również kopiowane do sparowanego regionu platformy Azure. Dlatego rozmiar kopii zapasowej będzie dwukrotnie większy niż rozmiar lokalnej kopii zapasowej. Rozliczenia są obliczane jako ( (2 x rozmiar lokalnej kopii zapasowej) — rozmiar aprowizowanego magazynu ) x cena @ gigabajty miesięcznie.

Możesz użyć metryki 'Używany magazyn kopii zapasowych' 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.

Uwaga

Niezależnie od rozmiaru bazy danych duża aktywność transakcyjna na serwerze generuje więcej plików WAL. Z kolei wzrost liczby plików zwiększa magazyn kopii zapasowych.

Odzyskiwanie punktu w czasie

W usłudze Azure Database for PostgreSQL — serwer elastyczny, wykonując PITR tworzy się nowy serwer w tym samym regionie co serwer źródłowy, ale można 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 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:

Ważne

Operacja przywracania na serwerze elastycznym usługi Azure Database for PostgreSQL zawsze tworzy nowy serwer bazy danych o podanej nazwie. Nie zastępuje istniejącego serwera bazy danych.

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.

Dzięki 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 umożliwia przywrócenie serwera do najnowszego punktu w czasie.

  • Niestandardowy punkt przywracania: ta opcja umożliwia wybranie dowolnego punktu w czasie w okresie przechowywania danych zdefiniowanym dla tego wystąpienia elastycznego 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 pozwala użytkownikom przywrócić serwer w możliwie najkrótszym czasie, w ramach okresu przechowywania zdefiniowanego dla ich wystąpienia serwera elastycznego w usłudze Azure Database for PostgreSQL. Najszybsze przywracanie jest możliwe, bezpośrednio wybierając znacznik czasu z listy kopii zapasowych. Ta operacja przywracania inicjuje serwer i po prostu odtwarza pełną kopię zapasową migawki, nie wymagając odzyskiwania dzienników, co sprawia, że jest szybka. Zalecamy wybranie znacznika czasu kopii zapasowej, który jest późniejszy niż najwcześniejszy punkt przywracania, w celu pomyślnego przeprowadzenia operacji przywracania.

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 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.

Ważne

Usunięte serwery można przywrócić. Jeśli usuniesz serwer, możesz postępować zgodnie z naszymi wskazówkami Przywracanie usuniętej bazy danych Azure dla elastycznego serwera Azure Database for PostgreSQL, aby odzyskać dane. Użyj blokady zasobów platformy Azure, aby zapobiec przypadkowemu usunięciu serwera.

Georedundantne kopie zapasowe i przywracanie

Aby włączyć geograficznie nadmiarową kopię zapasową w okienku Obliczenia i magazyn w portalu Azure, zobacz Utwórz elastyczny serwer bazy danych Azure dla PostgreSQL.

Ważne

Kopię zapasową z georedundancją można skonfigurować tylko podczas tworzenia serwera.

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ą.

Po skonfigurowaniu serwera z kopią zapasową o redundancji geograficznej, dane kopii zapasowej i dzienniki transakcji są kopiowane do sparowanego regionu asynchronicznie poprzez replikację pamięci masowej. Po utworzeniu serwera poczekaj co najmniej godzinę przed zainicjowaniem przywracania geograficznego. Umożliwia to replikowanie 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 PITR kopii zapasowych z geograficzną redundancją jest niedostępne.

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 konfiguracje serwera, które można zmienić, obejmują ustawienia sieci wirtualnej i możliwość usuwania geograficznie nadmiarowej kopii zapasowej z przywróconego serwera. Podczas przywracania geograficznego nie jest obsługiwana zmiana innych konfiguracji serwera, takich jak obliczenia, magazyn lub warstwa cenowa (przerywalna, ogólnego przeznaczenia lub zoptymalizowana pod kątem pamięci).

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

Ważne

Gdy region podstawowy nie działa, nie można utworzyć serwerów geo-nadmiarowych w odpowiednim regionie sparowanym geograficznie, ponieważ nie można przydzielić pamięci masowej w regionie podstawowym. Zanim będzie można udostępnić serwery z nadmiarowością geograficzną w sparowanym geograficznie regionie, musisz poczekać, aż region podstawowy będzie dostępny.

Gdy region podstawowy jest niedostępny, można nadal geograficznie przywrócić serwer źródłowy do regionu sparowanego geograficznie. Aby uzyskać więcej informacji, zobacz Przywracanie do sparowanego regionu (przywracanie geograficzne). Należy użyć replik geograficznych jako strategii odzyskiwania po awarii (DR), jeśli konieczne jest skonfigurowanie DR w dowolnym regionie lub jeśli region podstawowy nie obsługuje kopii zapasowych z geograficzną redundancją.

Przywracanie i sieciowanie

Odzyskiwanie punktu w czasie

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

Jeśli serwer źródłowy jest skonfigurowany 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

Jeśli serwer źródłowy jest skonfigurowany 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.

Jeśli serwer źródłowy jest skonfigurowany z siecią wirtualną dostępu prywatnego, 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 można wykonać następujące zadania, aby umożliwić użytkownikom i aplikacjom ponowne działanie:

  • Jeśli nowy serwer ma zastąpić oryginalny, 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 serwera na oryginalnym serwerze nie są automatycznie stosowane do nowego serwera. Upewnij się, że wszystkie parametry serwera na nowym serwerze zostały ponownie skonfigurowane 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, możesz wykonać 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, możesz postępować zgodnie z instrukcjami w temacie Tworzenie repliki do odczytu.

Kopie zapasowe na żądanie

Azure Database for PostgreSQL Flexible Server automatycznie generuje migawki woluminu magazynu całej instancji bazy danych, obejmując wszystkie bazy danych, jako część zaplanowanych kopii zapasowych. Ponadto można utworzyć kopię zapasową na żądanie zawsze, gdy jest to konieczne, co jest idealne w scenariuszach, takich jak przygotowanie do potencjalnie ryzykownej operacji lub okresowe odświeżanie poza zwykłym harmonogramem tworzenia kopii zapasowych.

Kopie zapasowe na żądanie można wykonywać oprócz zaplanowanych automatycznych kopii zapasowych. Te kopie zapasowe są zachowywane zgodnie z oknem przechowywania kopii zapasowych. Te kopie zapasowe na żądanie można usunąć w dowolnym momencie, jeśli nie są już potrzebne. Aby zainicjować tworzenie kopii zapasowej na żądanie, po prostu wybierz wystąpienie bazy danych, którego kopię zapasową chcesz utworzyć, i określ nazwę kopii zapasowej. Te kopie zapasowe są przechowywane wraz z automatycznymi kopiami zapasowymi, ale tylko kopie zapasowe na żądanie mogą zostać usunięte przez użytkowników, ponieważ automatyczne kopie zapasowe są zarządzane i przechowywane przez usługę Serwera elastycznego w celu spełnienia wymagań dotyczących przechowywania kopii zapasowych.

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

Ograniczenia

  • Funkcja tworzenia kopii zapasowej na żądanie nie jest obecnie obsługiwana w warstwie obliczeniowej serwera Burstable.
  • Funkcja tworzenia kopii zapasowej na żądanie nie jest obecnie obsługiwana w warstwie magazynowania SSDv2.
  • Można wykonać maksymalnie 7 kopii zapasowych na żądanie dla elastycznego serwera, które są przechowywane na podstawie okna przechowywania kopii zapasowych.

Długoterminowe przechowywanie

Usługi Azure Backup i Azure Database for PostgreSQL — Serwer Elastyczny stworzyły długoterminowe rozwiązanie do tworzenia kopii zapasowych klasy korporacyjnej dla wystąpień Serwera Elastycznego usługi Azure Database for PostgreSQL, przechowujące kopie zapasowe przez maksymalnie 10 lat. Można użyć przechowywania długoterminowego (LTR) niezależnie lub oprócz zautomatyzowanego rozwiązania do tworzenia kopii zapasowych oferowanego przez serwer elastyczny usługi Azure Database for PostgreSQL, który oferuje 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 ułatwiają spełnienie wymagań dotyczących 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).
  • Użycie pg_dump umożliwia 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 istotne zagadnienia

  • Zdecydowanie zaleca się przetestowanie kopii zapasowej LTR i przywrócenie bezpośrednio po konfiguracji, aby upewnić się, że spełniają one wymagania biznesowe.
  • Przywracanie LTR jest obecnie dostępne tylko jako "Przywróć jako pliki" na kontach magazynowych, z funkcją "Przywróć jako serwer" przewidzianą na przyszłość.
  • LTR wykonuje kopie zapasowe wszystkich baz danych w wystąpieniach serwerów elastycznych; nie można wybrać poszczególnych baz danych do konfiguracji LTR.
  • Kopia zapasowa LTR nie jest obsługiwana w replikach. 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 jest obecnie nieobsł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 jesteś zalogowany jako administrator Microsoft Entra, aby móc tworzyć dodatkowych użytkowników. Próba utworzenia ról Entra jako zwykłego użytkownika spowoduje błędy.

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

Często zadawane pytania

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

    Domyślnie usługa Azure Database for PostgreSQL — elastyczny serwer umożliwia automatyczne tworzenie kopii zapasowych całego serwera (obejmującego wszystkie utworzone bazy danych) z domyślnym okresem przechowywania 7 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ę?

    Nr. Obecnie Azure Database for PostgreSQL Flexible Server obsługuje maksymalnie 35 dni retencji. Możesz użyć ręcznych kopii zapasowych na potrzeby długoterminowego przechowywania przy użyciu usługi Azure Backup.

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

    Migawkę fizyczną można wykonać ręcznie przy użyciu funkcji tworzenia kopii zapasowych na żądanie. Możesz również wykonywać 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 — serwer elastyczny 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, kopie zapasowe i tymczasowe pliki serwera elastycznego usługi Azure Database for PostgreSQL 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?

    Nr. 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?

    Serwer elastyczny usługi Azure Database for PostgreSQL automatycznie tworzy kopie zapasowe serwera i przechowuje je w:

    • 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ą.

    Tych plików kopii zapasowych nie można eksportować, ponieważ są one przechowywane na kontach magazynu zarządzanego przez firmę Microsoft. Klienci mają dostęp tylko do odczytu w celu przywrócenia tych plików, ale nie mogą 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 zapasowej to 7 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?

    Po skonfigurowaniu serwera z georedundantną kopią zapasową, dane są przechowywane na koncie magazynu georedundantnego. 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?

    Nr. 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ą?

    Woluminy danych w elastycznym serwerze usługi Azure Database for PostgreSQL są tworzone przy użyciu migawek przyrostowych dysków zarządzanych 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 i pliki kopii zapasowej 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. Wszystkie starsze kopie zapasowe (w oknie przechowywania) w momencie zatrzymania serwera są zachowywane do momentu ponownego uruchomienia serwera. Następnie przechowywanie kopii zapasowych dla aktywnego serwera jest zarządzane przez okno przechowywania.

  • Jak będę obciążony i rozliczany za kopie zapasowe?

    Serwer elastyczny usługi Azure Database for PostgreSQL zapewnia do 100 procent aprowizowanego magazynu serwera jako magazyn kopii zapasowych bez dodatkowych kosztów. Każdy dodatkowy magazyn kopii zapasowych, który używasz, jest rozliczany na podstawie ilości gigabajtów 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 będą naliczane opłaty za zatrzymany serwer?

    Podczas gdy wystąpienie serwera jest zatrzymane, nie są wykonywane żadne nowe kopie zapasowe. Opłaty są naliczane za przydzielony magazyn i magazyn kopii zapasowych (kopie zapasowe przechowywane w określonym okresie przechowywania).

    Bezpłatny magazyn kopii zapasowych jest ograniczony do rozmiaru aprowizowanej bazy danych. Wszelkie nadmiarowe dane kopii zapasowej będą naliczane 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?

    Nr. Niezależnie od serwerów HA lub nie-HA, przechowywany jest tylko jeden zestaw kopii zapasowych. Opłaty są naliczane tylko raz.

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

    Platforma Azure obsługuje PITR dla wszystkich serwerów. Użytkownicy mogą przywrócić do najnowszego punktu przywracania lub niestandardowego punktu przywracania przy użyciu Azure Portal, interfejsu wiersza polecenia platformy Azure i API.

    Aby przywrócić serwer z ręcznych kopii zapasowych przy użyciu narzędzi takich jak pg_dump, możesz najpierw utworzyć instancję elastycznego serwera usługi Azure Database for PostgreSQL, a następnie przywrócić bazy danych na serwer 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, który stosuje dzienniki (odtwarzanie działań transakcyjnych), może się różnić w zależności od poprzedniej kopii zapasowej z żądanego dnia/godziny oraz od liczby dzienników do przetworzenia. Dotyczy to zarówno 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ść?

    Nr. Serwer jest przywracany jako pojedyncze wystąpienie Azure Database for PostgreSQL — serwer elastyczny. 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?

    Nr. Usługa Azure Database for PostgreSQL — Elastyczny Serwer obecnie nie obsługuje przywracania serwerów pomiędzy dostępem publicznym a 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.

Powiązana zawartość