Udostępnij za pomocą

Utwórz kopie zapasowe dla grup dostępności Always On w SQL Server

Usługa Azure Backup oferuje kompleksową obsługę tworzenia kopii zapasowych zawsze w grupach dostępności programu SQL Server, jeśli wszystkie węzły znajdują się w tym samym regionie i subskrypcji co magazyn usługi Recovery Services. Jeśli jednak węzły dostępności AG są rozmieszczone w różnych regionach, subskrypcjach, środowiskach lokalnych oraz na platformie Azure, należy pamiętać o kilku istotnych kwestiach.

Uwaga / Notatka

  • Tworzenie kopii zapasowych baz danych podstawowej grupy dostępności nie jest obsługiwane przez usługę Azure Backup.
  • Aby dowiedzieć się więcej na temat obsługiwanych konfiguracji i scenariuszy, zobacz macierz wsparcia kopii zapasowych SQL.

Preferencja tworzenia kopii zapasowej używana przez usługę Azure Backup SQL AG obsługuje pełne i różnicowe kopie zapasowe tylko z repliki podstawowej. Dlatego te zadania tworzenia kopii zapasowej są zawsze uruchamiane w węźle Podstawowym niezależnie od preferencji tworzenia kopii zapasowej. W przypadku pełnych kopii zapasowych tylko do kopiowania oraz kopii zapasowych dziennika transakcji, preferencja kopii zapasowej dla grupy dostępności jest brana pod uwagę przy wyborze węzła, na którym zostanie przeprowadzona kopia zapasowa.

Preferencja kopii zapasowej AG Pełne i różnicowe kopie zapasowe działają kopie zapasowe Copy-Only i dzienników są pobierane z
Podstawowy Replika podstawowa Replika podstawowa
Tylko drugorzędne Replika podstawowa Każda z replik pomocniczych
Preferuj drugorzędną Replika podstawowa Preferowane są repliki pomocnicze, ale kopie zapasowe mogą być również uruchamiane w repliki podstawowej.
Nie wybrano/dowolnie Replika podstawowa Dowolna replika

Rozszerzenie do tworzenia kopii zapasowych obciążenia jest instalowane na węźle podczas jego rejestracji w usłudze Azure Backup. Gdy baza danych grupy dostępności jest skonfigurowana do tworzenia kopii zapasowej, harmonogramy tworzenia kopii zapasowych są wypychane do wszystkich zarejestrowanych węzłów grupy dostępności. Harmonogramy są uruchamiane na wszystkich węzłach AG, a rozszerzenia kopii zapasowej dla obciążenia na tych węzłach synchronizują się między sobą, aby zdecydować, który węzeł może wykonać kopię zapasową. Wybór węzła zależy od typu kopii zapasowej i preferencji tworzenia kopii zapasowej, jak wyjaśniono w sekcji 1.

Wybrany węzeł kontynuuje zadanie tworzenia kopii zapasowej, podczas gdy zadanie uruchomione na innych węzłach zostaje przerwane, czyli pominięte.

Uwaga / Notatka

Usługa Azure Backup nie uwzględnia priorytetów kopii zapasowych ani replik podczas podejmowania decyzji między replikami pomocniczymi.

Zarejestruj węzły AG w magazynie usługi Recovery Services

Magazyn usługi Recovery Services obsługuje tworzenie kopii zapasowych baz danych tylko z maszyn wirtualnych w tym samym regionie i subskrypcji co magazyn.

  • Zarejestruj węzeł podstawowy w magazynie (w przeciwnym razie nie można wykonać pełnych kopii zapasowych).
  • Zarejestruj co najmniej jeden węzeł podrzędny w magazynie (w przeciwnym razie pełne kopie zapasowe, które są przeznaczone tylko do dziennika/kopiowania, nie mogą zostać utworzone), jeśli preferencja tworzenia kopii zapasowej to tylko dla pomocniczych.

