Automatyczne kopie zapasowe w usłudze Azure SQL Database

Dotyczy: baza danych Azure SQL

W tym artykule opisano funkcję automatycznego tworzenia kopii zapasowych dla bazy danych Azure SQL.

Aby zmienić ustawienia kopii zapasowej, zobacz Zmienianie ustawień. Aby przywrócić kopię zapasową, zobacz Odzyskiwanie przy użyciu automatycznych kopii zapasowych bazy danych.

Co to jest kopia zapasowa bazy danych?

Kopie zapasowe bazy danych są istotną częścią każdej strategii ciągłości działania i odzyskiwania po awarii, ponieważ pomagają chronić dane przed uszkodzeniem lub usunięciem. Te kopie zapasowe umożliwiają przywracanie bazy danych do punktu w czasie w skonfigurowanym okresie przechowywania. Jeśli reguły ochrony danych wymagają, aby kopie zapasowe są dostępne przez dłuższy czas (do 10 lat), możesz skonfigurować długoterminowe przechowywanie (LTR) zarówno dla pojedynczych baz danych, jak i baz danych w puli.

W przypadku warstw usług innych niż Hiperskala usługa Azure SQL Database używa technologii aparatu SQL Server do tworzenia kopii zapasowych i przywracania danych. Bazy danych w warstwie Hiperskala używają kopii zapasowych i przywracania na podstawie migawek magazynu. W przypadku tradycyjnej technologii tworzenia kopii zapasowych SQL Server większe bazy danych mają długi czas tworzenia kopii zapasowych/przywracania. Dzięki użyciu migawek hiperskala zapewnia natychmiastowe możliwości tworzenia kopii zapasowych i szybkiego przywracania niezależnie od rozmiaru bazy danych. Aby dowiedzieć się więcej, zobacz Tworzenie kopii zapasowych w warstwie Hiperskala.

Częstotliwość wykonywania kopii zapasowych

Azure SQL Baza danych tworzy:

Dokładna częstotliwość tworzenia kopii zapasowych dziennika transakcji zależy od rozmiaru obliczeniowego i ilości aktywności bazy danych. Podczas przywracania bazy danych usługa określa, które pełne, różnicowe kopie zapasowe i kopie zapasowe dziennika transakcji muszą zostać przywrócone.

Architektura hiperskala nie wymaga pełnych, różnicowych ani kopii zapasowych dziennika. Aby dowiedzieć się więcej, zobacz Tworzenie kopii zapasowych w warstwie Hiperskala.

Nadmiarowość magazynu kopii zapasowych

Domyślnie usługa Azure SQL Database przechowuje kopie zapasowe w obiektach blob magazynu geograficznie nadmiarowego replikowanych do sparowanego regionu. Nadmiarowość geograficzna pomaga chronić przed awariami, które wpływają na magazyn kopii zapasowych w regionie podstawowym. Umożliwia również przywracanie baz danych w innym regionie w przypadku awarii regionalnej.

Mechanizm nadmiarowości magazynu przechowuje wiele kopii danych, dzięki czemu są chronione przed zaplanowanymi i nieplanowanymi zdarzeniami. Zdarzenia te mogą obejmować przejściowe awarie sprzętu, awarie sieci lub zasilania lub ogromne klęski żywiołowe.

Aby upewnić się, że kopie zapasowe pozostają w tym samym regionie, w którym wdrożono bazę danych, możesz zmienić nadmiarowość magazynu kopii zapasowych z domyślnego magazynu geograficznie nadmiarowego na inne typy magazynów, które przechowują dane w regionie. Skonfigurowana nadmiarowość magazynu kopii zapasowych jest stosowana zarówno do kopii zapasowych krótkoterminowego przechowywania (STR) i kopii zapasowych LTR. Aby dowiedzieć się więcej na temat nadmiarowości magazynu, zobacz Nadmiarowość danych.

Nadmiarowość magazynu kopii zapasowych można skonfigurować podczas tworzenia bazy danych i zaktualizować ją w późniejszym czasie. Zmiany wprowadzone w istniejącej bazie danych mają zastosowanie tylko do przyszłych kopii zapasowych. Po zaktualizowaniu nadmiarowości magazynu kopii zapasowej istniejącej bazy danych zmiany mogą potrwać do 48 godzin.

