Automatyczne kopie zapasowe w usłudze Azure SQL Managed Instance

  • Artykuł

Dotyczy:Azure SQL Managed Instance

W tym artykule opisano funkcję automatycznej kopii zapasowej dla usługi Azure SQL Managed Instance.

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 są automatyczne kopie zapasowe bazy danych?

Kopie zapasowe bazy danych są istotną częścią każdej strategii ciągłości biznesowej i odzyskiwania po awarii, ponieważ pomagają chronić dane przed uszkodzeniem lub usunięciem. Usługa Azure SQL Managed Instance zapewnia całkowicie zarządzane i zautomatyzowane kopie zapasowe aparatu bazy danych programu SQL Server. Te kopie zapasowe umożliwiają przywracanie bazy danych do określonego punktu w czasie w skonfigurowanym okresie przechowywania do 35 dni. Jeśli jednak reguły ochrony danych wymagają udostępnienia kopii zapasowych przez dłuższy czas (do 10 lat), można skonfigurować zasady przechowywania długoterminowego (LTR) dla bazy danych.

Częstotliwość wykonywania kopii zapasowych

Usługa Azure SQL Managed Instance tworzy:

Częstotliwość tworzenia kopii zapasowych dziennika transakcji zależy od rozmiaru obliczeniowego i ilości aktywności bazy danych. Dzienniki transakcji są wykonywane co około 10 minut, ale mogą się różnić. Podczas przywracania bazy danych usługa określa, które pełne, różnicowe i transakcyjne kopie zapasowe dziennika muszą zostać przywrócone w odpowiedniej kolejności.

Nadmiarowość magazynu kopii zapasowych

Domyślnie usługa Azure SQL Managed Instance przechowuje dane 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ż przywrócenie wystąpienia do innego regionu w przypadku awarii.

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. Aby dowiedzieć się więcej na temat nadmiarowości magazynu, zobacz Nadmiarowość danych.

Nadmiarowość magazynu kopii zapasowych można skonfigurować podczas tworzenia wystąpienia i zaktualizować ją w późniejszym czasie na poziomie wystąpienia. Zmiany wprowadzone w istniejącym wystąpieniu mają zastosowanie tylko do przyszłych kopii zapasowych. Po zaktualizowaniu nadmiarowości magazynu kopii zapasowych istniejącego wystąpienia może upłynąć do 24 godzin, aż zmiany zostaną zastosowane. Zmiany wprowadzone w nadmiarowości magazynu kopii zapasowych mają zastosowanie tylko do krótkoterminowych kopii zapasowych. Zasady przechowywania długoterminowego dziedziczą opcję nadmiarowości krótkoterminowych kopii zapasowych podczas tworzenia zasad. Opcja nadmiarowości jest nadal dostępna w przypadku długoterminowych kopii zapasowych, nawet jeśli opcja nadmiarowości dla krótkoterminowych kopii zapasowych ulegnie zmianie.

Uwaga

Należy pamiętać, że zmiana nadmiarowości kopii zapasowej powoduje krok uaktualniania, który inicjuje przejście w tryb failover.

Dla kopii zapasowych można wybrać jedną z następujących nadmiarowości magazynu:

  • Magazyn lokalnie nadmiarowy (LRS): kopiuje kopie zapasowe synchronicznie trzy razy w jednej lokalizacji fizycznej w regionie podstawowym. Magazyn LRS jest najmniej kosztowną opcją replikacji, ale nie zalecamy jej w przypadku aplikacji wymagających wysokiej dostępności lub trwałości.

    Diagram showing the locally redundant storage (LRS) option.

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

    Diagram showing the zone-redundant storage (ZRS) option.

  • Magazyn geograficznie nadmiarowy (GRS): kopiuje kopie zapasowe synchronicznie trzy razy w 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 w jednej strefie dostępności.
    • Trzy synchroniczne kopie w sparowanym regionie w jednej strefie dostępności skopiowane z regionu podstawowego do regionu pomocniczego asynchronicznie.

    Diagram showing the geo-redundant storage (GRS) option.

  • Magazyn geograficznie nadmiarowy (GZRS): łączy wysoką dostępność zapewnianą przez nadmiarowość w różnych strefach dostępności z ochroną przed awariami regionalnymi zapewnianymi przez replikację geograficzną. Dane na koncie GZRS są kopiowane w trzech strefach dostępności platformy Azure w regionie podstawowym. Dane są również replikowane do pomocniczego regionu geograficznego w celu ochrony przed awariami regionalnymi. W tym regionie istnieją również trzy synchroniczne kopie w pojedynczej strefie dostępności, które zostały skopiowane z regionu podstawowego do regionu pomocniczego asynchronicznie.

    Diagram showing the geo-zone-redundant storage (GZRS) option.