Konfigurowanie kopii zapasowych baz danych grupy dostępności (AG) kończy się niepowodzeniem z kodem błędu FabricSvcBackupPreferenceCheckFailedUserError, jeśli powyższe warunki nie zostaną spełnione.

Rozważmy następujące wdrożenie AG jako punkt odniesienia.

Diagram wdrożenia AG jako odniesienie.

Opierając się na danym przykładowym wdrożeniu AG, należy rozważyć różne aspekty:

  • Ponieważ węzeł podstawowy znajduje się w regionie 1 i subskrypcji 1, magazyn usługi Recovery Services (magazyn 1) musi znajdować się w regionie 1 i subskrypcji 1 w celu ochrony tej grupy dostępności.
  • VM3 nie można zarejestrować do Vault 1, ponieważ jest w innej subskrypcji.
  • Nie można zarejestrować VM4 w magazynie 1, ponieważ znajduje się on w innym regionie.
  • Jeśli preferencja tworzenia kopii zapasowej jest tylko pomocnicza, VM1 (podstawowy) i VM2 (pomocniczy) muszą być zarejestrowane w Vault 1 (ponieważ pełne kopie zapasowe wymagają węzła podstawowego, a dzienniki wymagają węzła pomocniczego). W przypadku innych preferencji tworzenia kopii zapasowych maszyna VM1 (podstawowa) musi być zarejestrowana w magazynie 1, maszyna VM2 jest opcjonalna (ponieważ wszystkie kopie zapasowe mogą być uruchamiane w węźle podstawowym).
  • Podczas gdy maszyna wirtualna VM3 mogłaby być zarejestrowana w magazynie 2 w subskrypcji 2, a bazy danych grupy dostępności (AG) byłyby wtedy widoczne do ochrony w magazynie 2, to z powodu braku węzła podstawowego w magazynie 2 konfigurowanie kopii zapasowych zakończyłoby się niepowodzeniem.
  • Podobnie, podczas gdy maszyna wirtualna VM4 ma być zarejestrowana w magazynie skarbcowym 4 w regionie 2, konfigurowanie kopii zapasowych zakończy się niepowodzeniem, ponieważ węzeł podstawowy nie jest zarejestrowany w magazynie skarbcowym 4.

Obsługa trybu failover

Po przełączeniu grupy dostępności w tryb failover do jednego z węzłów pomocniczych:

  • Pełne i różnicowe kopie zapasowe będą kontynuowane z nowego węzła podstawowego, jeśli są zarejestrowane w magazynie.
  • Pełne kopie zapasowe dziennika i kopii tylko-do-odczytu będą wykonywane z węzła podstawowego lub pomocniczego w zależności od preferencji tworzenia kopii zapasowej.

Uwaga / Notatka

Podział łańcucha logów nie występuje w trybie failover, jeśli tryb failover nie pokrywa się z wykonywaniem kopii zapasowej.

Na podstawie powyższego przykładowego wdrożenia grupy dostępności poniżej przedstawiono różne możliwości przełączania awaryjnego.

  • Przełączenie do maszyny wirtualnej VM2
    • Pełne i różnicowe kopie zapasowe będą wykonywane z maszyny wirtualnej VM2.
    • Pełne kopie zapasowe dzienników i kopie tylko-do-odczytu będą wykonywane z VM1 lub VM2 w zależności od preferencji tworzenia kopii zapasowej.
  • Przełączenie na tryb awaryjny do VM3 w innej subskrypcji
    • Ponieważ kopie zapasowe nie są skonfigurowane w Vault 2, żadne kopie zapasowe się nie wykonają.
    • Jeśli preferencja tworzenia kopii zapasowej nie dotyczy tylko zapasowego węzła, można teraz skonfigurować kopie zapasowe w skrzynce 2, ponieważ węzeł podstawowy jest w niej zarejestrowany. Może to jednak prowadzić do konfliktów/niepowodzeń tworzenia kopii zapasowej. Więcej informacji na ten temat znajduje się w temacie Konfigurowanie kopii zapasowych dla grupy dostępności w wielu regionach.
  • Przełączenie na maszynę wirtualną VM4 (w innym regionie)
    • Ponieważ kopie zapasowe nie są skonfigurowane w systemie Vault 4, żadne kopie zapasowe nie będą wykonywane.
    • Jeśli preferencja tworzenia kopii zapasowej nie jest tylko pomocnicza, kopie zapasowe można skonfigurować teraz w usłudze Vault 4, ponieważ węzeł podstawowy jest zarejestrowany w tym magazynie. Może to jednak prowadzić do konfliktów/niepowodzeń tworzenia kopii zapasowej. Więcej informacji na ten temat znajduje się w temacie Konfigurowanie kopii zapasowych dla grupy dostępności w wielu regionach.