Możesz wybrać jedną z następujących nadmiarowości magazynu dla kopii zapasowych:

  • Magazyn lokalnie nadmiarowy (LRS): kopiuje kopie zapasowe synchronicznie trzy razy w ramach jednej lokalizacji fizycznej w regionie podstawowym. Magazyn LRS jest najtańszą opcją magazynu, ale nie zalecamy jej w przypadku aplikacji wymagających odporności na awarie regionalne lub gwarancję wysokiej trwałości danych.

    Diagram przedstawiający opcję magazynu lokalnie nadmiarowego (LRS).

  • Magazyn strefowo nadmiarowy (ZRS): kopiuje kopie zapasowe synchronicznie w trzech strefach dostępności platformy Azure w regionie podstawowym. Jest ona obecnie dostępna tylko w niektórych regionach.

    Diagram przedstawiający opcję magazynu strefowo nadmiarowego (ZRS).

  • Magazyn geograficznie nadmiarowy (GRS): kopiuje kopie zapasowe synchronicznie trzy razy w ramach jednej lokalizacji fizycznej w regionie podstawowym przy użyciu magazynu LRS. Następnie dane są kopiowane asynchronicznie trzy razy do pojedynczej lokalizacji fizycznej w sparowanym regionie pomocniczym.

    Wynik to:

    • Trzy synchroniczne kopie w regionie podstawowym.
    • Trzy synchroniczne kopie w sparowanym regionie, które zostały skopiowane z regionu podstawowego do regionu pomocniczego asynchronicznie.

    Diagram przedstawiający opcję magazynu geograficznie nadmiarowego (GRS).

Ostrzeżenie

  • Przywracanie geograficzne jest wyłączone po zaktualizowaniu bazy danych w celu korzystania z magazynu lokalnie nadmiarowego lub strefowo nadmiarowego.
  • Diagramy nadmiarowości magazynu pokazują wszystkie regiony z wieloma strefami dostępności (multi-az). Istnieją jednak niektóre regiony, które zapewniają tylko jedną strefę dostępności i nie obsługują magazynu ZRS.
  • Nadmiarowość magazynu kopii zapasowych dla baz danych w warstwie Hiperskala można ustawić tylko podczas tworzenia. Nie można zmodyfikować tego ustawienia po aprowizacji zasobu. Aby zaktualizować ustawienia nadmiarowości magazynu kopii zapasowych dla istniejącej bazy danych hiperskala z minimalnym przestojem, użyj aktywnej replikacji geograficznej. Alternatywnie można użyć kopii bazy danych. Dowiedz się więcej w temacie Tworzenie kopii zapasowych w warstwie Hiperskala i nadmiarowość magazynu.

Użycie kopii zapasowej

W następujących scenariuszach można użyć automatycznie utworzonych kopii zapasowych:

  • Przywróć istniejącą bazę danych do punktu w czasie w okresie przechowywania przy użyciu Azure Portal, Azure PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Ta operacja tworzy nową bazę danych na tym samym serwerze co oryginalna baza danych, ale używa innej nazwy, aby uniknąć zastępowania oryginalnej bazy danych.

    Po zakończeniu przywracania możesz opcjonalnie usunąć oryginalną bazę danych i zmienić nazwę przywróconej bazy danych na oryginalną nazwę bazy danych. Alternatywnie zamiast usuwać oryginalną bazę danych, można ją zmienić , a następnie zmienić nazwę przywróconej bazy danych na oryginalną nazwę bazy danych.

  • Przywróć usuniętą bazę danych do punktu w czasie w okresie przechowywania, w tym czas usunięcia. Usuniętą bazę danych można przywrócić tylko na tym samym serwerze, na którym utworzono oryginalną bazę danych. Przed usunięciem bazy danych usługa wykonuje ostateczną kopię zapasową dziennika transakcji, aby zapobiec utracie danych.

  • Przywracanie bazy danych do innego regionu geograficznego. Przywracanie geograficzne umożliwia odzyskiwanie po awarii regionalnej, gdy nie można uzyskać dostępu do bazy danych ani kopii zapasowych w regionie podstawowym. Tworzy nową bazę danych na dowolnym istniejącym serwerze w dowolnym regionie świadczenia usługi Azure.

    Ważne

    Przywracanie geograficzne jest dostępne tylko dla baz danych skonfigurowanych z geograficznie nadmiarowym magazynem kopii zapasowych. Jeśli obecnie nie używasz replikowanych geograficznie kopii zapasowych bazy danych, możesz to zmienić, konfigurując nadmiarowość magazynu kopii zapasowych.

  • Przywracanie bazy danych z określonej długoterminowej kopii zapasowej pojedynczej bazy danych lub bazy danych w puli, jeśli baza danych została skonfigurowana przy użyciu zasad LTR. LTR umożliwia przywrócenie starszej wersji bazy danych przy użyciu Azure Portal, interfejsu wiersza polecenia platformy Azure lub Azure PowerShell w celu spełnienia żądania zgodności lub uruchomienia starszej wersji aplikacji. Aby uzyskać więcej informacji, zobacz Długoterminowe przechowywanie.

Funkcje i możliwości przywracania

Ta tabela zawiera podsumowanie możliwości i funkcji przywracania do punktu w czasie (PITR), przywracaniageograficznego i długoterminowego przechowywania.

