Udostępnij za pomocą

Przywracanie serwera usługi Azure PostgreSQL-Flexible jako plików przy użyciu witryny Azure Portal

W tym artykule opisano sposób przywracania serwera Azure PostgreSQL-Flexible przy użyciu plików z kopii zapasowej wykonanej przy użyciu portalu Azure.

Wymagania wstępne

Przed przywróceniem z kopii zapasowych serwera elastycznego usługi Azure Database for PostgreSQL zapoznaj się z następującymi wymaganiami wstępnymi:

  • Upewnij się, że masz wymagane uprawnienia do operacji przywracania.

  • Dane kopii zapasowej są przechowywane w skarbcu kopii zapasowych jako obiekt typu blob w dzierżawie firmy Microsoft. Podczas operacji przywracania dane kopii zapasowej są kopiowane z jednego konta magazynu do innego między tenantami. Upewnij się, że docelowe konto magazynu do przywracania ma właściwość AllowCrossTenantReplication ustawioną na true.

  • Upewnij się, że docelowe konto magazynu, na którym przywracasz kopię zapasową jako plik, jest dostępne za pośrednictwem sieci publicznej. Jeśli konto magazynu używa prywatnego punktu końcowego, zaktualizuj ustawienia dostępu do sieci publicznej przed wykonaniem operacji odzyskiwania danych.

Przywracanie usługi Azure PostgreSQL — elastyczne kopie zapasowe serwera jako pliki

Uwaga / Notatka

Operacja przywracania to proces dwuetapowy:

  1. Przywróć kopię zapasową z sejfu kopii zapasowych do kontenera magazynowego.
  2. Przywróć pliki kopii zapasowej z zasobnika pamięci do nowego lub istniejącego serwera elastycznego.

Aby przywrócić bazę danych usługi Azure PostgreSQL-Flexible, wykonaj następujące kroki:

  1. Przejdź do Skarbiec kopii zapasowej>Wystąpienia kopii zapasowych. Wybierz serwer PostgreSQL — elastyczny, który ma zostać przywrócony, a następnie wybierz pozycję Przywróć.

    Alternatywnie przejdź do centrum kopii zapasowej i wybierz pozycję Przywróć.

  2. Wybierz punkt w czasie, który chcesz przywrócić, używając Wybierz punkt przywracania. Zmień zakres dat, wybierając pozycję Okres.

  3. Wybierz docelowe konto magazynu i kontener w zakładce Parametry przywracania. Wybierz Weryfikuj, aby sprawdzić uprawnienia parametrów przywracania przed ostatecznym przeglądem i przywróceniem.

  4. Po pomyślnym zakończeniu walidacji wybierz pozycję Przejrzyj i przywróć.

  5. Po ostatecznym przejrzeniu parametrów wybierz pozycję Przywróć, aby przywrócić wybraną kopię zapasową elastycznego serwera PostgreSQL na docelowym koncie magazynowym.

  6. Prześlij operację przywracania i śledź uruchomione zadanie w obszarze Zadania tworzenia kopii zapasowej.

Po pomyślnym zakończeniu zadania przywracania przejdź do kontenera w koncie magazynowania, aby wyświetlić przywrócone bazy danych jako pliki (.sql pliki) z serwera PostgreSQL – Fleksyjny. Usługa Azure Backup generuje również następujące pliki kopii zapasowej:

  • Database.sql file dla każdej bazy danych: zawiera dane i informacje o schemacie dla określonej bazy danych.

  • Roles.sql files dla całego wystąpienia: zawiera wszystkie informacje o roli istniejące na poziomie serwera.

  • Tablespace.sql file: plik Tablespace.

  • Schema.sql file: zawiera informacje o schemacie dla wszystkich baz danych na serwerze.

    Uwaga / Notatka

    Zalecamy, aby nie uruchamiać tego skryptu na serwerze PostgreSQL — elastycznym, ponieważ schemat jest już częścią skryptu database.sql .

Przywróć pliki kopii zapasowej z kontenera magazynu do nowego lub istniejącego serwera PostgreSQL — serwera elastycznego

