Sposób wykonywania kopii zapasowej i przywracania serwera w usłudze Azure Database for PostgreSQL — pojedynczy serwer przy użyciu interfejsu wiersza polecenia platformy Azure

DOTYCZY: Azure Database for PostgreSQL — pojedynczy serwer

Ważne

Usługa Azure Database for PostgreSQL — pojedynczy serwer znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do usługi Azure Database for PostgreSQL — serwer elastyczny. Aby uzyskać więcej informacji na temat migracji do usługi Azure Database for PostgreSQL — serwer elastyczny, zobacz Co się dzieje z usługą Azure Database for PostgreSQL — pojedynczy serwer?.

Kopie zapasowe serwerów usługi Azure Database for PostgreSQL są okresowo tworzone w celu włączenia funkcji przywracania. Korzystając z tej funkcji, można przywrócić serwer i wszystkie jego bazy danych do wcześniejszego punktu w czasie na nowym serwerze.

Wymagania wstępne

Aby ukończyć ten przewodnik z instrukcjami:

  • Ten artykuł wymaga wersji 2.0 lub nowszej interfejsu wiersza polecenia platformy Azure. W przypadku korzystania z usługi Azure Cloud Shell najnowsza wersja jest już zainstalowana.

Ustawianie konfiguracji kopii zapasowej

Należy dokonać wyboru między skonfigurowaniem serwera dla lokalnie nadmiarowych kopii zapasowych lub geograficznie nadmiarowych kopii zapasowych podczas tworzenia serwera.

Uwaga

Po utworzeniu serwera rodzaj nadmiarowości, który ma, geograficznie nadmiarowy i lokalnie nadmiarowy, nie można przełączyć.

Podczas tworzenia serwera za pomocą az postgres server create polecenia --geo-redundant-backup parametr decyduje o opcji nadmiarowości kopii zapasowej. Jeśli Enabledsą wykonywane geograficznie nadmiarowe kopie zapasowe. Lub jeśli Disabled są wykonywane lokalnie nadmiarowe kopie zapasowe.

Okres przechowywania kopii zapasowej jest ustawiany przez parametr --backup-retention-days.

Aby uzyskać więcej informacji na temat ustawiania tych wartości podczas tworzenia, zobacz Przewodnik Szybki start dotyczący interfejsu wiersza polecenia serwera usługi Azure Database for PostgreSQL.

Okres przechowywania kopii zapasowej serwera można zmienić w następujący sposób:

az postgres server update --name mydemoserver --resource-group myresourcegroup --backup-retention 10

Poprzedni przykład zmienia okres przechowywania kopii zapasowej serwera mydemoserver na 10 dni.

Okres przechowywania kopii zapasowej określa, jak daleko w czasie można pobrać przywracanie do punktu w czasie, ponieważ jest on oparty na dostępnych kopiach zapasowych. Przywracanie do punktu w czasie zostało opisane w następnej sekcji.

Przywracanie do punktu w czasie serwera

Serwer można przywrócić do poprzedniego punktu w czasie. Przywrócone dane są kopiowane na nowy serwer, a istniejący serwer jest pozostawiony w takiej postaci. Jeśli na przykład tabela zostanie przypadkowo porzucona w południe dzisiaj, możesz przywrócić do godziny tuż przed południem. Następnie możesz pobrać brakującą tabelę i dane z przywróconej kopii serwera.

Aby przywrócić serwer, użyj polecenia az postgres server restore interfejsu wiersza polecenia platformy Azure.

Uruchom polecenie przywracania

Aby przywrócić serwer, w wierszu polecenia interfejsu wiersza polecenia platformy Azure wprowadź następujące polecenie:

az postgres server restore --resource-group myresourcegroup --name mydemoserver-restored --restore-point-in-time 2018-03-13T13:59:00Z --source-server mydemoserver

Polecenie az postgres server restore wymaga następujących parametrów:

Ustawienie Sugerowana wartość Opis
resource-group  myresourcegroup  Grupa zasobów, w której istnieje serwer źródłowy. 
name mydemoserver-restored Nazwa nowego serwera utworzonego za pomocą polecenie przywracania.
restore-point-in-time 2018-03-13T13:59:00Z Wybierz punkt w czasie do przywrócenia. Ta data i godzina musi przypadać w okresie przechowywania kopii zapasowej serwera źródłowego. Użyj formatu daty i godziny ISO8601. Możesz na przykład użyć własnej lokalnej strefy czasowej, takiej jak 2018-03-13T05:59:00-08:00. Można również użyć formatu UTC Zulu, na przykład 2018-03-13T13:59:00Z.
source-server mydemoserver Nazwa lub identyfikator serwera źródłowego, z którego ma zostać przeprowadzone przywrócenie.