Właściwość kopii zapasowej  PITR Przywracanie geograficzne LTR
Typy kopii zapasowych SQL Pełny, różnicowy, dziennik. Replikowane kopie kopii zapasowych w celu przywracania do punktu w czasie. Tylko pełne kopie zapasowe.
Cel punktu odzyskiwania (recovery point objective, RPO)  10 minut na podstawie rozmiaru obliczeniowego i ilości aktywności bazy danych.   Do 1 godziny, zależnie od replikacji geograficznej.*  Tydzień (lub zasady użytkownika).
Cel czasu odzyskiwania (recovery time objective, RTO) Przywracanie zwykle trwa mniej niż 12 godzin, ale może trwać dłużej, w zależności od rozmiaru i aktywności. Zobacz Odzyskiwanie Przywracanie zwykle trwa mniej niż 12 godzin, ale może trwać dłużej, w zależności od rozmiaru i aktywności. Zobacz Odzyskiwanie. Przywracanie zwykle trwa mniej niż 12 godzin, ale może trwać dłużej, w zależności od rozmiaru i aktywności. Zobacz Odzyskiwanie.
Przechowywanie Domyślnie domyślnie można skonfigurować maksymalnie 35 dni.  Włączone domyślnie tak samo jak źródło.** Nie włączono domyślnie. Okres przechowywania wynosi do 10 lat.
Azure Storage   Domyślnie geograficznie nadmiarowy. Opcjonalnie można skonfigurować magazyn strefowo nadmiarowy lub lokalnie nadmiarowy. Dostępne, gdy nadmiarowość magazynu kopii zapasowych przywracania do punktu w czasie jest ustawiona na nadmiarowość geograficzną. Niedostępne, gdy magazyn kopii zapasowych PITR jest strefowo nadmiarowy lub lokalnie nadmiarowy.  Domyślnie geograficznie nadmiarowy. Możesz skonfigurować magazyn strefowo nadmiarowy lub lokalnie nadmiarowy.
Przywracanie nowej bazy danych w tym samym regionie Obsługiwane Obsługiwane  Obsługiwane
Przywracanie nowej bazy danych w innym regionie Nieobsługiwane Obsługiwane w dowolnym regionie świadczenia platformy Azure Obsługiwane w dowolnym regionie świadczenia platformy Azure
Przywracanie nowej bazy danych w innej subskrypcji Nieobsługiwane Nieobsługiwane*** Nieobsługiwane***
Przywracanie za pośrednictwem Azure Portal Tak Tak Tak
Przywracanie za pomocą programu PowerShell Tak Tak Tak
Przywracanie za pomocą interfejsu wiersza polecenia platformy Azure Tak Tak Tak

* W przypadku aplikacji krytycznych dla działania firmy, które wymagają dużych baz danych i muszą zapewnić ciągłość działania, użyj grup automatycznego trybu failover.

** Wszystkie kopie zapasowe pitr są domyślnie przechowywane w magazynie geograficznie nadmiarowym, więc przywracanie geograficzne jest domyślnie włączone.

Obejście polega na przywróceniu do nowego serwera i użyciu polecenia Resource Move w celu przeniesienia serwera do innej subskrypcji lub użycia kopii bazy danych między subskrypcjami.

Przywracanie bazy danych z kopii zapasowej

Aby wykonać przywracanie, zobacz Przywracanie bazy danych z kopii zapasowych. Konfigurację i przywracanie kopii zapasowych można eksplorować, korzystając z poniższych przykładów.

Operacja Azure Portal Interfejs wiersza polecenia platformy Azure Azure PowerShell
Zmienianie przechowywania kopii zapasowych SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
Zmienianie długoterminowego przechowywania kopii zapasowych SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
Przywracanie bazy danych z punktu w czasie SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
Przywracanie usuniętej bazy danych SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL
SQL Database
Wystąpienie zarządzane SQL

Planowanie kopii zapasowych

Pierwsza pełna kopia zapasowa jest planowana natychmiast po utworzeniu lub przywróceniu nowej bazy danych. Ta kopia zapasowa zwykle kończy się w ciągu 30 minut, ale może to potrwać dłużej, gdy baza danych jest duża. Na przykład początkowa kopia zapasowa może trwać dłużej w przywróconej bazie danych lub kopii bazy danych, co zwykle byłoby większe niż nowa baza danych.

Po utworzeniu pierwszej pełnej kopii zapasowej wszystkie kolejne kopie zapasowe są zaplanowane i zarządzane automatycznie. Dokładne terminy wykonywania wszystkich kopii zapasowych bazy danych są określane przez usługę SQL Database, ponieważ równoważy ona całkowite obciążenie systemu. Nie można zmienić harmonogramu zadań tworzenia kopii zapasowej ani ich wyłączyć.

Ważne

  • W przypadku nowej, przywróconej lub skopiowanej bazy danych funkcja przywracania do punktu w czasie staje się dostępna po utworzeniu początkowej kopii zapasowej dziennika transakcji, która następuje po utworzeniu początkowej pełnej kopii zapasowej.
  • Bazy danych w warstwie Hiperskala są chronione natychmiast po utworzeniu, w przeciwieństwie do innych baz danych, w których początkowa kopia zapasowa zajmuje czas. Ochrona jest natychmiastowa, nawet jeśli baza danych w warstwie Hiperskala została utworzona z dużą ilością danych za pośrednictwem kopiowania lub przywracania. Aby dowiedzieć się więcej, zapoznaj się z automatycznymi kopiami zapasowymi w warstwie Hiperskala.