Konfigurowanie kopii zapasowych dla grupy dostępności w wielu regionach

Magazyn usługi Recovery Services nie obsługuje kopii zapasowych między subskrypcjami ani między regionami. W tej sekcji podsumowano sposób konfigurowania kopii zapasowych grup dostępności obejmujących subskrypcje i regiony Azure oraz powiązane zagadnienia.

  • Oceń, czy naprawdę musisz włączyć kopie zapasowe ze wszystkich węzłów. Jeśli jeden region/subskrypcja ma większość węzłów grupy dostępności (AG), a przejście w tryb failover do innych węzłów zdarza się bardzo rzadko, skonfigurowanie kopii zapasowej w tym pierwszym regionie może być wystarczające. Jeśli failovery do innego regionu lub subskrypcji występują często i trwają długo, warto również proaktywnie konfigurować kopie zapasowe w innych regionach.

  • Każdy magazyn, w którym jest włączona kopia zapasowa, będzie miał własny zestaw łańcuchów punktów przywracania. Przywracanie z tych punktów odzyskiwania można wykonać tylko na maszynach wirtualnych zarejestrowanych w tym magazynie.

  • Pełne i różnicowe kopie zapasowe mogą być pomyślnie wykonane tylko w magazynie zawierającym węzeł podstawowy. Kopie zapasowe w innych magazynach będą nadal kończyć się niepowodzeniem.

  • Kopie zapasowe dzienników będą nadal działać w poprzednim magazynie do momentu uruchomienia kopii zapasowej dziennika w nowym magazynie (czyli w magazynie, w którym znajduje się nowy węzeł podstawowy) i przerywają łańcuch dzienników dla starego magazynu.

    Uwaga / Notatka

    Istnieje sztywny limit 15 dni, po upływie którego kopie zapasowe dzienników zaczną uruchomić się niepowodzeniem.

  • Pełne kopie zapasowe tylko do kopiowania będą działać we wszystkich magazynach.

  • Ochrona w każdym magazynie jest traktowana jako odrębne źródło danych i jest rozliczana oddzielnie.

Aby uniknąć konfliktów kopii zapasowych logów między dwoma magazynami, zalecamy ustawienie preferencji kopii zapasowej na Podstawowy. Następnie, w zależności od tego, który magazyn ma węzeł podstawowy, również wykona kopie zapasowe dziennika.

Na podstawie powyższego przykładowego wdrożenia AG, poniżej przedstawiono kroki umożliwiające wykonywanie kopii zapasowej ze wszystkich węzłów. Założenie jest takie, że preferencje dotyczące kopii zapasowych są spełnione na każdym etapie.

Krok 1: Włącz kopie zapasowe w regionie 1, subskrypcji 1 (Skarbiec 1)

Ponieważ węzeł podstawowy znajduje się w regionie i subskrypcji, typowe kroki umożliwiające włączenie kopii zapasowych będą działać.

