Kopie zapasowe z długoterminowym przechowywaniem — Azure SQL Database i Azure SQL Managed Instance

Dotyczy:Azure SQL DatabaseAzure SQL Managed Instance

Ten artykuł zawiera przegląd koncepcyjny długoterminowego przechowywania kopii zapasowych dla Azure SQL Database i Azure SQL Managed Instance. Długoterminowe przechowywanie można skonfigurować przez maksymalnie 10 lat w przypadku kopii zapasowych dla Azure SQL Database (w tym w warstwie usługi Hiperskala) i Azure SQL Managed Instance.

Aby rozpocząć korzystanie z funkcji kopii zapasowej długoterminowego przechowywania, zobacz:

Ważne

Niektóre starsze interfejsy API używane na potrzeby operacji przechowywania długoterminowego (LTR) są przestarzałe i nie są już obsługiwane. Unikaj używania starszych poleceń cmdlet programu PowerShell, takich jak Copy-AzSqlDatabaseLongTermRetentionBackup. Zamiast tego użyj obsługiwanych metod przywracania opisanych w tym artykule.

Jak działa przechowywanie długoterminowe

Wiele aplikacji ma regulacje prawne, wymogi zgodności lub inne przyczyny biznesowe, które wymagają przechowywania kopii zapasowych bazy danych dłużej niż okres 1–35 dni udostępniany przez krótkoterminowy okres przechowywania kopii automatycznych. Długoterminowe przechowywanie kopii zapasowych (LTR) opiera się na pełnych kopiach zapasowych bazy danych tworzonych automatycznie przez usługę Azure SQL. Aby uzyskać więcej informacji, zobacz Automatyczne kopie zapasowe w Azure SQL Database lub Automatyczne kopie zapasowe w Azure SQL Managed Instance.

Korzystając z funkcji LTR, można przechowywać określone pełne kopie zapasowe usługi SQL Database i SQL Managed Instance w nadmiarowym Azure Blob Storage z konfigurowalnymi zasadami przechowywania do 10 lat. Kopie zapasowe LTR można następnie przywrócić jako nową bazę danych. Jeśli skonfigurowano zasady LTR, automatyczne kopie zapasowe są kopiowane do różnych blobów na potrzeby długoterminowego przechowywania, którego można następnie użyć do przywrócenia bazy danych do określonego punktu w czasie. Proces kopiowania jest zadaniem w tle, które nie ma wpływu na wydajność obciążenia bazy danych. Zasady LTR dla każdej bazy danych mogą również określać, jak często są tworzone kopie zapasowe LTR.

Uwaga

Aby włączyć LTR, można zdefiniować zasady przy użyciu kombinacji czterech parametrów: tygodniowego przechowywania kopii zapasowych (W), miesięcznego przechowywania kopii zapasowych (M), przechowywania kopii zapasowych rocznie (Y) i tygodnia roku (WeekOfYear). W przypadku określenia W jedna kopia zapasowa co tydzień jest kopiowana do magazynu długoterminowego. Jeśli określisz M, pierwsza kopia zapasowa każdego miesiąca zostanie skopiowana do długoterminowej pamięci masowej. Jeśli określisz wartość Y, jedna kopia zapasowa w tygodniu określona przez WeekOfYear zostanie skopiowana do magazynu długoterminowego. Jeśli określony WeekOfYear jest w przeszłości po skonfigurowaniu polityki, pierwsza kopia zapasowa LTR zostanie utworzona w następnym roku. Każda kopia zapasowa jest przechowywana w magazynie długoterminowym zgodnie z parametrami zasad skonfigurowanymi podczas tworzenia kopii zapasowej LTR.

Zmiany w polityce LTR mają zastosowanie tylko do przyszłych kopii zapasowych. Jeśli na przykład zmodyfikujesz tygodniowy okres przechowywania kopii zapasowych (W), miesięczny okres przechowywania kopii zapasowych (M) lub roczny okres przechowywania kopii zapasowych (Y), nowe ustawienie przechowywania ma zastosowanie tylko do nowych kopii zapasowych. Przechowywanie istniejących kopii zapasowych nie jest modyfikowane. Zasady LTR można skonfigurować dla każdej bazy danych w Azure SQL Database i Azure SQL Managed Instance. Jeśli zamierzasz usunąć stare kopie zapasowe LTR przed upływem ich okresu przechowywania, możesz usunąć kopie zapasowe ręcznie.

Uwaga