Użycie magazynu kopii zapasowych

Dzięki SQL Server technologii tworzenia kopii zapasowych i przywracania przywracanie bazy danych do punktu w czasie wymaga nieprzerwanego łańcucha kopii zapasowych. Ten łańcuch składa się z jednej pełnej kopii zapasowej, opcjonalnie jednej różnicowej kopii zapasowej i co najmniej jednej kopii zapasowej dziennika transakcji.

Azure SQL Baza danych planuje jedną pełną kopię zapasową co tydzień. Aby zapewnić pitR w całym okresie przechowywania, system musi przechowywać dodatkowe pełne, różnicowe i transakcyjne kopie zapasowe dziennika transakcji przez maksymalnie tydzień dłużej niż skonfigurowany okres przechowywania.

Innymi słowy, w przypadku dowolnego punktu w czasie w okresie przechowywania musi istnieć pełna kopia zapasowa starsza niż najstarszy czas okresu przechowywania. Musi również istnieć nieprzerwany łańcuch różnicowych kopii zapasowych dziennika transakcji z tej pełnej kopii zapasowej do następnej pełnej kopii zapasowej.

Bazy danych w warstwie Hiperskala używają innego mechanizmu planowania kopii zapasowych. Aby uzyskać więcej informacji, zobacz Planowanie kopii zapasowych w warstwie Hiperskala.

Kopie zapasowe, które nie są już potrzebne do zapewnienia funkcji przywracania do punktu w czasie, są automatycznie usuwane. Ponieważ różnicowe kopie zapasowe i kopie zapasowe dzienników wymagają wcześniejszej pełnej kopii zapasowej do przywrócenia, wszystkie trzy typy kopii zapasowych są czyszczone razem w zestawach tygodniowych.

W przypadku wszystkich baz danych, w tym baz danych zaszyfrowanych za pomocą technologii TDE , kopie zapasowe są kompresowane w celu zmniejszenia zużycia i kosztów magazynu kopii zapasowych. Średni współczynnik kompresji kopii zapasowej wynosi od 3 do 4 razy. Jednak może być znacznie niższa lub wyższa w zależności od charakteru danych i tego, czy kompresja danych jest używana w bazie danych.

Azure SQL Database oblicza łączną ilość używanego magazynu kopii zapasowych jako wartość skumulowaną. Co godzinę ta wartość jest zgłaszana do potoku rozliczeń platformy Azure. Potok jest odpowiedzialny za agregowanie tego godzinowego użycia w celu obliczenia zużycia na koniec każdego miesiąca. Po usunięciu bazy danych zużycie zmniejsza się w miarę starzenia się kopii zapasowych i usuwania. Po usunięciu wszystkich kopii zapasowych, a przywracanie do punktu w czasie odzyskiwania po awarii nie będzie już możliwe, rozliczenia zostaną zatrzymane.

Ważne

Kopie zapasowe bazy danych są zachowywane w celu zapewnienia przywracania do punktu w czasie, nawet jeśli baza danych została usunięta. Chociaż usunięcie i ponowne utworzenie bazy danych może zmniejszyć koszty magazynowania i zasobów obliczeniowych, może to zwiększyć koszty magazynu kopii zapasowych. Przyczyną jest to, że usługa zachowuje kopie zapasowe dla każdej usuniętej bazy danych za każdym razem, gdy jest usuwana.

Monitorowanie użycia

W przypadku baz danych opartych na rdzeniach wirtualnych w usłudze Azure SQL Database magazyn, z którego korzysta każdy typ kopii zapasowej (pełna, różnicowa i dziennik) jest raportowany w okienku monitorowania bazy danych jako oddzielna metryka. Poniższy zrzut ekranu przedstawia sposób monitorowania użycia magazynu kopii zapasowych dla pojedynczej bazy danych.

Zrzut ekranu przedstawiający opcje monitorowania użycia kopii zapasowej bazy danych w Azure Portal.

Aby uzyskać instrukcje dotyczące monitorowania użycia w warstwie Hiperskala, zobacz Monitorowanie użycia kopii zapasowych w warstwie Hiperskala.

Dostosowywanie użycia magazynów kopii zapasowych

