Bazy danych, topologie wdrażania i tworzenie kopii zapasowych

Artykuł
03/25/2024

Azure DevOps Server 2022 r. | Azure DevOps Server 2020 r. | Azure DevOps Server 2019 r.

Wdrożenie można chronić przed utratą danych, tworząc regularny harmonogram tworzenia kopii zapasowych baz danych, od których Azure DevOps Server zależy. Aby całkowicie przywrócić wdrożenie Azure DevOps Server, najpierw wykonaj kopię zapasową wszystkich Azure DevOps Server baz danych.

Jeśli wdrożenie obejmuje SQL Server Reporting Services, należy również utworzyć kopię zapasową baz danych używanych przez usługę Azure DevOps w ramach tych składników. Aby zapobiec błędom synchronizacji lub błędom niezgodności danych, należy zsynchronizować wszystkie kopie zapasowe z tym samym sygnaturą czasową. Najprostszym sposobem zapewnienia pomyślnej synchronizacji jest użycie oznaczonych transakcji. Rutynowo oznaczając powiązane transakcje w każdej bazie danych, ustanawiasz szereg typowych punktów odzyskiwania w bazach danych. Aby uzyskać szczegółowe wskazówki dotyczące tworzenia kopii zapasowej wdrożenia pojedynczego serwera korzystającego z raportowania, zobacz Tworzenie harmonogramu tworzenia kopii zapasowych i planu.

Tworzenie kopii zapasowych baz danych

Chroń wdrożenie usługi Azure DevOps przed utratą danych, tworząc kopie zapasowe bazy danych. W poniższej tabeli i towarzyszących ilustracjach pokazano, które bazy danych mają być kopiami zapasowymi, oraz przedstawiono przykłady sposobu, w jaki te bazy danych mogą być fizycznie dystrybuowane we wdrożeniu.

Typ bazy danych	Produkt	Wymagany składnik?
Baza danych konfiguracji	Azure DevOps Server	Tak
Baza danych magazynu	Azure DevOps Server	Tak
Bazy danych kolekcji projektów	Azure DevOps Server	Tak
Raportowanie baz danych	SQL Server Reporting Services	Nie
Bazy danych analizy	SQL Server Analysis Services	Nie

Topologie wdrażania

Na podstawie konfiguracji wdrożenia wszystkie bazy danych, które wymagają utworzenia kopii zapasowej, mogą znajdować się na tym samym serwerze fizycznym, co w tej przykładowej topologii.

Uwaga

W tym przykładzie nie ma usług Reporting Services ani produktów SharePoint, dlatego nie trzeba tworzyć kopii zapasowych baz danych skojarzonych z raportami, analizami ani produktami programu SharePoint.

Prosta struktura bazy danych Azure DevOps Server

Alternatywnie bazy danych mogą być dystrybuowane między wieloma serwerami i farmami serwerów. W tym przykładzie topologii należy utworzyć kopię zapasową następujących baz danych, które są skalowane na sześć serwerów lub farm serwerów:

baza danych konfiguracji
baza danych magazynu
bazy danych kolekcji projektów, które znajdują się w klastrze SQL Server
baza danych kolekcji znajdująca się na serwerze autonomicznym z uruchomionym SQL Server
bazy danych znajdujące się na serwerze z uruchomionymi usługami Reporting Services
baza danych znajdująca się na serwerze z uruchomionymi usługami Analysis Services
bazy danych administracyjnych produktów programu SharePoint i bazy danych zbioru witryn dla obu aplikacji internetowych programu SharePoint

Jeśli bazy danych programu SharePoint są skalowane na wiele serwerów, nie można utworzyć kopii zapasowej za pomocą funkcji Zaplanowane kopie zapasowe. Należy ręcznie skonfigurować kopie zapasowe dla tych baz danych i upewnić się, że te kopie zapasowe są synchronizowane z kopiami zapasowymi bazy danych Azure DevOps Server. Aby uzyskać więcej informacji, zobacz Ręczne tworzenie kopii zapasowych serwera Azure DevOps Server.

Złożona struktura bazy danych Azure DevOps Server

W obu tych przykładach nie trzeba tworzyć kopii zapasowych żadnych klientów łączących się z serwerem. Jednak może być konieczne ręczne wyczyszczenie pamięci podręcznych dla Azure DevOps Server na komputerach klienckich, zanim będą mogły ponownie nawiązać połączenie z przywróconym wdrożeniem.