Po przywróceniu serwera do wcześniejszego punktu w czasie zostanie utworzony nowy serwer. Oryginalny serwer i jego bazy danych z określonego punktu w czasie są kopiowane do nowego serwera.

Wartości lokalizacji i warstwy cenowej przywróconego serwera pozostają takie same jak w przypadku oryginalnego serwera.

Po zakończeniu procesu przywracania znajdź nowy serwer i sprawdź, czy dane zostały przywrócone zgodnie z oczekiwaniami. Nowy serwer ma taką samą nazwę logowania administratora serwera i hasło, które było prawidłowe dla istniejącego serwera w momencie zainicjowania przywracania. Hasło można zmienić na stronie Przegląd nowego serwera.

Nowy serwer utworzony podczas przywracania nie ma reguł zapory lub punktów końcowych usługi sieci wirtualnej, które istniały na oryginalnym serwerze. Te reguły należy skonfigurować oddzielnie dla tego nowego serwera.

Przywracanie geograficzne

Jeśli serwer został skonfigurowany pod kątem geograficznie nadmiarowych kopii zapasowych, można utworzyć nowy serwer z kopii zapasowej tego istniejącego serwera. Ten nowy serwer można utworzyć w dowolnym regionie dostępnym w usłudze Azure Database for PostgreSQL.

Aby utworzyć serwer przy użyciu geograficznie nadmiarowej kopii zapasowej, użyj polecenia interfejsu wiersza polecenia az postgres server georestore platformy Azure.

Uwaga

Po pierwszym utworzeniu serwera może nie być natychmiast dostępny na potrzeby przywracania geograficznego. Wypełnienie niezbędnych metadanych może potrwać kilka godzin.

Aby przywrócić serwer geograficznie, w wierszu polecenia interfejsu wiersza polecenia platformy Azure wprowadź następujące polecenie:

az postgres server georestore --resource-group myresourcegroup --name mydemoserver-georestored --source-server mydemoserver --location eastus --sku-name GP_Gen5_8 

To polecenie tworzy nowy serwer o nazwie mydemoserver-georestored w regionie Wschodnie stany USA, który będzie należeć do myresourcegroup. Jest to serwer ogólnego przeznaczenia gen 5 z 8 rdzeniami wirtualnymi. Serwer jest tworzony na podstawie geograficznie nadmiarowej kopii zapasowej serwera mydemoserver, który znajduje się również w grupie zasobów myresourcegroup

Jeśli chcesz utworzyć nowy serwer w innej grupie zasobów z istniejącego serwera, w parametrze --source-server należy zakwalifikować nazwę serwera, jak w poniższym przykładzie:

az postgres server georestore --resource-group newresourcegroup --name mydemoserver-georestored --source-server "/subscriptions/$<subscription ID>/resourceGroups/$<resource group ID>/providers/Microsoft.DBforPostgreSQL/servers/mydemoserver" --location eastus --sku-name GP_Gen5_8

Polecenie az postgres server georestore wymaga następujących parametrów:

Ustawienie Sugerowana wartość Opis
resource-group myresourcegroup Nazwa grupy zasobów, do którego będzie należeć nowy serwer.
name mydemoserver-georestored Nazwa nowego serwera.
source-server mydemoserver Nazwa istniejącego serwera, na którym są używane geograficznie nadmiarowe kopie zapasowe.
lokalizacja eastus Lokalizacja nowego serwera.
sku-name GP_Gen5_8 Ten parametr określa warstwę cenową, generowanie zasobów obliczeniowych i liczbę rdzeni wirtualnych nowego serwera. GP_Gen5_8 mapuje na serwer Ogólnego przeznaczenia, 5. generacji z 8 rdzeniami wirtualnymi.

Podczas tworzenia nowego serwera przez przywracanie geograficzne dziedziczy ten sam rozmiar magazynu i warstwę cenową co serwer źródłowy. Tych wartości nie można zmienić podczas tworzenia. Po utworzeniu nowego serwera jego rozmiar magazynu można skalować w górę.

Po zakończeniu procesu przywracania znajdź nowy serwer i sprawdź, czy dane zostały przywrócone zgodnie z oczekiwaniami. Nowy serwer ma taką samą nazwę logowania administratora serwera i hasło, które było prawidłowe dla istniejącego serwera w momencie zainicjowania przywracania. Hasło można zmienić na stronie Przegląd nowego serwera.

Nowy serwer utworzony podczas przywracania nie ma reguł zapory lub punktów końcowych usługi sieci wirtualnej, które istniały na oryginalnym serwerze. Te reguły należy skonfigurować oddzielnie dla tego nowego serwera.

Następne kroki