Udostępnij za pośrednictwem

Tworzenie i przywracanie kopii zapasowej w usłudze Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

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 określonym okresie przechowywania. Całkowity czas przywracania i odzyskiwania zwykle zależy od rozmiaru danych i ilości odzyskiwania do wykonania.

Omówienie usługi Backup

Elastyczny serwer usługi Azure Database for PostgreSQL tworzy migawki plików danych i przechowuje je bezpiecznie w magazynie strefowo nadmiarowym lub lokalnie nadmiarowym magazynie, w zależności od regionu. Serwer wykonuje również kopie zapasowe dzienników transakcji, gdy plik dziennika zapisu z wyprzedzeniem (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 elastycznych wystąpieniach serwera usługi Azure Database for PostgreSQL są oparte na migawkach. Pierwsza kopia zapasowa migawki jest planowana natychmiast po utworzeniu serwera. Kopie zapasowe migawek są obecnie wykonywane 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 każda baza danych na serwerze zostanie zmodyfikowana, zostanie natychmiast podjęta nowa migawka w celu przechwycenia najnowszych zmian. 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 celu punktu odzyskiwania (cel punktu odzyskiwania) może potrwać do 5 minut.

Opcje nadmiarowości kopii zapasowej

Serwer elastyczny usługi 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.

Serwer elastyczny usługi Azure Database for PostgreSQL oferuje trzy opcje:

  • Magazyn kopii zapasowych strefowo nadmiarowych: ta opcja jest wybierana automatycznie dla regionów obsługujących strefy dostępności. Gdy kopie zapasowe są przechowywane w magazynie kopii zapasowych geograficznie nadmiarowych, trzy kopie danych są przechowywane w regionie, w którym jest hostowany serwer. Ponadto dane są replikowane do sparowanego regionu 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,99999999999% (11 dziewiątek) trwałość obiektów kopii zapasowych w ciągu roku.

    Domyślnie magazyn kopii zapasowych dla serwerów z wysoką dostępnością w tej samej strefie lub żadna konfiguracja wysokiej dostępności nie jest ustawiona na lokalnie nadmiarową.

  • Geograficznie nadmiarowy magazyn kopii zapasowych: tę opcję można wybrać 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,999999999999999999 procent (16 dziewiątek) trwałość 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 magazynu kopii zapasowych do magazynu kopii zapasowych geograficznie nadmiarowego

Magazyn geograficznie nadmiarowy można skonfigurować tylko podczas tworzenia kopii zapasowej serwera. Po aprowizacji serwera nie można zmienić opcji nadmiarowości magazynu 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 wymagane do wykonania punktu w czasie 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

Elastyczny serwer 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 naliczane zgodnie z definicją w modelu 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 Magazyn kopii zapasowych Używany w witrynie Azure Portal, aby monitorować magazyn kopii zapasowych używany przez serwer. Metryka Użyta usługa Backup Storage reprezentuje sumę magazynu używanego przez wszystkie zachowane kopie zapasowe bazy danych i kopie zapasowe dzienników na podstawie okresu przechowywania kopii zapasowej ustawionego 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 do punktu w czasie

Na serwerze elastycznym usługi Azure Database for PostgreSQL wykonywanie przywracania do punktu w czasie tworzenia nowego serwera 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 fizycznej bazy danych są najpierw przywracane z kopii zapasowych migawek do lokalizacji danych serwera. 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, zapoznaj się z tymi krokami.

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 zdefiniowanym dla tego wystąpienia elastycznego serwera usługi 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 umożliwia użytkownikom przywrócenie serwera w najszybszym czasie w okresie przechowywania zdefiniowanym dla wystąpienia elastycznego serwera usługi Azure Database for PostgreSQL. Najszybsze przywracanie jest możliwe, bezpośrednio wybierając znacznik czasu z listy kopii zapasowych. Ta operacja przywracania aprowizuje serwer i po prostu przywraca pełną kopię zapasową migawki i nie wymaga odzyskiwania dzienników, co sprawia, że jest to szybkie. Zalecamy wybranie sygnatury czasowej kopii zapasowej, która jest większa niż najwcześniejszy punkt przywracania w czasie dla pomyślnej 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 usługi Azure Database for Azure Database for PostgreSQL — serwer elastyczny w celu odzyskania. Użyj blokady zasobów platformy Azure, aby zapobiec przypadkowemu usunięciu serwera.

Geograficznie nadmiarowa kopia zapasowa i przywracanie

Aby włączyć geograficznie nadmiarową kopię zapasową w okienku Obliczenia i magazyn w witrynie Azure Portal, zobacz przewodnik Szybki start.

Ważne

Geograficznie nadmiarowa kopia zapasowa można skonfigurować tylko w momencie tworzenia serwera.

Po skonfigurowaniu serwera przy użyciu geograficznie nadmiarowej kopii zapasowej można przywrócić go do sparowanego geograficznie regionu. Aby uzyskać więcej informacji, zobacz obsługiwane regiony dla geograficznie nadmiarowej kopii zapasowej.

Po skonfigurowaniu serwera z geograficznie nadmiarową kopią zapasową dane kopii zapasowej i dzienniki transakcji są kopiowane do sparowanego regionu asynchronicznie przez replikację magazynu. 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ą asynchroniczne kopii zapasowych kopii zapasowych do sparowanego regionu. W transmisji danych może wystąpić do jednej godziny opóźnienia. Dlatego podczas przywracania można oczekiwać do jednej godziny celu punktu odzyskiwania. Możesz przywrócić tylko dane kopii zapasowej, które są dostępne w sparowanym regionie. Obecnie usługa PITR kopii zapasowych geograficznie nadmiarowych jest niedostępna.

Szacowany czas odzyskiwania serwera (cel czasu odzyskiwania) zależy od czynników, takich jak rozmiar bazy danych, czas ostatniej kopii zapasowej bazy danych i ilość wal do przetworzenia do czasu ostatniego odebranego danych 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. Zmiana innych konfiguracji serwera , takich jak obliczenia, magazyn lub warstwa cenowa (z możliwością serii, ogólnego przeznaczenia lub zoptymalizowane pod kątem pamięci) — podczas przywracania geograficznego nie jest obsługiwana.

Aby uzyskać więcej informacji na temat wykonywania przywracania geograficznego, zobacz przewodnik z instrukcjami.

Ważne

Gdy region podstawowy nie działa, nie można utworzyć serwerów geograficznie nadmiarowych w odpowiednim regionie sparowanym geograficznie, ponieważ nie można aprowizować magazynu w regionie podstawowym. Zanim będzie można aprowizować serwery geograficznie nadmiarowe w sparowanym geograficznie regionie, musisz poczekać, aż region podstawowy będzie się znajdować.

W dół regionu podstawowego nadal można przywrócić geograficznie serwer źródłowy do sparowanego geograficznie regionu. Aby uzyskać więcej informacji na temat wykonywania przywracania geograficznego, zobacz przewodnik z instrukcjami. Jeśli konieczne jest skonfigurowanie odzyskiwania po awarii w dowolnym regionie lub jeśli region podstawowy nie obsługuje geograficznie nadmiarowych kopii zapasowych, należy użyć replik geograficznych

Przywracanie i sieć

Odzyskiwanie do 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 wykonać funkcji PITR w dostępie publicznym i prywatnym.

Przywracanie geograficzne

Jeśli serwer źródłowy jest skonfigurowany z siecią dostępu publicznego, możesz przywrócić tylko dostęp publiczny. Istniejące reguły zapory na serwerze źródłowym są kopiowane do przywróconego serwera. Prywatne punkty końcowe nie są przejmowane. Po zakończeniu operacji przywracania sprawdź, czy konieczne jest dostosowanie dowolnych przeniesionych reguł zapory i utworzenie jakichkolwiek prywatnych punktów końcowych, które mogą być potrzebne.

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 między dostępem publicznym i prywatnym.

Post-restore tasks

Po przywróceniu serwera można wykonać następujące zadania, aby umożliwić użytkownikom i aplikacjom tworzenie kopii zapasowej i uruchamianie:

  • Jeśli nowy serwer ma zastąpić oryginalny, przekieruj klientów i aplikacje klienckie na nowy serwer. Zmień nazwę serwera parametry 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 zapory na poziomie serwera, prywatne punkty końcowe i reguły sieci wirtualnej. W sieci dostępu publicznego reguły są kopiowane z oryginalnego serwera, ale te mogą nie być wymagane w przywróconym środowisku. Dostosuj je zgodnie z wymaganiami. Prywatne punkty końcowe nie są przenoszone. Utwórz wszystkie prywatne punkty końcowe, które mogą być potrzebne na przywróconym serwerze. W sieci wirtualnej z dostępem prywatnym przywracanie nie kopiuje żadnych artefaktów infrastruktury sieciowej ze źródła do przywróconych sieci serwerowych. Wszystkie elementy związane z konfiguracją sieci wirtualnej (sieci wirtualnej), podsieci lub sieciowych grup zabezpieczeń muszą być traktowane jako zadanie po przywróceniu.

  • 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 wykonać następujące kroki.

Kopie zapasowe na żądanie (wersja zapoznawcza)

Usługa Azure Database for PostgreSQL — elastyczny serwer automatycznie generuje migawki woluminu magazynu całego wystąpienia bazy danych obejmujące wszystkie bazy danych w ramach 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 na temat wykonywania kopii zapasowej na żądanie, odwiedź przewodnik z instrukcjami.

Ograniczenia

Funkcja tworzenia kopii zapasowej na żądanie nie jest obecnie obsługiwana w warstwie obliczeniowej serwera z możliwością rozszerzenia.

Znane problemy

Wiemy o istniejącej usterce, która umożliwia tworzenie kopii zapasowych na żądanie w replikach, mimo że przywracanie do punktu w czasie (PITR) nie jest obsługiwane w tym kontekście. Ten problem zostanie rozwiązany, aby upewnić się, że kopie zapasowe na żądanie mogą być wykonywane tylko na serwerze podstawowym.

Długoterminowe przechowywanie (wersja zapoznawcza)

Usługi Azure Backup i Azure Database for PostgreSQL — elastyczne usługi serwera stworzyły długoterminowe rozwiązanie do tworzenia kopii zapasowych klasy korporacyjnej dla elastycznych wystąpień serwera usługi Azure Database for PostgreSQL, które przechowuje 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 elastyczny serwer 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ą niezmienność i funkcje usuwania nietrwałego (wersja zapoznawcza) chroniące dane.
  • Obsługa kopii zapasowych LTR dla serwerów z obsługą klucza zarządzanego przez klienta

Ograniczenia i istotne zagadnienia

  • Przywracanie LTR jest obecnie dostępne tylko jako "Przywróć jako pliki" na kontach magazynu, z funkcją "Przywróć jako serwer" zaplanowaną na przyszłość.
  • Funkcja LTR wykonuje kopie zapasowe wszystkich baz danych w wystąpieniach serwera elastycznego, a dla konfiguracji LTR nie można wybrać poszczególnych baz danych.
  • Kopia zapasowa LTR nie jest obsługiwana w replikach geograficznych, ale może być wykonywana z serwerów podstawowych.
  • Maksymalny obsługiwany rozmiar bazy danych dla kopii zapasowych długoterminowego przechowywania wynosi 4 TiB. Podczas próby tworzenia kopii zapasowych na serwerach przekraczających 4 TiB nie są one oficjalnie obsługiwane, a powodzenie kopii zapasowych LTR dla takich serwerów nie może być gwarantowane.
  • Kopie zapasowe LTR można zaplanować co tydzień, co miesiąc lub co rok. Dzienny harmonogram tworzenia kopii zapasowych jest obecnie nieobsługiwany.

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 elastyczny serwer usługi Azure Database for PostgreSQL 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ę?

    L.p. Obecnie elastyczny serwer usługi Azure Database for PostgreSQL obsługuje maksymalnie 35 dni przechowywania. 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 elastycznej bazy danych serwera 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 migawki jest planowana natychmiast po utworzeniu serwera. Kolejne kopie zapasowe migawek są przyrostowe i są wykonywane raz dziennie.

  • Czy moje kopie zapasowe są szyfrowane?

    Tak. Wszystkie dane 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?

    L.p. 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 zapisuje je w:

    • Magazyn strefowo nadmiarowy w regionach, w których jest obsługiwanych wiele stref.
    • Magazyn lokalnie nadmiarowy w regionach, które nie obsługują jeszcze wielu stref.
    • Sparowany region, jeśli skonfigurujesz geograficznie nadmiarową kopię zapasową.

    Tych plików kopii zapasowych nie można eksportować.

    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 geograficznie nadmiarową kopią zapasową dane kopii zapasowej są przechowywane na koncie magazynu geograficznie nadmiarowego. Konto magazynu kopiuje pliki danych do sparowanego regionu, gdy codziennie wykonywana jest 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ę zrobić PITR w regionie zdalnym?

    L.p. Dane są odzyskiwane do danych ostatniej dostępnej kopii zapasowej w regionie zdalnym.

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

    Woluminy danych na serwerze elastycznym usługi Azure Database for PostgreSQL są tworzone za pomocą migawek przyrostowych dysków zarządzanych z serwera podstawowego. Kopia zapasowa wal jest wykonywana z serwera podstawowego lub serwera rezerwowego.

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

    Najlepszym sposobem sprawdzania kopii zapasowych jest wykonanie okresowego przywracania do punktu w czasie i upewnienie się, że kopie zapasowe są prawidłowe i 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 obszarze Magazyn kopii zapasowych Używany można monitorować łączne 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ą naliczane opłaty i naliczane opłaty za kopie zapasowe?

    Elastyczny serwer usługi Azure Database for PostgreSQL zapewnia do 100 procent aprowizowanego magazynu serwera jako magazyn kopii zapasowych bez dodatkowych kosztów. Więcej używanego magazynu kopii zapasowych jest naliczane 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 będą naliczane opłaty za zatrzymany serwer?

    Podczas zatrzymywania wystąpienia serwera nie są wykonywane żadne nowe kopie zapasowe. Opłaty są naliczane 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. Wszelkie nadmiarowe dane kopii zapasowej będą naliczane zgodnie z ceną kopii zapasowej.

  • Skonfigurowano serwer ze strefowo nadmiarową wysoką dostępnością. Czy wykonasz dwie kopie zapasowe i zostanie naliczona opłata dwa razy?

    L.p. Niezależnie od serwerów wysokiej dostępności lub nienależących do wysokiej dostępności, utrzymywany jest tylko jeden zestaw kopii zapasowych. Opłaty są naliczane tylko raz.

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

    pomoc techniczna platformy Azure pitR dla wszystkich serwerów. Użytkownicy mogą przywrócić do najnowszego punktu przywracania lub niestandardowego punktu przywracania przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure 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 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 przywracanie do punktu w czasie? Dlaczego przywracanie trwa tyle czasu?

    Operacja przywracania danych z migawki nie zależy od rozmiaru danych. Jednak czas procesu odzyskiwania, który stosuje dzienniki (działania transakcji do odtwarzania) może się różnić w zależności od poprzedniej kopii zapasowej żądanej daty/godziny i liczby dzienników do przetworzenia. Dotyczy to zarówno przywracania w tej samej strefie, jak i przywracania danych do innej strefy.

  • Czy jeśli przywracam serwer z włączoną wysoką dostępnością, czy serwer przywracania jest automatycznie skonfigurowany z wysoką dostępnością?

    L.p. Serwer jest przywracany jako pojedyncze wystąpienie usługi Azure Database for PostgreSQL — wystąpienie serwera elastycznego. 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?

    L.p. Serwer elastyczny usługi 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.

Następne kroki