Ostrzeżenie

  • Przywracanie geograficzne jest wyłączone natychmiast 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ą stref ZRS ani GZRS.

Korzystanie z kopii zapasowych

Tych kopii zapasowych można użyć w następujących celach:

  • Przywróć istniejącą bazę danych do punktu w czasie w przeszłości w okresie przechowywania przy użyciu witryny Azure Portal, programu Azure PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Ta operacja tworzy nową bazę danych w tym samym wystąpieniu co oryginalna baza danych lub inne wystąpienie w tej samej subskrypcji i regionie. Używa innej nazwy, aby uniknąć zastępowania oryginalnej bazy danych. Możesz również użyć witryny Azure Portal, aby przywrócić kopię zapasową bazy danych do wystąpienia w innej subskrypcji niż wystąpienie źródłowe.

    Po zakończeniu przywracania można usunąć oryginalną bazę danych. Alternatywnie możesz zmienić nazwę oryginalnej bazy danych i 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ć do tego samego wystąpienia zarządzanego, w którym utworzono kopię zapasową, lub innego wystąpienia w tym samym lub innej subskrypcji do wystąpienia źródłowego. 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 pozwala odzyskać dane po awarii geograficznej, gdy nie można uzyskać dostępu do bazy danych ani kopii zapasowych w regionie podstawowym. Tworzy nową bazę danych na dowolnym istniejącym wystąpieniu zarządzanym w dowolnym regionie świadczenia usługi Azure.

    Ważne

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

  • Przywróć bazę danych z długoterminowej kopii zapasowej bazy danych, jeśli baza danych ma skonfigurowane zasady LTR. LTR umożliwia przywrócenie starszej wersji bazy danych przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell w celu spełnienia żądania zgodności lub uruchomienia starej wersji aplikacji. Aby uzyskać więcej informacji, zapoznaj się ze stroną Przegląd przechowywania długoterminowego.

Funkcje i możliwości przywracania

W tej tabeli przedstawiono podsumowanie możliwości i funkcji przywracania do punktu w czasie (PITR), przywracania geograficznego i długoterminowego przechowywania.

Właściwości kopii zapasowej  PITR Przywracanie geograficzne LTR
Typy kopii zapasowych SQL Pełne, różnicowe i transakcyjne kopie zapasowe dziennika. Replikowane kopie kopii zapasowych w celu przywracania do punktu w czasie. Tylko pełne kopie zapasowe.
Cel punktu odzyskiwania (recovery point objective, RPO)  Około 10 minut na podstawie rozmiaru obliczeniowego i ilości aktywności bazy danych.   Do 1 godziny na podstawie replikacji geograficznej. 1    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 Od 1 do 35 dni.  Włączone domyślnie tak samo jak źródło. 2 Nie jest włączone domyślnie. Przechowywanie wynosi do 10 lat.
Magazyn platformy Azure   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.
Konfigurowanie kopii zapasowych jako niezmiennych Nieobsługiwane Nieobsługiwane Nieobsługiwane
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 Obsługiwane Nieobsługiwane 3 Nieobsługiwane 3
Przywracanie za pośrednictwem witryny Azure Portal Tak Tak Tak
Przywracanie za pomocą programu PowerShell Tak Tak Tak
Przywracanie za pomocą interfejsu wiersza polecenia platformy Azure Tak Tak Tak

1 W przypadku aplikacji o krytycznym znaczeniu dla działania firmy, które wymagają dużych baz danych i muszą zapewnić ciągłość działania, zobacz Grupy trybu failover.

2 Wszystkie kopie zapasowe pitr są domyślnie przechowywane w magazynie geograficznie nadmiarowym, co oznacza, że przywracanie geograficzne jest domyślnie włączone.