Użycie magazynu kopii zapasowych nieprzekraczające maksymalnego rozmiaru danych dla bazy danych nie podlega opłacie. Nadwyżka użycia magazynu kopii zapasowych będzie zależeć od obciążenia i maksymalnego rozmiaru poszczególnych baz danych. Rozważ niektóre z następujących technik dostrajania, aby zmniejszyć użycie magazynu kopii zapasowych:

  • Zmniejsz okres przechowywania kopii zapasowych do minimum w zależności od potrzeb.
  • Unikaj wykonywania dużych operacji zapisu, takich jak ponowne kompilowanie indeksu, częściej niż jest to konieczne.
  • W przypadku operacji ładowania dużych danych rozważ użycie klastrowanych indeksów magazynu kolumn i przestrzeganie powiązanych najlepszych rozwiązań. Rozważ również zmniejszenie liczby indeksów nieklasterowanych.
  • W warstwie usługi Ogólnego przeznaczenia aprowizowany magazyn danych jest tańszy niż cena magazynu kopii zapasowych. Jeśli stale wysokie koszty magazynu kopii zapasowych są wysokie, warto rozważyć zwiększenie magazynu danych w celu zaoszczędzenia w magazynie kopii zapasowych.
  • Użyj bazy danych TempDB zamiast tabel stałych w logice aplikacji do przechowywania wyników tymczasowych lub danych przejściowych.
  • Zawsze, gdy jest to możliwe, używaj lokalnie nadmiarowego magazynu kopii zapasowych (na przykład środowisk deweloperskich/testowych).

Przechowywanie kopii zapasowej

Azure SQL Database zapewnia krótkoterminowe i długoterminowe przechowywanie kopii zapasowych. Okres przechowywania krótkoterminowego umożliwia przywracanie do punktu w czasie przechowywania bazy danych. Długoterminowe przechowywanie zapewnia kopie zapasowe dla różnych wymagań dotyczących zgodności.

Przechowywanie krótkoterminowe

W przypadku wszystkich nowych, przywróconych i skopiowanych baz danych usługa Azure SQL Database zachowuje wystarczające kopie zapasowe, aby zezwolić na przywracanie do punktu w czasie domyślnie z ostatnich 7 dni. Usługa wykonuje regularne pełne, różnicowe i dzienniki kopie zapasowe, aby upewnić się, że bazy danych można przywrócić do dowolnego punktu w czasie w okresie przechowywania zdefiniowanym dla bazy danych.

Krótkoterminowe przechowywanie kopii zapasowej w okresie od 1 do 35 dni dla baz danych w warstwie Hiperskala jest teraz dostępne w wersji zapoznawczej. Aby dowiedzieć się więcej, zobacz Zarządzanie przechowywaniem kopii zapasowych w warstwie Hiperskala.

Różnicowe kopie zapasowe można skonfigurować tak, aby występowały raz w 12 godzinach lub raz w ciągu 24 godzin. 24-godzinna częstotliwość różnicowej kopii zapasowej może zwiększyć czas wymagany do przywrócenia bazy danych w porównaniu z częstotliwością 12-godzinną. W modelu rdzeni wirtualnych domyślna częstotliwość różnicowych kopii zapasowych wynosi raz na 12 godzin. W modelu DTU domyślna częstotliwość wynosi raz w ciągu 24 godzin.

Podczas tworzenia bazy danych można określić opcję nadmiarowości magazynu kopii zapasowych dla magazynu kopii zapasowych, a następnie zmienić ją w późniejszym czasie. Jeśli zmienisz opcję nadmiarowości kopii zapasowej po utworzeniu bazy danych, nowe kopie zapasowe będą używać nowej opcji nadmiarowości. Kopie zapasowe wykonane przy użyciu poprzedniej opcji nadmiarowości STR nie są przenoszone ani kopiowane. Pozostają one na oryginalnym koncie magazynu do momentu wygaśnięcia okresu przechowywania, który może wynosić od 1 do 35 dni.

Z wyjątkiem baz danych Podstawowych można zmienić okres przechowywania kopii zapasowych dla każdej aktywnej bazy danych w zakresie od 1 do 35 dni. Zgodnie z opisem w temacie Użycie magazynu kopii zapasowych kopie zapasowe przechowywane w celu włączenia przywracania do punktu w czasie przechowywania mogą być starsze niż okres przechowywania. Jeśli musisz przechowywać kopie zapasowe dłużej niż maksymalny okres przechowywania krótkoterminowego wynoszący 35 dni, możesz włączyć długoterminowe przechowywanie.

Jeśli usuniesz bazę danych, system przechowuje kopie zapasowe w taki sam sposób, jak w przypadku bazy danych online z określonym okresem przechowywania. Nie można zmienić okresu przechowywania kopii zapasowych dla usuniętej bazy danych.

Ważne

Jeśli usuniesz serwer, wszystkie bazy danych na tym serwerze również zostaną usunięte i nie można ich odzyskać. Nie można przywrócić usuniętego serwera. Jeśli jednak skonfigurowano długoterminowe przechowywanie bazy danych, kopie zapasowe długoterminowe nie zostaną usunięte. Następnie możesz użyć tych kopii zapasowych, aby przywrócić bazy danych na innym serwerze w tej samej subskrypcji do punktu w czasie wykonywania kopii zapasowej LTR. Aby dowiedzieć się więcej, zapoznaj się z artykułem Przywracanie długoterminowej kopii zapasowej.

Długoterminowe przechowywanie

W przypadku SQL Database można skonfigurować pełne kopie zapasowe LTR przez maksymalnie 10 lat w Azure Blob Storage. Po skonfigurowaniu zasad LTR pełne kopie zapasowe są automatycznie kopiowane do innego kontenera magazynu co tydzień.