Bazy danych do tworzenia kopii zapasowej

Poniższa lista zawiera dodatkowe szczegóły dotyczące kopii zapasowej, w zależności od zasobów wdrożenia.

Ważne

Wszystkie bazy danych na poniższej liście są SQL Server bazami danych. Chociaż można użyć SQL Server Management Studio do tworzenia kopii zapasowych poszczególnych baz danych w dowolnym momencie, należy unikać używania takich indywidualnych kopii zapasowych, jeśli to możliwe. W przypadku przywracania z poszczególnych kopii zapasowych mogą wystąpić nieoczekiwane wyniki, ponieważ wszystkie bazy danych używane przez usługę Azure DevOps są powiązane. W przypadku tworzenia kopii zapasowej tylko jednej bazy danych dane w tej bazie danych mogą nie być synchronizowane z danymi w innych bazach danych.

Bazy danych dla Azure DevOps Server — warstwa danych logicznych dla Azure DevOps Server zawiera kilka SQL Server baz danych, w tym bazę danych konfiguracji, bazę danych magazynu i bazę danych dla każdej kolekcji projektów we wdrożeniu. Te bazy danych mogą znajdować się na tym samym serwerze, dystrybuowane między kilka wystąpień w tym samym SQL Server wdrożeniu lub dystrybuowane na wielu serwerach. Niezależnie od ich rozkładu fizycznego należy utworzyć kopię zapasową wszystkich baz danych w tym samym sygnaturze czasowej, aby zapewnić utratę danych. Kopie zapasowe bazy danych można wykonywać ręcznie lub automatycznie przy użyciu planów konserwacji uruchamianych w określonych godzinach lub odstępach czasu.

Ważne

Lista baz danych usługi Azure DevOps nie jest statyczna. Nowa baza danych jest tworzona za każdym razem, gdy tworzysz kolekcję. Podczas tworzenia kolekcji upewnij się, że do planu konserwacji zostanie dodana baza danych dla tej kolekcji.
Bazy danych usług Reporting Services i Analysis Services — jeśli wdrożenie używa SQL Server Reporting Services lub SQL Server Analysis Services do generowania raportów dla Azure DevOps Server, należy utworzyć kopię zapasową baz danych raportowania i analizy. Jednak po przywróceniu należy ponownie wygenerować niektóre bazy danych, takie jak magazyn.
Klucz szyfrowania dla serwera raportów — serwer raportów ma klucz szyfrowania, który należy utworzyć kopię zapasową. Ten klucz chroni poufne informacje przechowywane w bazie danych serwera raportów. Możesz ręcznie utworzyć kopię zapasową tego klucza przy użyciu narzędzia do konfiguracji usług Reporting Services lub narzędzia wiersza polecenia.

Zaawansowane przygotowywanie kopii zapasowych

Podczas wdrażania usługi Azure DevOps należy zachować rekord kont tworzonych i wszelkich nazw komputerów, haseł i opcji konfiguracji, które zostały określone. Należy również przechowywać kopię wszystkich materiałów odzyskiwania, dokumentów oraz kopii zapasowych dziennika transakcji i bazy danych w bezpiecznej lokalizacji. Aby zapewnić ochronę przed awarią, taką jak pożar lub trzęsienie ziemi, należy zachować duplikaty kopii zapasowych serwera w innej lokalizacji niż lokalizacja serwerów. Ta strategia pomoże Chronić Cię przed utratą krytycznych danych. Najlepszym rozwiązaniem jest przechowywanie trzech kopii nośnika kopii zapasowych i przechowywanie co najmniej jednej kopii poza siedzibą w kontrolowanym środowisku.

Ważne

Okresowo przeprowadzaj przywracanie danych w wersji próbnej, aby sprawdzić, czy pliki są prawidłowo tworzone. Przywracanie wersji próbnej może ujawnić problemy sprzętowe, które nie są wyświetlane z weryfikacją tylko oprogramowania.

Podczas tworzenia kopii zapasowej i przywracania bazy danych należy utworzyć kopię zapasową danych na nośniku z adresem sieciowym (na przykład taśmami i dyskami, które zostały udostępnione jako dyski sieciowe). Plan tworzenia kopii zapasowych powinien zawierać aprowizacje dotyczące zarządzania nośnikami, takie jak następująca taktyka:

Plan śledzenia i zarządzania do przechowywania i recyklingu zestawów kopii zapasowych.
Harmonogram zastępowania nośnika kopii zapasowej.
W środowisku wieloserwerowym decyzja o użyciu scentralizowanych lub rozproszonych kopii zapasowych.
Sposób śledzenia użytecznego życia mediów.
Procedura minimalizująca skutki utraty zestawu kopii zapasowych lub nośnika kopii zapasowej (na przykład taśmy).
Decyzja o przechowywaniu zestawów kopii zapasowych w lokacji lub poza siedzibą firmy oraz analiza sposobu, w jaki ta decyzja może mieć wpływ na czas odzyskiwania.

Ponieważ dane usługi Azure DevOps są przechowywane w SQL Server bazach danych, nie trzeba tworzyć kopii zapasowych komputerów, na których są instalowani klienci usługi Azure DevOps. Jeśli wystąpi awaria nośnika lub awaria, która dotyczyła tych komputerów, możesz ponownie zainstalować oprogramowanie klienckie i ponownie nawiązać połączenie z serwerem. Po ponownym zainstalowaniu oprogramowania klienckiego użytkownicy będą mieli czystszą i bardziej niezawodną alternatywę do przywrócenia komputera klienckiego z kopii zapasowej.

Możesz utworzyć kopię zapasową serwera przy użyciu dostępnych funkcji Zaplanowane kopie zapasowe lub ręcznie utworzyć plany konserwacji w SQL Server, aby utworzyć kopię zapasową baz danych związanych z wdrożeniem usługi Azure DevOps. Bazy danych usługi Azure DevOps działają w relacji ze sobą, a jeśli utworzysz plan ręczny, należy utworzyć ich kopię zapasową i przywrócić w tym samym czasie. Aby uzyskać więcej informacji na temat strategii tworzenia kopii zapasowych baz danych, zobacz Tworzenie kopii zapasowych i przywracanie baz danych SQL Server.

Typy kopii zapasowych

Zrozumienie dostępnych typów kopii zapasowych ułatwia określenie najlepszych opcji tworzenia kopii zapasowych wdrożenia. Jeśli na przykład pracujesz z dużym wdrożeniem i chcesz chronić przed utratą danych przy użyciu ograniczonych zasobów magazynu, możesz skonfigurować różnicowe kopie zapasowe, a także pełne kopie zapasowe danych. Jeśli używasz SQL Server Always On, możesz utworzyć kopie zapasowe pomocniczej bazy danych. Możesz również spróbować użyć kompresji kopii zapasowej lub dzielenia kopii zapasowych między wiele plików. Poniżej przedstawiono krótkie opisy opcji tworzenia kopii zapasowej:

Pełne kopie zapasowe danych (bazy danych)

Pełna kopia zapasowa bazy danych jest niezbędna do odzyskania wdrożenia. Pełna kopia zapasowa obejmuje część dziennika transakcji, dzięki czemu można odzyskać pełną kopię zapasową. Pełne kopie zapasowe są samodzielne, ponieważ reprezentują całą bazę danych, ponieważ istniały podczas tworzenia kopii zapasowej. Aby uzyskać więcej informacji, zobacz Pełne kopie zapasowe bazy danych.

Różnicowe kopie zapasowe danych (bazy danych)

Różnicowa kopia zapasowa bazy danych rejestruje tylko dane, które uległy zmianie od czasu ostatniej pełnej kopii zapasowej bazy danych, która jest nazywana różnicową bazą. Różnicowe kopie zapasowe baz danych są mniejsze i szybsze niż pełne kopie zapasowe bazy danych. Ta opcja pozwala zaoszczędzić czas tworzenia kopii zapasowej kosztem zwiększonej złożoności. W przypadku dużych baz danych różnicowe kopie zapasowe mogą występować w krótszych odstępach czasu niż kopie zapasowe bazy danych, co zmniejsza narażenie na utratę pracy. Aby uzyskać więcej informacji, zobacz Różnicowe kopie zapasowe bazy danych.

Należy również regularnie tworzyć kopie zapasowe dzienników transakcji. Te kopie zapasowe są niezbędne do odzyskiwania danych w przypadku korzystania z pełnego modelu tworzenia kopii zapasowej bazy danych. Jeśli tworzysz kopię zapasową dzienników transakcji, możesz odzyskać bazę danych do punktu awarii lub do wcześniejszego punktu w czasie.

Kopie zapasowe dziennika transakcji