3 Obejście polega na przywróceniu do nowego serwera i przeniesieniu zasobu do przeniesienia serwera do innej subskrypcji.

Przywracanie bazy danych z kopii zapasowej

Aby wykonać przywracanie, zobacz Przywracanie bazy danych z kopii zapasowych. Możesz wypróbować operacje konfiguracji i przywracania kopii zapasowej, korzystając z poniższych przykładów.

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

Harmonogram automatycznych kopii zapasowych

Usługa Azure SQL Managed Instance automatycznie zarządza kopiami zapasowymi, tworząc pełne, różnicowe i transakcyjne kopie zapasowe dziennika. Ten proces podlega harmonogramowi wewnętrznemu.

Początkowa kopia zapasowa

  • Nowe bazy danych: natychmiast po utworzeniu, przywróceniu lub przejściu zmian nadmiarowości kopii zapasowej następuje zainicjowanie pierwszej pełnej kopii zapasowej. Ta kopia zapasowa zwykle trwa w ciągu 30 minut, chociaż może to potrwać dłużej w przypadku większych baz danych.

  • Przywrócone bazy danych: czas trwania początkowej kopii zapasowej przywróconych baz danych jest różny i zależy od rozmiaru bazy danych. Przywrócone bazy danych lub kopie bazy danych, które są często większe, mogą wymagać więcej czasu na początkową kopię zapasową.

Zaplanowane pełne kopie zapasowe

  • Harmonogram tygodniowy: system ustawia tygodniowe pełne okno tworzenia kopii zapasowej dla całego wystąpienia.
  • Okno pełnej kopii zapasowej: jest to wyznaczony okres, w przypadku wykonywania pełnych kopii zapasowych. Mimo że system ma na celu ukończenie pełnych kopii zapasowych w tym oknie, w razie potrzeby kopia zapasowa może trwać poza zaplanowanym czasem, dopóki nie zostanie ukończona.
  • Planowanie adaptacyjne: algorytm tworzenia kopii zapasowych ocenia wpływ okna tworzenia kopii zapasowej na obciążenie około raz w tygodniu przy użyciu użycia procesora CPU i przepływności operacji we/wy jako wskaźników. W zależności od obciążenia poprzedniego tygodnia można dostosować pełne okno tworzenia kopii zapasowej.
  • Konfiguracja użytkownika: należy pamiętać, że użytkownicy nie mogą modyfikować ani wyłączać harmonogramu tworzenia kopii zapasowych.

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.

Użycie magazynu kopii zapasowych

Dzięki technologii tworzenia i przywracania kopii zapasowych programu SQL Server 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.

Harmonogramy tworzenia kopii zapasowych usługi Azure SQL Managed Instance obejmują 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 przez maksymalnie tydzień dłużej niż skonfigurowany okres przechowywania.

Innymi słowy, dla dowolnego punktu w czasie okresu 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.

Kopie zapasowe, które nie są już potrzebne do zapewnienia funkcji PITR, 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ą funkcji TDE, wszystkie pełne i różnicowe kopie zapasowe są kompresowane, aby zmniejszyć kompresję i koszty 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.

Ważne

W przypadku baz danych zaszyfrowanych za pomocą funkcji TDE pliki kopii zapasowych dzienników nie są kompresowane ze względu na wydajność. Kopie zapasowe dzienników dla nieszyfrowanych baz danych TDE są kompresowane.

Usługa Azure SQL Managed Instance 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 usługa PITR nie jest już możliwa, rozliczenia zostaną zatrzymane.

Ważne

Kopie zapasowe usuniętej bazy danych są przechowywane na potrzeby przywracania do punktu w czasie (PITR), co może zwiększyć koszty magazynowania w miarę przechowywania kopii zapasowych, mimo że baza danych jest usuwana. Aby zmniejszyć koszty, możesz ustawić okres przechowywania kopii zapasowych na 0 dni, ale tylko dla usuniętych baz danych. W przypadku zwykłych baz danych minimalny okres przechowywania wynosi 1 dzień.

Dostosowywanie użycia magazynów kopii zapasowych