Aby spełnić różne wymagania dotyczące zgodności, możesz wybrać różne okresy przechowywania dla pełnych kopii zapasowych co tydzień, co miesiąc i/lub rok. Częstotliwość zależy od zasad. Na przykład ustawienie W=0, M=1 spowoduje utworzenie miesięcznej kopii LTR. Aby uzyskać więcej informacji na temat długoterminowego przechowywania, zobacz Długoterminowe przechowywanie.

Aktualizacja nadmiarowości magazynu kopii zapasowych dla istniejącej bazy danych stosuje zmianę tylko do kolejnych kopii zapasowych wykonanych w przyszłości, a nie dla istniejących kopii zapasowych. Wszystkie istniejące kopie zapasowe długoterminowe dla bazy danych będą nadal znajdować się w istniejącym obiekcie blob magazynu. Nowe kopie zapasowe będą replikowane na podstawie skonfigurowanej nadmiarowości magazynu kopii zapasowych.

Zużycie magazynu zależy od wybranych częstotliwości i okresów przechowywania kopii zapasowych LTR. Aby oszacować koszt magazynu LTR, można użyć kalkulatora cen przechowywania długoterminowego.

Koszty magazynu kopii zapasowych

Cena magazynu kopii zapasowych zależy od modelu zakupów (DTU lub rdzenia wirtualnego), wybranej opcji nadmiarowości magazynu kopii zapasowych i regionu. Opłaty za magazyn kopii zapasowych są naliczane na podstawie gigabajtów zużywanych miesięcznie, z taką samą szybkością dla wszystkich kopii zapasowych.

Nadmiarowość magazynu kopii zapasowych wpływa na koszty tworzenia kopii zapasowych w następujący sposób:

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2

Aby uzyskać informacje o cenach, zobacz stronę cennika usługi Azure SQL Database.

Uwaga

Faktura za platformę Azure pokazuje tylko nadmierne użycie magazynu kopii zapasowych, a nie całe użycie magazynu kopii zapasowych. Na przykład w hipotetycznym scenariuszu, jeśli aprowizujesz 4 TB magazynu danych, otrzymasz 4 TB wolnego miejsca do magazynowania kopii zapasowych. Jeśli używasz łącznie 5,8 TB miejsca do magazynowania kopii zapasowych, faktura platformy Azure będzie zawierać tylko 1,8 TB, ponieważ opłaty są naliczane tylko za nadmiarowy magazyn kopii zapasowych, który został użyty.

Model jednostki DTU

W modelu jednostki DTU nie są naliczane dodatkowe opłaty za magazyn kopii zapasowych baz danych i pul elastycznych. Cena magazynu kopii zapasowych jest częścią ceny bazy danych lub puli.

Model rdzenia wirtualnego

Azure SQL Database oblicza całkowity rozliczany magazyn kopii zapasowych jako skumulowaną wartość dla wszystkich plików kopii zapasowych. Co godzinę ta wartość jest zgłaszana do potoku rozliczeń platformy Azure. Potok agreguje to godzinowe użycie w celu uzyskania użycia magazynu kopii zapasowych na koniec każdego miesiąca.

Jeśli baza danych zostanie usunięta, użycie magazynu kopii zapasowych będzie stopniowo zmniejszane w miarę starzenia się starszych kopii zapasowych i ich usuwania. Ponieważ różnicowe kopie zapasowe i kopie zapasowe dzienników wymagają wcześniejszej pełnej kopii zapasowej do przywrócenia, wszystkie trzy typy kopii zapasowych są czyszczone razem w zestawach tygodniowych. Po usunięciu wszystkich kopii zapasowych rozliczenia zostaną zatrzymane.

Koszt magazynu kopii zapasowych jest obliczany inaczej dla baz danych w warstwie Hiperskala. Aby uzyskać więcej informacji, zobacz Koszty magazynu kopii zapasowych w warstwie Hiperskala.

W przypadku pojedynczych baz danych magazyn kopii zapasowych wynosi 100 procent maksymalnego rozmiaru magazynu danych dla bazy danych bez dodatkowych opłat. Następujące równanie służy do obliczania całkowitego rozliczanego użycia magazynu kopii zapasowych:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

W przypadku elastycznych pul magazyn kopii zapasowych wynosi 100 procent maksymalnego rozmiaru magazynu danych dla rozmiaru magazynu puli bez dodatkowych opłat. W przypadku baz danych w puli łączny rozmiar rozliczanego magazynu kopii zapasowych jest agregowany na poziomie puli i jest obliczany w następujący sposób:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Łączna opłata za rozliczany magazyn kopii zapasowych, jeśli istnieje, jest naliczana w gigabajtach miesięcznie zgodnie z szybkością nadmiarowości magazynu kopii zapasowych, która została użyta. To użycie magazynu kopii zapasowych zależy od obciążenia i rozmiaru poszczególnych baz danych, pul elastycznych i wystąpień zarządzanych. Silnie zmodyfikowane bazy danych mają większe różnicowe kopie zapasowe i kopie zapasowe dzienników, ponieważ rozmiar tych kopii zapasowych jest proporcjonalny do ilości zmienionych danych. W związku z tym takie bazy danych będą miały wyższe opłaty za tworzenie kopii zapasowych.