Krok 2. Włączanie kopii zapasowych w regionie 1, subskrypcja 2 (magazyn 2)

  1. Przełącz grupę dostępności w tryb failover do maszyny wirtualnej VM3, aby węzeł podstawowy był obecny w magazynie 2.
  2. Skonfiguruj kopie zapasowe baz danych AG w magazynie 2.
  3. W tym momencie:
    1. Pełne/różnicowe kopie zapasowe zakończą się niepowodzeniem w Vault 1, ponieważ żaden z zarejestrowanych węzłów nie jest w stanie wykonać tej kopii zapasowej.
    2. Kopie zapasowe dzienników zostaną wykonane pomyślnie w magazynie 1 do momentu uruchomienia kopii zapasowej dziennika w magazynie 2 i przerwania łańcucha dzienników dla magazynu 1.
  4. Przywróć AG do maszyny wirtualnej VM1.

Krok 3: Włącz kopie zapasowe w regionie 2, subskrypcja 1 (magazyn 4)

Tak samo jak w kroku 2.

Tworzenie kopii zapasowej Grupy Dostępności, która obejmuje zarówno platformę Azure, jak i środowisko lokalne.

Nie można uruchomić usługi Azure Backup dla programu SQL Server lokalnie. Jeśli węzeł podstawowy znajduje się na platformie Azure, a preferencje tworzenia kopii zapasowej są spełnione przez węzły na platformie Azure, możesz postępować zgodnie z powyższymi wskazówkami dla dostępności w wielu regionach, aby włączyć tworzenie kopii zapasowych dla replik na platformie Azure. Jeśli nastąpi failover do węzła lokalnego, pełne i różnicowe kopie zapasowe w Azure zaczną się psuć. Kopie zapasowe dzienników mogą być kontynuowane do momentu, gdy nastąpi przerwanie łańcucha kopii zapasowych lub upłynie 15 dni.

Ograniczanie przepustowości dla zadań tworzenia kopii zapasowych w bazie danych grupy dostępności

Obecnie limity dotyczące ograniczania kopii zapasowych mają zastosowanie na poziomie poszczególnych maszyn. Domyślny limit to 20 — jeśli więcej niż 20 kopii zapasowych zostanie uruchomionych współbieżnie, uruchomionych zostanie pierwszych 20, a pozostałe trafią do kolejki. Gdy uruchomione zadania się zakończą, rozpoczną się te oczekujące w kolejce.

Tę wartość można zmienić na mniejszą, jeśli współbieżne kopie zapasowe powodują obciążenie pamięci, operacji we/wy oraz procesora w węźle. Ponieważ ograniczanie jest na poziomie węzła, w przypadku niezrównoważonych węzłów grupy dostępności może dojść do problemów z synchronizacją kopii zapasowych. Aby to zrozumieć, rozważmy na przykład 2-węzłową grupę dostępności (AG).

Na przykład pierwszy węzeł ma chronione 50 autonomicznych baz danych, a oba węzły mają chronione 5 baz danych grupy dostępności. W rzeczywistości węzeł 1 ma zaplanowane 55 zadań tworzenia kopii zapasowych bazy danych, natomiast węzeł 2 ma tylko 5. Ponadto wszystkie te kopie zapasowe są konfigurowane do uruchamiania w tym samym czasie co godzinę. W pewnym momencie wszystkie 55 kopii zapasowych zostanie uruchomionych na Węźle 1 i 35 z nich zostanie umieszczonych w kolejce. Niektóre z nich to kopie zapasowe bazy danych AG. Jednak na węźle 2 kopie zapasowe bazy danych grupy dostępności będą wykonywane bez kolejkowania.

Ponieważ zadania bazy danych grupy dostępności są kolejkowane na jednym węźle i działają na innym, synchronizacja kopii zapasowych (wymieniona w sekcji 6) nie będzie działać prawidłowo. Węzeł 2 może zakładać, że węzeł 1 jest wyłączony i dlatego zadania z niego nie są przesyłane do synchronizacji. Może to prowadzić do przerwania łańcucha dzienników lub dodatkowych kopii zapasowych, ponieważ oba węzły mogą niezależnie wykonywać kopie zapasowe.