Użycie magazynu kopii zapasowej do maksymalnego rozmiaru danych dla bazy danych nie jest naliczane. Nadmierne użycie magazynu kopii zapasowych zależy 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 zapasowej bazy danych do minimum dla Twoich potrzeb.
  • Unikaj wykonywania dużych operacji zapisu, takich jak ponowne kompilowanie indeksów, 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 nieklastrowanych.
  • W warstwie usługi Ogólnego przeznaczenia aprowizowany magazyn danych jest mniej kosztowny niż cena magazynu kopii zapasowych. Jeśli stale wysokie koszty magazynu kopii zapasowych są wysokie, warto rozważyć zwiększenie magazynu danych, aby zaoszczędzić na magazynie kopii zapasowych.
  • Użyj tempdb zamiast stałych tabel w logice aplikacji do przechowywania tymczasowych wyników lub danych przejściowych.
  • Używaj lokalnie nadmiarowego magazynu kopii zapasowych, jeśli to możliwe (na przykład środowisk deweloperskich/testowych).

Przechowywanie kopii zapasowej

Usługa Azure SQL Managed Instance zapewnia krótkoterminowe i długoterminowe przechowywanie kopii zapasowych. Przechowywanie krótkoterminowe umożliwia przechowywanie punktu w czasie przechowywania bazy danych w okresie przechowywania. Długoterminowe przechowywanie zapewnia kopie zapasowe dla różnych wymagań dotyczących zgodności.

Przechowywanie krótkoterminowe

W przypadku wszystkich nowych, przywróconych i kopiowanych baz danych usługa Azure SQL Managed Instance zachowuje wystarczające kopie zapasowe, aby zezwolić na przywracanie do punktu w czasie ostatnich 7 dni domyślnie. Tę konfigurację można zmienić w zakresie od 1 do 35 dni. Usługa wykonuje regularne pełne, różnicowe i dzienniki kopie zapasowe, aby upewnić się, że bazy danych można przywracać do dowolnego punktu w czasie w okresie przechowywania zdefiniowanym dla bazy danych lub wystąpienia zarządzanego.

Możesz określić opcję nadmiarowości magazynu kopii zapasowych dla usługi STR podczas tworzenia wystąpienia, a następnie zmienić je później. Jeśli zmienisz opcję nadmiarowości kopii zapasowej po utworzeniu wystąpienia, 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. 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 w celu zapewnienia dokładnego przywracania danych.

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. Jednak w przypadku usuniętej bazy danych okres przechowywania jest aktualizowany z 1–35 dni do 0–35 dni, co umożliwia ręczne usuwanie kopii zapasowych. Jeśli musisz przechowywać kopie zapasowe przez dłuższy niż maksymalny okres przechowywania krótkoterminowego wynoszący 35 dni, możesz włączyć długoterminowe przechowywanie.

Ważne

Jeśli usuniesz wystąpienie zarządzane, wszystkie bazy danych w tym wystąpieniu zarządzanym również zostaną usunięte i nie można będzie ich odzyskać. Nie można przywrócić usuniętego wystąpienia zarządzanego. Jeśli jednak skonfigurowano długoterminowe przechowywanie dla wystąpienia zarządzanego, kopie zapasowe LTR nie zostaną usunięte. Następnie można użyć tych kopii zapasowych, aby przywrócić bazy danych do innego wystąpienia zarządzanego w tej samej subskrypcji, do punktu w czasie wykonywania kopii zapasowej LTR. Aby dowiedzieć się więcej, zobacz Przywracanie długoterminowej kopii zapasowej.

Przechowywanie długoterminowe (LTR)

Za pomocą usługi SQL Managed Instance można skonfigurować przechowywanie pełnych kopii zapasowych LTR przez maksymalnie 10 lat w usłudze Azure Blob Storage. Po skonfigurowaniu zasad LTR pełne kopie zapasowe są automatycznie kopiowane do innego kontenera magazynu.

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

Nadmiarowość magazynu kopii zapasowych LTR w usłudze Azure SQL Managed Instance jest dziedziczona z nadmiarowości magazynu kopii zapasowych używanej przez funkcję STR w momencie, gdy zdefiniowano zasady LTR. Nie można go zmienić, nawet jeśli nadmiarowość magazynu kopii zapasowych STR zmieni się w przyszłości.

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