W uproszczonym przykładzie załóżmy, że baza danych zgromadziła 744 GB magazynu kopii zapasowych i że ta ilość pozostaje stała przez cały miesiąc, ponieważ baza danych jest całkowicie bezczynna. Aby przekonwertować to skumulowane użycie magazynu na użycie godzinowe, podziel je na 744,0 (31 dni miesięcznie 24 godziny dziennie). SQL Database będzie zgłaszać potok rozliczeń platformy Azure, który baza danych zużywała 1 GB kopii zapasowej pitr co godzinę, przy stałej szybkości. Rozliczenia platformy Azure będą agregować to zużycie i pokazywać użycie 744 GB przez cały miesiąc. Koszt będzie zależeć od stawki za gigabajty miesięcznie w Twoim regionie.

Oto kolejny przykład. Załóżmy, że ta sama bezczynna baza danych ma zwiększone przechowywanie z 7 dni do 14 dni w połowie miesiąca. Ten wzrost powoduje podwojenie całkowitego magazynu kopii zapasowych do 1488 GB. SQL Database raportowałby 1 GB użycia przez godziny od 1 do 372 (pierwsza połowa miesiąca). Raportuje użycie jako 2 GB dla godzin od 373 do 744 (druga połowa miesiąca). To użycie zostanie zagregowane do końcowego rachunku w wysokości 1116 GB miesięcznie.

Rzeczywiste scenariusze rozliczeń kopii zapasowych są bardziej złożone. Ponieważ szybkość zmian w bazie danych zależy od obciążenia i jest zmienna w czasie, rozmiar każdej różnicowej i kopii zapasowej dziennika również będzie się różnić. Godzinowe zużycie magazynu kopii zapasowych będzie odpowiednio ulegać wahaniom.

Każda różnicowa kopia zapasowa zawiera również wszystkie zmiany wprowadzone w bazie danych od ostatniej pełnej kopii zapasowej. Dlatego całkowity rozmiar wszystkich różnicowych kopii zapasowych stopniowo wzrasta w ciągu tygodnia. Następnie gwałtownie spada po starcie starszego zestawu pełnych, różnicowych i kopii zapasowych dziennika starzeje się.

Załóżmy na przykład, że duża aktywność zapisu, taka jak ponowne kompilowanie indeksu, jest uruchamiana tuż po zakończeniu pełnej kopii zapasowej. Modyfikacje wprowadzone przez ponowną kompilację indeksu zostaną uwzględnione:

  • W kopiach zapasowych dziennika transakcji przejęte w czasie trwania ponownego kompilowania.
  • W następnej różnicowej kopii zapasowej.
  • W każdej różnicowej kopii zapasowej wykonanej do momentu utworzenia następnej pełnej kopii zapasowej.

W przypadku ostatniego scenariusza w większych bazach danych optymalizacja w usłudze tworzy pełną kopię zapasową zamiast różnicowej kopii zapasowej, jeśli różnicowa kopia zapasowa byłaby zbyt duża. Zmniejsza to rozmiar wszystkich różnicowych kopii zapasowych do momentu utworzenia następującej pełnej kopii zapasowej.

Łączne użycie magazynu kopii zapasowych można monitorować dla każdego typu kopii zapasowej (pełny, różnicowy, dziennik transakcji) w czasie, zgodnie z opisem w temacie Monitorowanie zużycia.

Monitorowanie kosztów

Aby zrozumieć koszty magazynu kopii zapasowych, przejdź do obszaru Zarządzanie kosztami i rozliczenia w Azure Portal. Wybierz pozycję Cost Management, a następnie wybierz pozycję Analiza kosztów. Wybierz żądaną subskrypcję dla pozycji Zakres, a następnie odfiltruj odpowiedni okres i usługę w następujący sposób:

  1. Dodaj filtr dla nazwy usługi.

  2. Z listy rozwijanej wybierz pozycję sql database dla pojedynczej bazy danych lub elastycznej puli baz danych.

  3. Dodaj kolejny filtr dla podkategorii Miernik.

  4. Aby monitorować koszty tworzenia kopii zapasowych pitr, na liście rozwijanej wybierz magazyn kopii zapasowych pojedynczej/elastycznej puli kopii zapasowej dla pojedynczej bazy danych lub elastycznej puli baz danych. Mierniki będą wyświetlane tylko wtedy, gdy istnieje użycie magazynu kopii zapasowych.

    Aby monitorować koszty tworzenia kopii zapasowych LTR, na liście rozwijanej wybierz pozycję ltr backup storage dla pojedynczej bazy danych lub elastycznej puli baz danych. Mierniki będą wyświetlane tylko wtedy, gdy istnieje użycie magazynu kopii zapasowych.