Podobny problem może wystąpić, jeśli liczba chronionych baz danych AG jest większa niż limit ograniczania. W takim przypadku można utworzyć kopię zapasową dla bazy danych DB1 w węźle 1, podczas gdy jest ona uruchamiana w węźle 2.

Zalecamy użycie następujących preferencji tworzenia kopii zapasowych, aby uniknąć tych problemów z synchronizacją:

  • W przypadku grupy dostępności z 2 węzłami ustaw opcję Preferencja kopii zapasowej na Podstawowa lub Pomocnicza — wówczas tylko jeden węzeł może wykonać kopie zapasowe, a drugi zawsze zrezygnuje.
  • W przypadku grupy dostępności z więcej niż 2 węzłami ustaw opcję Preferencja tworzenia kopii zapasowej na Podstawowa — wówczas tylko węzeł podstawowy może wykonywać kopie zapasowe, inne zostaną wykluczone.

Rozliczenia za kopie zapasowe AG

Tak samo jak samodzielne wystąpienie SQL, jedno wystąpienie AG, którego kopia zapasowa jest uznawana za jedno chronione wystąpienie. Łączny rozmiar frontonu wszystkich chronionych baz danych w wystąpieniu jest naliczany. Rozważ następujące wdrożenie:

Diagram przedstawiający obliczanie chronionych wystąpień baz danych.

Wystąpienia chronione są obliczane w następujący sposób:

Instancja chroniona oraz instancja rozliczeniowa Bazy danych rozważane do obliczania rozmiaru frontonu
AG1 DB1, DB2
AG2 DB4
Maszyna wirtualna 2 DB3
Maszyna wirtualna 3 DB6
Maszyna wirtualna VM4 DB5

Przenoszenie chronionej bazy danych do lub z grupy dostępności

Usługa Azure Backup uważa wystąpienie SQL lub nazwę grupy dostępności/nazwę bazy danych za unikatową nazwę bazy danych. Gdy autonomiczna baza danych była chroniona, jego unikatowa nazwa to StandAloneInstanceName\DBName. Gdy zostanie przeniesiona pod AG, unikatowa nazwa zmieni się na AGName\DBName. Tworzenie kopii zapasowych autonomicznej bazy danych zacznie kończyć się niepowodzeniem z kodem błędu: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Baza danych musi być skonfigurowana do ochrony z poziomu grupy dostępności. Będzie to traktowane jako nowe źródło danych z oddzielnym łańcuchem punktów odzyskiwania. Starszą ochronę autonomicznej bazy danych można zatrzymać, zachowując dane w nienaruszonym stanie, aby uniknąć uruchamiania i niepowodzeń przyszłych kopii zapasowych. Podobnie, gdy chroniona baza danych AG wychodzi z grupy dostępności i staje się autonomiczną bazą danych, tworzenie kopii zapasowych kończy się niepowodzeniem z kodem błędu: UserErrorBackupFailedDatabaseMovedOutOfAG.

Baza danych musi być skonfigurowana do ochrony przed działaniem w trybie autonomicznym. Będzie to traktowane jako nowe źródło danych z oddzielnym łańcuchem punktów odzyskiwania. Starszą metodę ochrony bazy danych grupy dostępności można zatrzymać, zachowując dane, aby unikać uruchamiania i niepowodzeń przyszłych kopii zapasowych.

Dodawanie/usuwanie węzła w grupie dostępności

Po dodaniu nowego węzła do grupy dostępności skonfigurowanej do tworzenia kopii zapasowych rozszerzenia kopii zapasowej obciążenia uruchomione w już zarejestrowanych węzłach grupy dostępności wykrywają zmianę topologii grupy dostępności i informują usługę Azure Backup podczas następnego zaplanowanego zadania odnajdywania bazy danych. Gdy ten nowy węzeł zostanie zarejestrowany do tworzenia kopii zapasowych w tym samym magazynie Recovery Services co inne istniejące węzły, usługa Azure Backup wyzwala przepływ pracy, który konfiguruje ten nowy węzeł z wymaganymi metadanymi do wykonywania kopii zapasowych AG.