Usługa Azure SQL Managed Instance oblicza łączną rozliczaną kopię zapasową jako skumulowaną wartość we wszystkich plikach 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, zużycie magazynu kopii zapasowych stopniowo spadnie wraz ze starzeniem się starszych kopii zapasowych i usunięciem. 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.

Cena magazynu kopii zapasowych jest różna. Zależy to od wybranej opcji nadmiarowości magazynu kopii zapasowych i regionu. Opłata za magazyn kopii zapasowych jest naliczana na podstawie gigabajtów zużywanych miesięcznie, z taką samą stawką 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
  • Geo-zone-redundant price = published price x 3.4

Aby uzyskać informacje o cenach, zapoznaj się ze stroną cennika usługi Azure SQL Managed Instance.

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 zawiera tylko 1,8 TB, ponieważ opłaty są naliczane tylko za nadmiarowy magazyn kopii zapasowych, który został użyty.

W przypadku wystąpień zarządzanych łączny rozmiar rozliczanego magazynu kopii zapasowych jest agregowany na poziomie wystąpienia i jest obliczany w następujący sposób:

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

Łączna opłata za magazyn kopii zapasowych, jeśli istnieje, jest naliczana w gigabajtach miesięcznie dla każdego regionu zgodnie z szybkością nadmiarowości magazynu kopii zapasowych, która została użyta. Użycie magazynu kopii zapasowych zależy od obciążenia i rozmiaru poszczególnych baz danych 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 przyjęto założenie, ż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). Wystąpienie zarządzane SQL zgłasza potok rozliczeń platformy Azure, w którym baza danych używała 1 GB kopii zapasowej pitr co godzinę, przy stałej szybkości. Rozliczenia platformy Azure agregują to użycie i pokazują użycie 744 GB przez cały miesiąc. Koszt jest oparty na stawce dla gigabajtów miesięcznie w Twoim regionie.

Oto kolejny przykład. Załóżmy, że ta sama bezczynna baza danych ma wzrost przechowywania z 7 dni do 14 dni w połowie miesiąca. Ten wzrost powoduje podwojenie całkowitego magazynu kopii zapasowych do 1488 GB. Wystąpienie zarządzane SQL zgłaszałoby 1 GB użycia przez godziny od 1 do 372 (pierwsza połowa miesiąca). Będzie zgłaszać użycie jako 2 GB 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. Koszty utrzymania nie zwiększają się natychmiast. Zwiększają się one stopniowo każdego dnia, ponieważ kopie zapasowe rosną aż do osiągnięcia maksymalnego okresu przechowywania wynoszącego 14 dni.

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ć. Zużycie godzinowe magazynu kopii zapasowych zmienia się odpowiednio.

Każda różnicowa kopia zapasowa zawiera również wszystkie zmiany wprowadzone w bazie danych od czasu 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 starzeniu się starszego zestawu pełnych, różnicowych i kopii zapasowych dziennika.

Załóżmy na przykład, że duże działanie zapisu, takie jak ponowne kompilowanie indeksu, jest uruchamiane tuż po zakończeniu pełnej kopii zapasowej. Modyfikacje wprowadzone przez ponowną kompilację indeksu zostaną następnie uwzględnione:

  • W kopiach zapasowych dziennika transakcji wykonanych w czasie trwania odbudowy.
  • W następnej różnicowej kopii zapasowej.
  • W każdej różnicowej kopii zapasowej wykonanej do momentu następnego pełnego utworzenia kopii zapasowej.

Aby zmniejszyć rozmiar wszystkich różnicowych kopii zapasowych, zbyt duże różnicowe kopie zapasowe przekraczające 750 GB i stają się równe 75% rozmiaru bazy danych są promowane do pełnych kopii zapasowych, jeśli ostatnia pełna kopia zapasowa została wykonana ponad 24 godziny temu.

Monitorowanie kosztów

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

  1. Dodaj filtr dla nazwy usługi.

  2. Z listy rozwijanej wybierz pozycję sql managed instance for a managed instance (Wystąpienie zarządzane sql dla wystąpienia zarządzanego).

  3. Dodaj kolejny filtr podkategorii miernika.

  4. Aby monitorować koszty tworzenia kopii zapasowych pitR, wybierz z listy rozwijanej pozycję Magazyn kopii zapasowych wystąpienia zarządzanego. Mierniki są wyświetlane tylko wtedy, gdy zużycie magazynu kopii zapasowych istnieje.

    Aby monitorować koszty tworzenia kopii zapasowych LTR, na liście rozwijanej wybierz pozycję sql managed instance — ltr backup storage. Mierniki są wyświetlane tylko wtedy, gdy zużycie magazynu kopii zapasowych istnieje.

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