Zarówno w Azure SQL Database, jak i Azure SQL Managed Instance, po włączeniu zasad dotyczących długoterminowego przechowywania kopii zapasowych (LTR) po raz pierwszy dla bazy danych, najnowsza pełna kopia zapasowa z przywracania do określonego punktu w czasie (PITR) jest kopiowana do magazynu długoterminowego.

Przykłady polityki LTR:

  • W=0, M=0, Y=5, WeekOfYear=3

    Trzecia pełna kopia zapasowa każdego roku jest przechowywana przez pięć lat.

  • W=0, M=3, Y=0

    Pierwsza pełna kopia zapasowa każdego miesiąca jest przechowywana przez trzy miesiące.

  • W=12, M=0, Y=0

    Każda cotygodniowa pełna kopia zapasowa jest przechowywana przez 12 tygodni.

  • W=6, M=12, Y=10, WeekOfYear=20

    Każda cotygodniowa pełna kopia zapasowa jest przechowywana przez sześć tygodni. Z wyjątkiem pierwszej pełnej kopii zapasowej każdego miesiąca, która jest przechowywana przez 12 miesięcy. Z wyjątkiem pełnej kopii zapasowej wykonanej w 20 tygodniu roku, która jest przechowywana przez 10 lat.

W poniższej tabeli przedstawiono częstotliwość i wygaśnięcie długoterminowych kopii zapasowych dla następującej zasady.

W=12 weeks (84 dni), M=12 months (365 dni), Y=10 years (3,650 dni), WeekOfYear=20 (tydzień po 13 maja)

Następujące daty znajdują się w standardzie ISO 8601 (YYYY-MM-DD).

Kopia zapasowa PITR do LTR Wygaśnięcie W Wygaśnięcie M Wygaśnięcie Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
04.04.2018 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 2018-07-18
2018-05-02 2019-04-27
2018-05-09 2018-08-01
2018-05-16 2028-05-13
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 2019-06-01
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
2018-07-18 2018-10-10
2018-07-25 2018-10-17
2018-08-01 2019-07-27
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Jeśli zmodyfikujesz tę zasadę i ustawisz W=0 (brak cotygodniowych kopii zapasowych), cotygodniowe kopie zapasowe będą przechowywane do momentu ich wygaśnięcia, a następnie usługa zachowa tylko miesięczne i roczne kopie zapasowe. Żadne przyszłe tygodniowe kopie zapasowe nie są przechowywane w ramach polityki LTR. Ilość miejsca potrzebnego do przechowywania tych kopii zapasowych zmniejsza się odpowiednio.

Ważne

Czas poszczególnych kopii zapasowych LTR jest kontrolowany przez Microsoft. Nie można ręcznie utworzyć kopii zapasowej LTR ani kontrolować chronometrażu tworzenia kopii zapasowej. Po skonfigurowaniu zasad LTR może upłynąć do siedmiu dni, zanim pierwsza kopia zapasowa LTR pojawi się na liście dostępnych kopii zapasowych.

Jeśli usuniesz serwer logiczny lub wystąpienie zarządzane SQL, zostaną również usunięte wszystkie bazy danych na tym serwerze lub wystąpieniu zarządzanym. Nie można przywrócić usuniętego serwera logicznego ani wystąpienia zarządzanego SQL. Jeśli jednak skonfigurowano usługę LTR dla bazy danych, kopie zapasowe LTR nie są usuwane i mogą służyć do przywracania baz danych na inny serwer lub wystąpienie zarządzane w tej samej subskrypcji do punktu w czasie, w którym została wykonana kopia zapasowa LTR.

Podobnie, jeśli usuniesz bazę danych, kopie zapasowe LTR nie zostaną usunięte i będą przechowywane przez skonfigurowany okres przechowywania. Te kopie zapasowe można przywrócić do tego samego serwera lub innego serwera w tej samej subskrypcji.

Replikacja geograficzna i długotrwałe przechowywanie kopii zapasowych

Jeśli używasz aktywnej replikacji geograficznej lub grup trybu failover jako rozwiązania do zapewniania ciągłości działania, przygotuj się na ewentualne przejścia w tryb failover i skonfiguruj te same zasady LTR w pomocniczej bazie danych lub wystąpieniu, co w podstawowej bazie danych. Koszt magazynu LTR nie wzrasta, ponieważ kopie zapasowe nie są generowane z replik. Kopie zapasowe są tworzone dopiero po tym, jak jednostka pomocnicza stanie się jednostką podstawową, aby zapewnić nieprzerwane generowanie kopii zapasowych typu LTR w przypadku wyzwolenia failover i przeniesienia jednostki podstawowej do regionu pomocniczego.