Następnie nowy węzeł synchronizuje informacje o harmonogramie tworzenia kopii zapasowych grupy dostępności z usługi Azure Backup i rozpoczyna uczestniczenie w zsynchronizowanym procesie tworzenia kopii zapasowej. Jeśli nowy węzeł nie jest w stanie zsynchronizować harmonogramów tworzenia kopii zapasowych i uczestniczyć w kopiach zapasowych, wyzwalanie ponownej rejestracji w węźle wymusza również ponowną konfigurację węzła dla kopii zapasowych grupy dostępności. Podobnie, w przypadku dodania węzła, rozszerzenia dla obciążenia wykrywają zmianę topologii grupy dostępności i informują o tym usługę Azure Backup. Usługa rozpoczyna przepływ pracy przywrócenia konfiguracji w usuniętym węźle, aby wyczyścić harmonogramy tworzenia kopii zapasowych baz danych AG i usunąć powiązane metadane AG.

Wyrejestruj węzeł AG z usługi Azure Backup

Jeśli węzeł jest częścią grupy dostępności, która ma co najmniej jedną bazę danych skonfigurowaną do tworzenia kopii zapasowej, usługa Azure Backup nie zezwala na anulowanie rejestracji tego węzła. Zapobiega to przyszłym niepowodzeniom tworzenia kopii zapasowych, jeśli nie można spełnić preferencji tworzenia kopii zapasowej bez tego węzła. Aby wyrejestrować węzeł, należy najpierw usunąć go z AG. Po zakończeniu przepływu pracy dekonfiguracji węzła i wyczyszczeniu tego węzła, można go wyrejestrować.

Przywracanie bazy danych z Azure Backup do grup dostępności SQL nie obsługuje bezpośredniego przywracania bazy danych do grup dostępności. Baza danych musi zostać przywrócona do niezależnego wystąpienia SQL, a następnie musi zostać przyłączona do Grupy dostępności.

Scenariusze ponownego tworzenia grupy dostępności dla serwera bazy danych SQL

Ponowne tworzenie grupy dostępności, zduplikowanych grup dostępności i elementów kopii zapasowej są wyświetlane jako chronione elementy lub chronione elementy w następujących scenariuszach:

  • Ponowne tworzenie grup zabezpieczeń, które są już chronione, są wyświetlane jako zduplikowane grupy Zabezpieczeń na stronie Konfigurowanie kopii zapasowej i na liście Chronione elementy . Jeśli chcesz zachować dane kopii zapasowej, które są już obecne w starszej grupy dostępności, zatrzymaj tworzenie kopii zapasowej przy użyciu opcji Zatrzymaj ochronę i zachowaj dane przed ponownym utworzeniem i zaplanowaniem kopii zapasowych w nowych elementach grupy dostępności.

    Zgodnie z projektem, usługa Azure Backup wyświetla zduplikowane elementy na liście Chronione elementy, a także na stronie Konfigurowanie kopii zapasowej lub na liście Elementów z możliwością ochrony i wyświetla te elementy tak długo, jak chcesz przechowywać dane kopii zapasowej.

  • Jeśli nie chcesz danych kopii zapasowej ze starszej grupy dostępności, zatrzymaj operację tworzenia kopii zapasowej, korzystając z opcji Zatrzymaj ochronę i usuń dane dla starszego elementu, zanim ponownie utworzysz i zaplanujesz kopie zapasowe w nowej grupie dostępności.

    Ostrzeżenie

    Zatrzymanie ochrony i usunięcie danych to operacja destrukcyjna.

  • Grupę dostępności można utworzyć ponownie po zakończeniu jednego z wymienionych procesów zatrzymania ochrony, aby uniknąć błędów podczas tworzenia kopii zapasowych.

Dalsze kroki

Dowiedz się, jak:

Treści powiązane

  • Last updated on