Aby przywrócić pliki kopii zapasowej z kontenera magazynu do nowego lub istniejącego elastycznego serwera PostgreSQL, wykonaj następujące kroki:

  1. Upewnij się, że wszystkie wymagane rozszerzenia są włączone na nowym docelowym serwerze elastycznym.

  2. Dopasuj wartości parametrów serwera ze źródłowej bazy danych PostgreSQL do usługi Azure Database for PostgreSQL, korzystając z sekcji Parametry serwera w witrynie Azure Portal i ręcznie aktualizując odpowiednio wartości. Zapisz zmiany parametrów, a następnie uruchom ponownie usługę Azure Database for PostgreSQL — serwer elastyczny, aby zastosować nową konfigurację.

  3. Jeśli na nowym serwerze jest wymagane Uwierzytelnianie Microsoft Entra, włącz je i utwórz odpowiednich administratorów Microsoft Entra.

  4. Utwórz nową bazę danych na potrzeby przywracania.

    Uwaga / Notatka

    Przed przywróceniem bazy danych należy utworzyć nową, pustą bazę danych. Upewnij się, że twoje konto użytkownika ma CREATEDB uprawnienia.

    Aby utworzyć bazę danych, użyj polecenia CREATE DATABASE Database_name.

  5. Przywróć bazę danych, używając database.sql file jako użytkownika administratora.

  6. Po utworzeniu docelowej bazy danych pobierz plik zrzutu z konta usługi Azure Storage, uruchamiając następujące polecenie:

    az storage blob download --container-name <container-name> --name <blob-name> --account-name <storage-account-name> --account-key <storage-account-key> --file <file-name>

  7. Następnie przywróć dane w tej bazie danych z pliku zrzutu, uruchamiając następujące polecenie:

    pg_restore -h <postgres-server-url> -p <port> -U <username> -d <database-name> --no-owner -v <File Name>
    • --account-name: Nazwa docelowego konta magazynowego.
    • --container-name: nazwa kontenera blob.
    • --blob-name: nazwa blobu.
    • --account-key: Klucz konta storage.
    • -Fd: format katalogu.
    • -j: liczba miejsc pracy.
    • -C: Rozpocznij dane wyjściowe za pomocą polecenia , aby utworzyć samą bazę danych, a następnie ponownie nawiązać z nią połączenie.

    Uwaga / Notatka

    Jeśli polecenie nie jest wykonywane zgodnie z oczekiwaniami, określ pełną ścieżkę pliku zamiast używać tylko nazwy pliku.

    Alternatywnie możesz pobrać plik kopii zapasowej i uruchomić przywracanie bezpośrednio.

  8. Przywróć tylko wymagane role i uprawnienia i ignoruj typowe błędy. Pomiń ten krok, jeśli wykonujesz przywracanie pod kątem wymagań dotyczących zgodności i pobierania danych jako administrator lokalny.

Przywracanie ról i użytkowników dla przywróconych baz danych

Archiwalne kopie zapasowe są przywracane głównie w celu spełnienia wymogów zgodności, takich jak testy i audyty. Możesz zalogować się jako administrator lokalny i przywrócić przy użyciu database.sql pliku. Żadne inne role nie są potrzebne do pobierania danych.

W przypadku innych zastosowań, takich jak przypadkowa ochrona przed usunięciem lub odzyskiwanie po awarii, upewnij się, że niezbędne role są tworzone zgodnie z potrzebami organizacji. Unikaj duplikowania między elementami roles.sql i database.sql.

  • Przywróć ten sam elastyczny serwer: przywracanie ról może nie być konieczne.
  • Przywróć na inny serwer elastyczny: Użyj pliku roles.sql, aby ponownie utworzyć wymagane role.

Podczas przywracania z roles.sql niektóre role lub atrybuty mogą być nieprawidłowe dla nowego serwera docelowego.

W przypadku środowisk z dostępem superużytkownika (lokalnie lub maszynami wirtualnymi) można bezproblemowo uruchamiać wszystkie polecenia.

Kluczowe zagadnienia dotyczące scenariusza serwera elastycznego

Poniżej przedstawiono najważniejsze zagadnienia:

  • Usuń atrybuty Superuser-Only: na serwerze elastycznym nie ma uprawnień administratora. Usuń atrybuty, takie jak NOSUPERUSER i NOBYPASSRLS, ze zrzutu ról.
  • Wyklucz użytkowników Service-Specific: wyklucz użytkowników specyficznych dla usług serwera elastycznego ( azure_su, azure_pg_admin, replication, localadmin, ). Entra Admin Te określone role usługi są automatycznie tworzone ponownie, gdy administratorzy są dodawani do nowego serwera elastycznego.

Przed przywróceniem obiektów bazy danych upewnij się, że prawidłowo zrzucisz i wyczyścisz role. Aby wykonać tę akcję, pobierz roles.sqlskrypt z kontenera przechowywania i utwórz wszystkie wymagane loginy.

  • Tworzenie ról innych niż entra: użyj konta administratora lokalnego, aby uruchomić skrypty tworzenia roli.
  • Tworzenie ról firmy Microsoft Entra: jeśli musisz utworzyć role dla użytkowników firmy Microsoft Entra, użyj konta administratora Firmy Microsoft Entra, aby uruchomić niezbędne skrypty.

Skrypt ról możesz pobrać z konta storage, jak pokazano na poniższym zrzucie ekranu.

Podczas migracji pliku roles.sql wyjściowego może zawierać pewne role i atrybuty, które nie mają zastosowania w nowym środowisku. Należy wziąć pod uwagę następujące kwestie:

  • Usuwanie atrybutów, które można ustawić tylko przez superużytkowników: w przypadku migracji do środowiska, w którym nie masz uprawnień administratora, usuń atrybuty, takie jak NOSUPERUSER i NOBYPASSRLS z zrzutu ról.
  • Wykluczanie użytkowników specyficznych dla usługi: wyklucz użytkowników usługi pojedynczego serwera, takich jak azure_superuser lub azure_pg_admin. Są one specyficzne dla usługi i są tworzone automatycznie w nowym środowisku.

Użyj następującego polecenia sed, aby wyczyścić zrzut danych ról.

sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql

To polecenie usuwa linie zawierające azure_superuser, azure_pg_admin, azuresu, linie rozpoczynające się od CREATE ROLE replikacji oraz ALTER ROLE replikacji, a także usuwa atrybuty NOSUPERUSER i NOBYPASSRLS z instrukcji ALTER ROLE.

Następne kroki

Zarządzanie kopiami zapasowymi usługi Azure PostgreSQL — serwer elastyczny przy użyciu witryny Azure Portal.

  • Last updated on