Podkategorie magazynu i zasobów obliczeniowych mogą cię również zainteresować, ale nie są skojarzone z kosztami magazynu kopii zapasowych.

Zrzut ekranu przedstawiający analizę kosztów magazynu kopii zapasowych.

Ważne

Mierniki są widoczne tylko dla liczników, które są obecnie używane. Jeśli licznik jest niedostępny, prawdopodobnie kategoria nie jest obecnie używana. Na przykład liczniki magazynu nie będą widoczne dla zasobów, które nie korzystają z magazynu. Jeśli nie ma użycia magazynu kopii zapasowych do punktu w czasie do punktu w czasie, te mierniki nie będą widoczne.

Aby uzyskać więcej informacji, zobacz zarządzanie kosztami w usłudze Azure SQL Database.

Zaszyfrowane kopie zapasowe

Jeśli baza danych jest zaszyfrowana za pomocą TDE, kopie zapasowe są automatycznie szyfrowane w spoczynku, w tym kopie zapasowe LTR. Wszystkie nowe bazy danych w usłudze Azure SQL są domyślnie skonfigurowane z włączonym szyfrowaniem TDE. Aby uzyskać więcej informacji na temat technologii TDE, zobacz Transparent Data Encryption with SQL Database (Przezroczyste szyfrowanie danych przy użyciu SQL Database).

Integralność kopii zapasowych

Zespół inżynierów usługi Azure SQL stale przeprowadza automatyczne testy przywracania zautomatyzowanych kopii zapasowych baz danych. Po przywróceniu do punktu w czasie bazy danych również otrzymują kontrole integralności DBCC CHECKDB.

Wszelkie problemy znalezione podczas sprawdzania integralności spowodują wyświetlenie alertu dla zespołu inżynierów. Aby uzyskać więcej informacji, zobacz Integralność danych w SQL Database.

Wszystkie kopie zapasowe bazy danych są wykonywane z opcją CHECKSUM, aby zapewnić dodatkową integralność kopii zapasowej.

Zgodność

Podczas migrowania bazy danych z warstwy usługi opartej na jednostkach DTU do warstwy usługi opartej na rdzeniach wirtualnych przywracanie do punktu w czasie jest zachowywane w celu zapewnienia, że zasady odzyskiwania danych aplikacji nie zostaną naruszone. Jeśli domyślne przechowywanie nie spełnia wymagań dotyczących zgodności, możesz zmienić okres przechowywania do punktu w czasie. Aby uzyskać więcej informacji, zobacz Zmienianie okresu przechowywania kopii zapasowych przywracania do punktu w czasie.

Uwaga

Artykuł Zmiana ustawień automatycznych kopii zapasowych zawiera kroki usuwania danych osobowych z urządzenia lub usługi i może służyć do obsługi zobowiązań wynikających z RODO. Aby uzyskać ogólne informacje na temat RODO, zobacz sekcję RODO w Centrum zaufania Firmy Microsoft i w sekcji RODO w portalu Service Trust Portal.

Używanie Azure Policy do wymuszania nadmiarowości magazynu kopii zapasowych

Jeśli masz wymagania dotyczące rezydencji danych, które wymagają przechowywania wszystkich danych w jednym regionie świadczenia usługi Azure, możesz wymusić strefowo nadmiarowe lub lokalnie nadmiarowe kopie zapasowe bazy danych SQL przy użyciu Azure Policy.

Azure Policy to usługa, której można użyć do tworzenia, przypisywania i zarządzania zasadami, które stosują reguły do zasobów platformy Azure. Azure Policy pomaga zachować zgodność tych zasobów ze standardami firmy i umowami dotyczącymi poziomu usług. Aby uzyskać więcej informacji, zobacz Omówienie Azure Policy.

Wbudowane zasady nadmiarowości magazynu kopii zapasowych

Aby wymusić wymagania dotyczące rezydencji danych na poziomie organizacji, można przypisać zasady do subskrypcji przy użyciu Azure Portal lub Azure PowerShell. Jeśli na przykład przypiszesz następujące wbudowane zasady, użytkownicy w subskrypcji nie będą mogli utworzyć bazy danych z geograficznie nadmiarowym magazynem kopii zapasowych za pośrednictwem Azure Portal lub Azure PowerShell: SQL Database należy unikać nadmiarowości kopii zapasowych GRS.

Aby uzyskać pełną listę wbudowanych definicji zasad dla SQL Database, zapoznaj się z dokumentacją zasad.

Ważne

Zasady platformy Azure nie są wymuszane podczas tworzenia bazy danych za pośrednictwem języka T-SQL. Aby określić miejsce przechowywania danych podczas tworzenia bazy danych przy użyciu języka T-SQL, użyj wartości LOCAL lub ZONE jako danych wejściowych dla parametru BACKUP_STORAGE_REDUNDANCY w instrukcji CREATE DATABASE.

Następne kroki