Udostępnij za pośrednictwem

Automatyczne kopie zapasowe w 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. Dzięki usłudze Azure SQL Managed Instance, kopie zapasowe silnika bazy danych SQL Server są automatycznie zarządzane przez Microsoft i przechowywane na kontach pamięci Azure zarządzanych przez Microsoft.

Użyj tych kopii zapasowych, aby przywrócić bazę danych do określonego punktu w czasie w skonfigurowanym okresie przechowywania, do 35 dni. Jeśli jednak reguły ochrony danych wymagają, aby kopie zapasowe są dostępne przez dłuższy czas (do 10 lat), można skonfigurować zasady przechowywania długoterminowego (LTR) dla każdej 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.

Uwaga

Automatyczne pełne kopie zapasowe są inicjowane raz w tygodniu na podstawie harmonogramu określonego przez firmę Microsoft. Kopie zapasowe inicjowane przez użytkownika mają priorytet nad automatycznymi pełnymi kopiami zapasowymi, więc długotrwała kopia zapasowa tylko do kopiowania może mieć wpływ na czas następnej automatycznej pełnej kopii zapasowej.

Kopia zapasowa dziennika końcowego jest tworzona za każdym razem, gdy baza danych lub wystąpienie zarządzane SQL zostanie usunięte.

Nadmiarowość magazynu kopii zapasowych

Domyślnie usługa Azure SQL Managed Instance przechowuje kopie zapasowe w geograficznie nadmiarowych obiektach magazynowych blob, które są replikowane 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 w innym regionie w przypadku awarii.

Mechanizm nadmiarowości magazynu przechowuje wiele kopii Twoich danych, dzięki czemu są chronione przed planowanymi 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 redundancji przechowywania, zobacz Nadmiarowość danych.

Konfigurację nadmiaru magazynu kopii zapasowych można ustawić przy tworzeniu instancji i później zaktualizować na poziomie instancji. Zmiany, które wprowadzisz w istniejącym wystąpieniu, będą miały 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 w momencie ich tworzenia. 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

Zmiana nadmiarowości kopii zapasowej to operacja zarządzania aktualizacjami, która inicjuje tryb failover.

Można wybrać jedną z następujących opcji przechowywania z redundancją dla kopii zapasowych.

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

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

  • Strefowo redundantna pamięć masowa (ZRS): tworzy synchronizowane kopie zapasowe w trzech strefach dostępności platformy Azure w regionie podstawowym. Jest ona obecnie dostępna w niektórych regionach.

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

  • Magazyn geograficznie nadmiarowy (GRS): służy do synchronicznego kopiowania kopii zapasowych 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 przedstawiający opcję magazynu geograficznie nadmiarowego (GRS).

  • Magazyn geograficznie nadmiarowy (GZRS): Łączy wysoką dostępność dzięki nadmiarowości w różnych strefach dostępności z ochroną przed awariami regionalnymi zapewnianą 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 przedstawiający opcję magazynowania z nadmiarowością strefową (GZRS).

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 wszystkie pokazują regiony, które mają wiele stref dostępności (wielostrefowe). Istnieją jednak pewne regiony, które zapewniają tylko jedną strefę dostępności i nie obsługują 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, która może znajdować się w tym samym wystąpieniu co oryginalna baza danych lub w innym wystąpieniu, lecz w tej samej subskrypcji i regionie. Używa innej nazwy, aby uniknąć zastępowania oryginalnej bazy danych. Możesz również użyć portalu Azure, aby przywrócić kopię zapasową bazy danych w określonym punkcie czasu do wystąpienia w innej subskrypcji niż w twoim wystąpieniu źródłowym.

    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 określonego momentu w czasie w czasie przechowywania, w tym czas jej 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 geograficznie redundantną kopią zapasową. 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ę z Przeglądem przechowywania długoterminowego.

