Tworzenie kopii zapasowej programu SQL Server zawsze w grupach dostępności

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 grupy dostępności są rozłożone między regionami/subskrypcjami/środowiskiem lokalnym i platformą Azure, należy pamiętać o kilku kwestiach.

Uwaga

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

Preferencja tworzenia kopii zapasowej używana przez grupę dostępności SQL usługi Azure Backup 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 kopii zapasowych dziennika transakcji i kopii zapasowych tylko do kopiowania preferencja kopii zapasowej grupy dostępności jest brana pod uwagę podczas podejmowania decyzji o węźle, w którym zostanie uruchomiona kopia zapasowa.

Preferencja kopii zapasowej grupy dostępności	Pełne i różnicowe kopie zapasowe są uruchamiane	Kopie zapasowe tylko do kopiowania i dziennika są pobierane z
Podstawowe	Replika podstawowa	Replika podstawowa
Tylko pomocnicza	Replika podstawowa	Każda z replik pomocniczych
Preferuj pomocniczą	Replika podstawowa	Preferowane są repliki pomocnicze, ale kopie zapasowe mogą być również uruchamiane w repliki podstawowej.
Brak/dowolny	Replika podstawowa	Dowolna replika

Rozszerzenie kopii zapasowej obciążenia jest instalowane w węźle, gdy jest zarejestrowane 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 grupy dostępności i rozszerzenia kopii zapasowej obciążenia w tych węzłach są synchronizowane między sobą, aby zdecydować, który węzeł 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ł jest kontynuowany z zadaniem tworzenia kopii zapasowej, podczas gdy zadanie wyzwalane w innych węzłach zostaje pominięte.

Uwaga

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

Rejestrowanie węzłów grupy dostępności 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.

• Musisz zarejestrować węzeł podstawowy w magazynie (w przeciwnym razie nie można wykonać pełnych kopii zapasowych).
• Jeśli preferencja tworzenia kopii zapasowej jest tylko pomocnicza, musisz zarejestrować co najmniej jeden węzeł pomocniczy w magazynie (w przeciwnym razie nie można wykonać pełnych kopii zapasowych tylko do dziennika/kopiowania).

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

Rozważmy następujące wdrożenie grupy dostępności jako odwołanie.

Na podstawie powyższego przykładowego wdrożenia grupy dostępności należy wziąć pod uwagę różne zagadnienia:

• 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.
• Nie można zarejestrować maszyny wirtualnej VM3 w magazynie 1, ponieważ znajduje się w innej subskrypcji.
• Nie można zarejestrować maszyny wirtualnej VM4 w magazynie 1, ponieważ znajduje się w innym regionie.
• Jeśli preferencja tworzenia kopii zapasowej jest tylko pomocnicza, maszyna WIRTUALNA1 (podstawowa) i maszyna wirtualna VM2 (pomocnicza) muszą być zarejestrowane w magazynie 1 (ponieważ pełne kopie zapasowe wymagają węzła podstawowego i 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 może być zarejestrowana w magazynie 2 w subskrypcji 2, a bazy danych grupy dostępności będą wyświetlane w celu ochrony w magazynie 2, ale z powodu braku węzła podstawowego w magazynie 2 konfigurowanie kopii zapasowych zakończy się niepowodzeniem.
• Podobnie, podczas gdy maszyna WIRTUALNa VM4 może być zarejestrowana w magazynie 4 w regionie 2, konfigurowanie kopii zapasowych zakończy się niepowodzeniem, ponieważ węzeł podstawowy nie jest zarejestrowany w magazynie 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 będą kontynuowane z węzła podstawowego/pomocniczego na podstawie preferencji tworzenia kopii zapasowej.

Uwaga

Podziały łańcucha dzienników nie występują w trybie failover, jeśli tryb failover nie pokrywa się z kopią zapasową.

Na podstawie powyższego przykładowego wdrożenia grupy dostępności poniżej przedstawiono różne możliwości pracy w trybie failover:

• Przechodzenie w tryb failover do maszyny wirtualnej VM2
  • Pełne i różnicowe kopie zapasowe będą wykonywane z maszyny wirtualnej VM2.
  • Pełne kopie zapasowe dziennika i kopiowania będą wykonywane z maszyny wirtualnej VM1 lub VM2 na podstawie preferencji tworzenia kopii zapasowej.
• Przechodzenie w tryb failover do maszyny wirtualnej VM3 (inna subskrypcja)
  • Ponieważ kopie zapasowe nie są skonfigurowane w magazynie 2, żadne kopie zapasowe nie zostaną wykonane.
  • Jeśli preferencja tworzenia kopii zapasowej nie jest tylko pomocnicza, kopie zapasowe można skonfigurować teraz w magazynie 2, 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.
• Przechodzenie w tryb failover do maszyny wirtualnej VM4 (inny region)
  • Ponieważ kopie zapasowe nie są skonfigurowane w magazynie 4, żadne kopie zapasowe nie zostaną wykonane.
  • 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 włączania kopii zapasowych grup zabezpieczeń obejmujących subskrypcje lub regiony platformy 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 i przejście w tryb failover do innych węzłów odbywa się bardzo rzadko, skonfigurowanie kopii zapasowej w tym pierwszym regionie może być wystarczające. Jeśli przejścia w tryb failover do innego regionu/subskrypcji występują często i przez dłuższy czas, warto również aktywnie konfigurować kopie zapasowe w innym regionie.

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

• Pełne/różnicowe kopie zapasowe zostaną wykonane pomyślnie tylko w magazynie, który ma węzeł podstawowy. Te kopie zapasowe w innych magazynach będą nadal kończyły 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

  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 dzienników między dwoma magazynami, zalecamy ustawienie preferencji tworzenia kopii zapasowej na Podstawowa. 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 grupy dostępności poniżej przedstawiono kroki umożliwiające utworzenie kopii zapasowej ze wszystkich węzłów. Założeniem jest to, że preferencje tworzenia kopii zapasowej są spełnione we wszystkich krokach.

Krok 1. Włączanie kopii zapasowych w regionie 1, subskrypcji 1 (magazyn 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. Konfigurowanie kopii zapasowych baz danych grupy dostępności w magazynie 2.
3. W tym momencie:
   1. Pełne/różnicowe kopie zapasowe zakończy się niepowodzeniem w magazynie 1, ponieważ żaden z zarejestrowanych węzłów nie może 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. Powrót po awarii grupy dostępności do maszyny wirtualnej VM1.

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

Tak samo jak w kroku 2.

Tworzenie kopii zapasowej grupy dostępności obejmującej platformę Azure i lokalnie

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 grupy dostępności w wielu regionach, aby umożliwić tworzenie kopii zapasowych replik na platformie Azure. Jeśli nastąpi przejście w tryb failover do węzła lokalnego, pełne i różnicowe kopie zapasowe na platformie Azure zaczną się wieść. Kopie zapasowe dzienników mogą być kontynuowane do momentu przerwania łańcucha dzienników/15 dni.

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

Obecnie limity ograniczania kopii zapasowej mają zastosowanie na poziomie poszczególnych maszyn. Domyślny limit to 20 — jeśli więcej niż 20 kopii zapasowych zostanie wyzwolonych współbieżnie, zostanie uruchomionych pierwszych 20, a pozostałe zostaną uruchomione w kolejce. Po zakończeniu uruchomionych zadań kolejkowane zostaną uruchomione.

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

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 wyzwolonych w węźle 1 i 35 z nich zostanie w kolejce. Niektóre z nich to kopie zapasowe bazy danych grupy dostępności. Jednak w 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 w jednym węźle i działają w 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ł Node 1 nie działa i dlatego zadania z tego miejsca nie są dostępne 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 grupy dostępności jest większa niż limit ograniczania przepustowości. 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 tworzenia kopii zapasowej na Wartość Podstawowa lub Pomocnicza — wówczas tylko jeden węzeł może wykonać kopie zapasowe, a drugi zawsze zostanie zwolniony.
• 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 będą mogły wykonywać kopie zapasowe.

Rozliczenia dla kopii zapasowych grupy dostępności

Tak samo jak autonomiczne wystąpienie SQL, jedno wystąpienie grupy dostępności, 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:

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

Wystąpienie chronione/wystąpienie rozliczeniowe	Bazy danych rozważane do obliczania rozmiaru frontonu
AG1	DB1, DB2
AG2	DB4
Maszyna wirtualna 2	DB3
Maszyna wirtualna 3	DB6
Maszyna wirtualna 4	DB5

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

Usługa Azure Backup uwzględnia wystąpienie SQL lub nazwę grupy dostępności\Nazwa bazy danych jako unikatową nazwę bazy danych. Gdy autonomiczna baza danych była chroniona, jego unikatowa nazwa to StandAloneInstanceName\DBName. Gdy zostanie przeniesiona pod grupę dostępności, unikatowa nazwa zmieni się na AGName\DBName. Tworzenie kopii zapasowych autonomicznej bazy danych zakoń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ć z zachowaniem danych, aby uniknąć wyzwalania i niepowodzenia w przyszłości kopii zapasowych. Podobnie, gdy chroniona baza danych grupy dostępności 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 pod kątem ochrony z poziomu wystąpienia autonomicznego. Będzie to traktowane jako nowe źródło danych z oddzielnym łańcuchem punktów odzyskiwania. Starszą ochronę bazy danych grupy dostępności można zatrzymać z zachowaniem danych, aby uniknąć wyzwalania i niepowodzenia przyszłych kopii zapasowych.

Dodawanie/usuwanie węzła do grupy 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 usługi 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 grupy dostępności.

Następnie nowy węzeł synchronizuje informacje o harmonogramie tworzenia kopii zapasowych grupy dostępności z usługi Azure Backup i rozpoczyna uczestniczyć w zsynchronizowany proces 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, dodanie węzła, rozszerzenia obciążenia wykrywają zmianę topologii grupy dostępności w tym przypadku i informują usługę Azure Backup. Usługa uruchamia przepływ pracy usuwania konfiguracji węzła w usuniętym węźle, aby wyczyścić harmonogramy tworzenia kopii zapasowych baz danych grupy dostępności i usunąć powiązane metadane grupy dostępności.

Wyrejestrowywanie węzła grupy dostępności 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 grupy dostępności. Po zakończeniu przepływu pracy wyrejestrowania węzła można wyrejestrować ten węzeł.

Przywracanie bazy danych z usługi Azure Backup do grup dostępności SQL grupy dostępności nie obsługuje bezpośredniego przywracania bazy danych do grupy dostępności. Baza danych musi zostać przywrócona do autonomicznego 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 listę zduplikowanych elementów na liście Chronione elementy, a na stronie Konfigurowanie kopii zapasowej lub na liście Elementów z możliwością ochrony są wyświetlane te elementy, dopóki nie chcesz przechowywać danych kopii zapasowej.

• Jeśli nie chcesz, aby dane kopii zapasowej ze starszej grupy dostępności zostały zatrzymane, zatrzymaj operację tworzenia kopii zapasowej przy użyciu opcji Zatrzymaj ochronę i usuń dane dla starszego elementu przed ponownym utworzeniem i zaplanowaniem kopii zapasowych w nowej grupy dostępności.

  Uwaga

  Zatrzymaj ochronę i usuń dane jest operacją destrukcyjną.

• Grupę dostępności można utworzyć ponownie po wykonaniu jednego z powyższych procesów zatrzymywania ochrony, aby uniknąć błędów tworzenia kopii zapasowych.

Następne kroki

Instrukcje:

• Przywracanie kopii zapasowych baz danych programu SQL Server
• Zarządzanie kopiami zapasowymi baz danych programu SQL Server