Gdy oryginalna podstawowa baza danych zostanie odzyskana po awarii, która spowodowała przejście w tryb failover, staje się nową pomocniczą. W związku z tym tworzenie kopii zapasowej nie zostanie wznowione na nowym pomocniczym serwerze, a istniejące zasady LTR nie zaczną obowiązywać, dopóki nie stanie się ponownie podstawowym.

Obwód zabezpieczeń sieci i przywracanie LTR (podgląd)

Uwaga

Obwód zabezpieczeń sieciowych (podgląd) dotyczy tylko Azure SQL Database. Azure SQL Managed Instance nie jest zasobem onboardowanym, więc ta sekcja go nie dotyczy. Aktualną listę można znaleźć w artykule Onboarded private link resources.

Przywracanie LTR to operacja zarządzana przez platformę, która przywraca bazę danych z długoterminowej kopii zapasowej na docelowy serwer logiczny. Gdy którykolwiek z logicznych serwerów należy do perymetru, przywracanie podlega regułom dostępu tego perymetru.

Usługa sprawdza ruch wychodzący na serwerze źródłowym, kiedy ten serwer nadal istnieje, oraz ruch przychodzący na serwerze docelowym. Jeśli źródłowy serwer logiczny został usunięty, może być przeprowadzona tylko kontrola przychodząca po stronie docelowej.

Obsługiwane konfiguracje

Przywracanie LTR działa zarówno w trybie przejściowym, jak i wymuszonym. W trybie przejściowym operacje przywracania kończą się powodzeniem bez reguł dostępu. Skonfiguruj reguły przed przejściem na tryb wymuszony.

W trybie wymuszonym obsługiwane są następujące konfiguracje:

Serwer źródłowy Serwer docelowy Zasady dostępu są wymagane
Na obwodzie W tym samym obszarze None. Dostęp między zasobami w tym samym obrębie jest zawsze dozwolony.
Na obwodzie W innym obszarze Ruch wychodzący po stronie źródła, ruch przychodzący po stronie celu.
Na obwodzie Poza obwodem Ruch wychodzący ze źródła.
Poza obwodem Na obwodzie Kieruje się na cel.
Usunięto Na obwodzie Na kursie do celu.
Poza obwodem Poza obwodem None.

Przywracanie LTR nie wymaga zarządzanej tożsamości.

Konfiguruj reguły dostępu dla przywracania LTR

  1. Połącz każdy logiczny serwer z jego strefą brzegową, jeśli jeszcze tego nie zrobiłeś. Pomiń ten krok dla serwera, który znajduje się poza obwodem zabezpieczeń, lub dla usuniętego serwera źródłowego.
  2. Jeśli serwer źródłowy znajduje się w obwodzie, a serwer docelowy nie jest w tym samym obwodzie, dodaj regułę wychodzącą w profilu źródłowym z ustawieniem Destination type na FQDN oraz z w pełni kwalifikowaną nazwą domenową serwera docelowego.
  3. Jeśli docelowy serwer znajduje się w perymetrze, a źródłowy nie jest w tym samym perymetrze, dodaj regułę przychodzącą w profilu docelowym. Żądanie przywrócenia pochodzi z infrastruktury zarządzania Azure SQL, a nie z serwera źródłowego. W regule można dozwolić jedno z tych źródeł:
    • Identyfikator subskrypcji serwera źródłowego (zalecany).
    • Znacznik serwisowy (zalecane).
    • Zakresy adresów IP. W chmurze publicznej dokument Azure IP Ranges and Service Tags - Public Cloud wymienia każdy tag usługi oraz jego zakresy adresów IP. Nazwa tagu usługi to SqlManagement. Microsoft nie publikuje tych zakresów według regionów, więc zezwól na wszystkie.
  4. Gdy serwery są nadal w trybie przejściowym, przeprowadź przywracanie i sprawdź dzienniki diagnostyczne granicy zabezpieczeń sieciowych pod kątem nieoczekiwanych odmów.
  5. Przełącz się na tryb wymuszony dopiero po przejściu wszystkich testów diagnostycznych.