Screenshot that shows an analysis of backup storage costs.

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 wystąpień zarządzanych nie będą obecne dla klientów, którzy nie mają wdrożonego wystąpienia zarządzanego. Podobnie liczniki magazynu nie będą widoczne dla zasobów, które nie korzystają z magazynu. Jeśli nie ma użycia magazynu kopii zapasowych PITR ani LTR, te mierniki nie będą widoczne.

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 funkcji TDE, zobacz Transparent Data Encryption with SQL Managed Instance (Szyfrowanie transparent data encryption za pomocą usługi SQL Managed Instance).

Integralność kopii zapasowej

Wszystkie kopie zapasowe bazy danych są wykonywane z opcją CHECKSUM, aby zapewnić dodatkową integralność kopii zapasowej. Automatyczne testowanie automatycznych kopii zapasowych baz danych przez zespół inżynierów usługi Azure SQL nie jest obecnie dostępne dla usługi Azure SQL Managed Instance. Zaplanuj przywracanie kopii zapasowych testowych i bazę danych DBCC CHECKDB w bazach danych w usłudze SQL Managed Instance wokół obciążenia.

Mimo że system nie weryfikuje integralności kopii zapasowych, nadal istnieje wbudowana ochrona kopii zapasowych, która powiadamia firmę Microsoft o problemie z usługą tworzenia kopii zapasowych. Ponadto firma Microsoft obsługuje Cię, jeśli wystąpi problem z tworzeniem kopii zapasowej, na przykład jeśli nie zostanie wykonana pełna kopia zapasowa, usługa tworzenia kopii zapasowej jest zablokowana, kopia zapasowa dziennika nie jest zgodna z umową SLA lub jeśli sprzęt lub oprogramowanie kopii zapasowej jest uszkodzone.

Używanie usługi 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 dla wystąpienia zarządzanego SQL przy użyciu usługi 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. Usługa Azure Policy pomaga zachować zgodność tych zasobów ze standardami firmowymi i umowami dotyczącymi poziomu usług. Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Policy.

Wbudowane zasady nadmiarowości magazynu kopii zapasowych

Aby wymusić wymagania dotyczące rezydencji danych na poziomie organizacji, możesz przypisać zasady do subskrypcji przy użyciu witryny Azure Portal lub programu Azure PowerShell. Jeśli na przykład przypiszesz następujące wbudowane zasady na poziomie subskrypcji lub grupy zasobów, użytkownicy w subskrypcji nie będą mogli utworzyć wystąpienia zarządzanego z geograficznie nadmiarowym magazynem kopii zapasowych za pośrednictwem witryny Azure Portal lub programu Azure PowerShell: wystąpienia zarządzane SQL powinny unikać używania nadmiarowości kopii zapasowych GRS.

Aby uzyskać pełną listę wbudowanych definicji zasad dla usługi SQL Managed Instance, 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 wymusić miejsce przechowywania danych podczas tworzenia bazy danych przy użyciu języka T-SQL, użyj parametru LOCAL lub ZONE jako danych wejściowych dla parametru BACKUP_STORAGE_REDUNDANCY w instrukcji CREATE DATABASE.

Zgodność z przepisami

Jeśli domyślne przechowywanie nie spełnia wymagań dotyczących zgodności, możesz zmienić okres przechowywania pitr. Aby uzyskać więcej informacji, zobacz Zmienianie okresu przechowywania kopii zapasowych pitr.

Uwaga

Artykuł Zmiana ustawień automatycznego tworzenia kopii zapasowych zawiera kroki usuwania danych osobowych z urządzenia lub usługi i może służyć do wspierania zobowiązań wynikających z RODO. Aby uzyskać ogólne informacje o RODO, zobacz sekcję RODO w Centrum zaufania Microsoft i sekcję RODO w portalu zaufania usług.

Następne kroki