Przywracanie możliwości i funkcji

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 danych LTR
Typy kopii zapasowych SQL Pełne, różnicowe i transakcyjne kopie zapasowe. Replikowane kopie kopii zapasowych PITR. 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.
Przechowywanie Azure Domyślnie redundantny geograficznie. Opcjonalnie można skonfigurować magazyn strefowo nadmiarowy lub lokalnie nadmiarowy. Dostępne, gdy nadmiarowość przechowywania kopii zapasowych przywracania do punktu w czasie (PITR) 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 Nie obsługiwane Nieobsługiwany
Aktualizacja zasad3 Musi być zgodne lub zaktualizowane Musi być zgodna lub uaktualniona Musi być zgodna lub uaktualniona
Przywracanie nowej bazy danych w tym samym regionie Wspierane Wspierane Obsługiwane
Przywracanie nowej bazy danych w innym regionie Nieobsługiwany 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 Brak obsługi 4 Nie obsługiwane 4
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 kluczowym znaczeniu dla działalności biznesowej, które wymagają dużych baz danych i muszą zapewnić ciągłość działania firmy, zobacz grupy przełączania awaryjnego.
2 Wszystkie kopie zapasowe PITR są domyślnie przechowywane w geograficznie nadmiarowym magazynie, co oznacza, że przywracanie geograficzne jest automatycznie włączone.
3 Kopie zapasowe bazy danych pobrane z wystąpień skonfigurowanych przy użyciu zasad aktualizacji programu SQL Server 2022 można przywrócić do wystąpień skonfigurowanych przy użyciu programu SQL Server 2022 lub zasad aktualizacji Zawsze na bieżąco. Kopie zapasowe bazy danych pobrane z wystąpień skonfigurowanych przy użyciu zawsze aktualnych zasad aktualizacji można przywrócić tylko do wystąpień skonfigurowanych przy użyciu zawsze aktualnych zasad aktualizacji.
4 Obejście polega na przywróceniu do nowego serwera i użyciu funkcji "Przenoszenie 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 CLI platformy Azure Azure PowerShell
Zmienianie przechowywania kopii zapasowych SQL Database / Wystąpienie zarządzane SQL Baza danych SQL / Zarządzane wystąpienie SQL Baza danych SQL / Zarządzane wystąpienie SQL
Zmienianie długoterminowego przechowywania kopii zapasowych SQL Database / Wystąpienie zarządzane SQL SQL Database / Zarządzane wystąpienie SQL Baza danych SQL / Zarządzane wystąpienie SQL
Przywracanie bazy danych z punktu w czasie SQL Database / Zarządzane wystąpienie SQL SQL Database / Wystąpienie zarządzane SQL Baza danych SQL / Wystąpienie zarządzane SQL
Przywracanie usuniętej bazy danych SQL Database / Zarządzane wystąpienie SQL SQL Database / SQL Managed Instance SQL Database / Zarządzane wystąpienie SQL
Przywracanie bazy danych z usługi Azure Blob Storage Instancja zarządzana 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

Natychmiast po utworzeniu, przywróceniu lub zmianie nadmiarowości kopii zapasowej baza danych zostaje zainicjowana do wykonania pierwszej pełnej kopii zapasowej. Ta kopia zapasowa zwykle kończy się w ciągu 30 minut, chociaż może to potrwać dłużej. Czas trwania początkowej kopii zapasowej przywróconych baz danych jest różny i zależy od rozmiaru bazy danych. Większe przywrócone bazy danych lub kopie bazy danych mogą wymagać więcej czasu na początkową kopię zapasową.

Ważne

Pierwsza pełna kopia zapasowa nowej bazy danych ma priorytet nad innymi kopiami zapasowymi bazy danych, dlatego jest to pierwsza kopia zapasowa wykonywana w pierwszym oknie pełnej kopii zapasowej. Jeśli pełne okno tworzenia kopii zapasowej jest już aktywne, a kopie zapasowe innych baz danych są tworzone, pierwsza pełna kopia zapasowa nowej bazy danych jest wykonywana natychmiast po zakończeniu pełnej kopii zapasowej innej bazy danych.

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 czas na wykonywanie 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 punktowego staje się dostępna po zakończeniu początkowego tworzenia kopii zapasowej dziennika transakcji, które następuje po wykonaniu 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 oraz kopie zapasowe dzienników transakcji przez okres do tygodnia 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, ponieważ kopie zapasowe są przechowywane nawet po usunięciu bazy danych. 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ń.