Ograniczenia i różnice w zachowaniach

  • Nie możesz usunąć logicznego serwera, który ma kopie zapasowe LTR, gdy jego skojarzenie z obwodem jest w trybie wymuszonym. Niezmienne kopie zapasowe LTR blokują także usuwanie, niezależnie od tego, czy serwer znajduje się w strefie obwodowej. Więcej informacji można znaleźć w artykule Niezmienne długoterminowe kopie zapasowe i usuwanie serwerów logicznych.
  • Jeśli usuniesz serwer źródłowy, gdy jego skojarzenie jest w trybie przejściowym, usługa nie może już odczytać metadanych strefy tego serwera, więc może weryfikować tylko stronę docelową przywracania. Uwzględnij tę lukę, jeśli polegasz na walidacji po stronie źródła jako kontroli.
  • W trybie przejściowym przywracanie kończy się sukcesem nawet wtedy, gdy wymagane reguły są nieobecne. W trybie wymuszonym to samo przywracanie jest blokowane.

Konfigurowanie długoterminowego przechowywania kopii zapasowych

Ważne

Niektóre starsze interfejsy API używane na potrzeby operacji przechowywania długoterminowego (LTR) są przestarzałe i nie są już obsługiwane. Unikaj używania starszych poleceń cmdlet programu PowerShell, takich jak Copy-AzSqlDatabaseLongTermRetentionBackup. Zamiast tego użyj obsługiwanych metod przywracania opisanych w tym artykule.

Długoterminowe przechowywanie kopii zapasowych można skonfigurować przy użyciu portalu Azure i programu PowerShell dla Azure SQL Database i Azure SQL Managed Instance. Aby przywrócić bazę danych z magazynu LTR, możesz wybrać określoną kopię zapasową na podstawie sygnatury czasowej. Bazę danych można przywrócić do dowolnego istniejącego serwera lub wystąpienia zarządzanego w ramach tej samej subskrypcji co oryginalna baza danych. Aby uzyskać pełną listę możliwości przywracania, ograniczeń i funkcji, zobacz Restore capabilities and features in Azure SQL Managed Instance (Funkcje i możliwości przywracania w usłudze Azure SQL Managed Instance

Gdy żądanie przywrócenia zostanie zainicjowane w ciągu ostatnich siedmiu dni okresu przechowywania LTR, kopia zapasowa LTR zostanie usunięta dopiero po zakończeniu operacji przywracania, nawet jeśli okres przechowywania wygasł.

Uwaga

Przywracanie baz danych między warstwą usługi Hiperskala a innymi warstwami usług Azure SQL Database nie jest obecnie obsługiwane.

W Azure SQL Managed Instance można użyć zadań agenta SQL do zaplanowania kopii zapasowych baz danych typu copy-only i przenieść je na własne konto magazynu jako alternatywę.

  • Przechowuj kopie zapasowe przez okres dłuższy niż 10 lat.
  • Przechowuj codzienne kopie swoich baz danych przez okres dłuższy niż 35 dni.
  • Przechowuj kopie zapasowe bazy danych w niezmiennym przechowywaniu.

Wskazówka

Jeśli używasz kopii zapasowych LTR w celu spełnienia wymagań zgodności lub innych wymagań o znaczeniu krytycznym, rozważ przeprowadzenie okresowych prób odzyskiwania w celu sprawdzenia, czy kopie zapasowe LTR można przywrócić i czy przywracanie powoduje oczekiwany stan bazy danych.

Uwaga

Kopie zapasowe LTR zależą od pomyślnego wykonania pełnych kopii zapasowych. Pełny dziennik transakcyjny może zapobiec zaplanowanej pełnej kopii zapasowej, co może zapobiec kopii zapasowej LTR. Change Data capture (CDC) oraz inne funkcje zapobiegające skracaniu logów transakcyjnych mogą opóźnić kopię zapasową LTR, która jest udana dopiero po zakończeniu pełnej kopii zapasowej. Oceń funkcje zapobiegające obcinaniu logów transakcyjnych i rozważ ich tymczasowe wyłączenie do czasu powrotu operacji backup.

Następny krok

Zarządzanie długoterminowym przechowywaniem kopii zapasowych w Azure SQL Database

Zarządzanie długoterminową retencją kopii zapasowych w Azure SQL Managed Instance

Powiązana zawartość

Ponieważ kopie zapasowe bazy danych chronią dane przed przypadkowym uszkodzeniem lub usunięciem, są one istotną częścią każdej strategii ciągłości działania i odzyskiwania po awarii.

  • Ostatnia aktualizacja o