Dziennik transakcji jest rekordem seryjnym wszystkich modyfikacji, które wystąpiły w bazie danych oprócz transakcji, która wykonała każdą modyfikację. Dziennik transakcji rejestruje początek każdej transakcji, zmiany w danych i, w razie potrzeby, wystarczające informacje, aby cofnąć modyfikacje wprowadzone podczas tej transakcji. Dziennik stale rośnie w miarę występowania zarejestrowanych operacji w bazie danych.

Tworząc kopię zapasową dzienników transakcji, można odzyskać bazę danych do wcześniejszego punktu w czasie. Na przykład można przywrócić bazę danych do punktu przed wprowadzoną niepożądanymi danymi lub awarią. Oprócz kopii zapasowych bazy danych kopie zapasowe dziennika transakcji muszą być częścią strategii odzyskiwania. Aby uzyskać więcej informacji, zobacz Kopie zapasowe dziennika transakcji (SQL Server).

Kopie zapasowe dziennika transakcji zwykle używają mniejszej liczby zasobów niż pełne kopie zapasowe. W związku z tym można tworzyć kopie zapasowe dziennika transakcji częściej niż pełne kopie zapasowe, co zmniejsza ryzyko utraty danych. Jednak czasami kopia zapasowa dziennika transakcji jest większa niż pełna kopia zapasowa. Na przykład baza danych o wysokiej szybkości transakcji powoduje, że dziennik transakcji szybko rośnie. W takiej sytuacji należy częściej tworzyć kopie zapasowe dziennika transakcji. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z pełnym dziennikiem transakcji (błąd SQL Server 9002).

Można wykonywać następujące typy kopii zapasowych dziennika transakcji:

Czysta kopia zapasowa dziennika zawiera tylko rekordy dziennika transakcji dla interwału bez żadnych zmian zbiorczych.
Kopia zapasowa dziennika zbiorczego zawiera strony dziennika i danych, które zostały zmienione przez operacje zbiorcze. Odzyskiwanie do punktu w czasie nie jest dozwolone.
Kopia zapasowa dziennika końcowego jest pobierana z prawdopodobnie uszkodzonej bazy danych w celu przechwycenia rekordów dziennika, których kopia zapasowa nie została jeszcze utworzona. Kopia zapasowa dziennika końcowego jest wykonywana po niepowodzeniu zapobiegania utracie pracy i może zawierać czyste dane dziennika lub dziennika zbiorczego.

Ponieważ synchronizacja danych ma kluczowe znaczenie dla pomyślnego przywrócenia Azure DevOps Server, należy użyć oznaczonych transakcji w ramach strategii tworzenia kopii zapasowych, jeśli konfigurujesz kopie zapasowe ręcznie. Aby uzyskać więcej informacji, zobacz Tworzenie harmonogramu i planowania kopii zapasowych oraz Ręczne tworzenie kopii zapasowej Azure DevOps Server.

Kopie zapasowe usługi warstwy aplikacji

Jedyną kopią zapasową wymaganą dla warstwy aplikacji logicznej jest klucz szyfrowania dla usług Reporting Services. Jeśli używasz funkcji Zaplanowane kopie zapasowe w celu utworzenia kopii zapasowej wdrożenia, ten klucz będzie kopii zapasowej dla Ciebie w ramach planu. Można założyć, że należy utworzyć kopię zapasową witryn internetowych używanych jako portale projektów.

Chociaż można łatwiej utworzyć kopię zapasową warstwy aplikacji niż warstwa danych, nadal istnieje kilka kroków przywracania warstwy aplikacji. Musisz zainstalować inną warstwę aplikacji dla Azure DevOps Server, przekierować kolekcje projektów do korzystania z nowej warstwy aplikacji i przekierować witryny portalu dla projektów.

Domyślne nazwy baz danych

Jeśli nie dostosujesz nazw baz danych, możesz użyć poniższej tabeli, aby zidentyfikować bazy danych używane we wdrożeniu Azure DevOps Server. Jak wspomniano wcześniej, nie wszystkie wdrożenia mają wszystkie te bazy danych. Jeśli na przykład nie skonfigurowaliśmy Azure DevOps Server za pomocą usług Reporting Services, nie będziesz mieć baz danych ReportServer ani ReportServerTempDB. Podobnie nie będziesz mieć bazy danych dla programu System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, chyba że skonfigurujesz Azure DevOps Server do obsługi zarządzania laboratorium. Ponadto bazy danych używane Azure DevOps Server mogą być dystrybuowane między więcej niż jedno wystąpienie SQL Server lub na więcej niż jednym serwerze.