Dostosuj zużycie przestrzeni 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 masz ciągle wysokie koszty przechowywania kopii zapasowych, warto rozważyć zwiększenie pojemności przechowywania danych, aby zaoszczędzić na kosztach 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. Krótkoterminowe przechowywanie pozwala na odzyskiwanie punktów w czasie (PITR) w okresie 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 kopiowanych baz danych usługa Azure SQL Managed Instance domyślnie utrzymuje wystarczającą ilość kopii zapasowych, aby umożliwić przywrócenie do punktu w czasie w ciągu ostatnich 7 dni. Tę konfigurację można zmienić w zakresie od 1 do 35 dni. Usługa wykonuje regularne pełne, różnicowe i logowe 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 magazynowania kopii zapasowych dla usługi STR podczas tworzenia swojego wystąpienia, a następnie zmienić ją 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 przechowywania do momentu wygaśnięcia okresu zatrzymania. Zgodnie z opisem w sekcji Użycie magazynu na kopie zapasowe, kopie zapasowe przechowywane w celu włączenia przywracania do punktu w czasie mogą być starsze niż okres retencji, aby zapewnić dokładne przywracanie 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 zarządzanego wystąpienia w tej samej subskrypcji, z uwzględnieniem stanu z chwili wykonania 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 zasobnika 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 kopii zapasowych użytej przez STR w momencie definiowania zasad LTR. Nie można go zmienić, nawet jeśli redundancja 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 LTR.

Koszty magazynu kopii zapasowych

Azure SQL Managed Instance oblicza całkowitą rozliczaną przestrzeń na kopie zapasowe jako sumaryczną wartość we wszystkich plikach kopii zapasowych. Co godzinę ta wartość jest zgłaszana do potoku rozliczeń platformy Azure. Proces agreguje to godzinowe użycie, aby obliczyć zużycie 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, aby były możliwe do przywrócenia, wszystkie trzy typy kopii zapasowych są usuwane 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 kopii zapasowych w następujący sposób:

  • Locally-redundant price (LRS) = Zone-redundant price (ZRS) = published price
  • Geo-redundant price (GRS) = Geo-zone-redundant price (GZRS) = published price x 2

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

Całkowita ilość płatnego magazynu kopii zapasowych, jeśli taka istnieje, jest naliczana w gigabajtach miesięcznie za każdy region, według stawki za nadmiarowość wykorzystanego magazynu kopii zapasowych. 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). Zarządzane wystąpienie SQL zgłasza do potoku rozliczeniowego platformy Azure, że baza danych zużywa 1 GB kopii zapasowej PITR każdej godziny, z równomierną 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 czas przechowywania w tej samej nieużywanej bazie danych został przedłużony z 7 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 wykazywać zużycie jako 2 GB w godzinach od 373 do 744 (druga część 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, gdy starszy zestaw pełnych, różnicowych i kopii zapasowych dziennika transakcji utraci ważność.

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 czasu następnej pełnej 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ę usługi Scope, a następnie filtruj okres i usługę, która cię interesuje, w następujący sposób:

  1. Dodaj filtr dla nazwy usługi.

  2. Z listy rozwijanej wybierz zarządzane wystąpienie SQL.

  3. Dodaj kolejny filtr dla podkategorii licznika.

  4. pl-PL: Aby monitorować koszty tworzenia kopii zapasowych PITR, wybierz z listy rozwijanej pozycję Magazyn kopii zapasowych zarządzanego wystąpienia. Mierniki są widoczne tylko wtedy, gdy jest zużycie magazynu kopii zapasowych.

    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 jest wykorzystanie przestrzeni na kopie zapasowe.

Podkategorie magazynu i zasobów obliczeniowych mogą cię również zainteresować, ale nie są one 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 dla wystąpień zarządzanych nie będą dostępne dla klientów, którzy nie wdrożyli wystąpienia zarządzanego. Podobnie liczniki magazynu nie będą widoczne dla zasobów, które nie korzystają z magazynu. Jeśli nie ma zużycia zasobów 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).

Firma Microsoft jest w pełni odpowiedzialna za przechowywanie i rotację kluczy dla baz danych przy użyciu kluczy zarządzanych przez usługę (SMK). Kopie zapasowe (PITR lub LTR) pobrane z wystąpień z włączonym SMK w TDE można przywrócić przez Microsoft.

Automatyczne kopie zapasowe przechowywane na kontach magazynu zarządzanego przez platformę Azure są automatycznie szyfrowane przez usługę Azure Storage. Dowiedz się więcej o szyfrowaniu usługi Azure Storage dla danych magazynowanych.

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 testowych kopii zapasowych oraz operację DBCC CHECKDB na bazach danych w usłudze SQL Managed Instance, dostosowując to do swojego 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ącą wbudowaną zasadę na poziomie subskrypcji lub grupy zasobów, użytkownicy w tej subskrypcji nie będą mogli tworzyć zarządzanych wystąpień z geograficznie nadmiarowym magazynem kopii zapasowych poprzez portal Azure ani 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ść

Jeśli domyślne przechowywanie nie spełnia wymagań dotyczących zgodności, możesz zmienić okres retencji 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