Bazy danych, topologie wdrażania i tworzenie kopii zapasowych
Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019
Możesz pomóc chronić wdrożenie przed utratą danych, tworząc regularny harmonogram tworzenia kopii zapasowych baz danych, od których zależy serwer Azure DevOps Server. Aby całkowicie przywrócić wdrożenie usługi Azure DevOps Server, najpierw wykonaj kopię zapasową wszystkich baz danych usługi Azure DevOps Server.
Jeśli wdrożenie obejmuje usługi 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 i planu tworzenia kopii zapasowych.
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 przedstawiono bazy danych do utworzenia kopii zapasowej oraz przedstawiono przykłady fizycznego dystrybuowania tych baz danych we wdrożeniu.
| Typ bazy danych | Rezultat | 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 |
| Bazy danych raportowania | SQL Server Reporting Services | Nie. |
| Bazy danych analizy | SQL Server Analysis Services | Nie. |
Topologie wdrażania
Na podstawie konfiguracji wdrożenia wszystkie bazy danych wymagające utworzenia kopii zapasowej mogą znajdować się na tym samym serwerze fizycznym, co w tej przykładowej topologii.
Uwaga
Ten przykład nie obejmuje usług Reporting Services ani produktów programu SharePoint, dlatego nie trzeba tworzyć kopii zapasowych baz danych skojarzonych z raportami, analizami ani produktami programu SharePoint.
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 programu SQL Server
baza danych kolekcji znajdująca się na serwerze autonomicznym z uruchomionym programem 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
administracyjne bazy danych produktów programu SharePoint i bazy danych zbioru witryn dla obu aplikacji internetowych programu SharePoint
Jeśli bazy danych programu SharePoint są skalowane na wielu serwerach, nie można użyć funkcji Zaplanowane kopie zapasowe, aby utworzyć ich kopię zapasową. 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 usługi Azure DevOps Server. Aby uzyskać więcej informacji, zobacz Ręczne tworzenie kopii zapasowych serwera Azure DevOps Server.
W obu tych przykładach nie trzeba tworzyć kopii zapasowych żadnych klientów łączących się z serwerem. Może jednak być konieczne ręczne wyczyszczenie pamięci podręcznych dla usługi Azure DevOps Server na komputerach klienckich, zanim będą mogły ponownie nawiązać połączenie z przywróconym wdrożeniem.
Bazy danych do utworzenia kopii zapasowej
Poniższa lista zawiera dodatkowe szczegóły dotyczące elementów potrzebnych do utworzenia kopii zapasowej w zależności od zasobów wdrożenia.
Ważne
Wszystkie bazy danych na poniższej liście to bazy danych programu SQL Server. Chociaż program SQL Server Management Studio umożliwia tworzenie kopii zapasowych poszczególnych baz danych w dowolnym momencie, należy unikać używania takich pojedynczych 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. Jeśli tworzysz kopię zapasową tylko jednej bazy danych, dane w tej bazie danych mogą nie być synchronizowane z danymi w innych bazach danych.
- Bazy danych dla usługi Azure DevOps Server — warstwa danych logicznych dla usługi Azure DevOps Server zawiera kilka baz danych programu SQL Server, w tym bazę danych konfiguracji, bazę danych magazynu i bazę danych dla każdej kolekcji projektów we wdrożeniu. Wszystkie te bazy danych mogą znajdować się na tym samym serwerze, dystrybuowane między kilka wystąpień w tym samym wdrożeniu programu SQL Server 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ć ochronę przed 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 jest dodana baza danych dla tej kolekcji.
- Bazy danych usług Reporting Services i Analysis Services — jeśli wdrożenie używa usług SQL Server Reporting Services lub SQL Server Analysis Services do generowania raportów dla usługi 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 serwera raportów — serwer raportów ma klucz szyfrowania, którego kopię zapasową należy utworzyć. 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 konfiguracji usług Reporting Services lub narzędzia wiersza polecenia.
Zaawansowane przygotowanie do tworzenia kopii zapasowych
Podczas wdrażania usługi Azure DevOps należy przechowywać rejestr kont tworzonych i wszystkich nazw komputerów, haseł i opcji konfiguracji. 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. Należy zachować co najmniej jedną kopię poza siedzibą w kontrolowanym środowisku.
Ważne
Okresowo przeprowadzaj przywracanie danych w wersji próbnej, aby sprawdzić, czy pliki są poprawnie tworzone. Przywracanie wersji próbnej może ujawnić problemy sprzętowe, które nie występują w przypadku weryfikacji tylko oprogramowania.
Podczas tworzenia kopii zapasowej i przywracania bazy danych należy utworzyć kopię zapasową danych na nośniku przy użyciu adresu sieciowego (na przykład taśm i dysków, 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 z wieloma serwerami decyzja o użyciu scentralizowanych lub rozproszonych kopii zapasowych.
- Sposób śledzenia użytecznego życia mediów.
- Procedura minimalizowania skutków 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 bazach danych programu SQL Server, 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ę dla 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 programie SQL Server, aby utworzyć kopię zapasową baz danych powiązanych z wdrożeniem usługi Azure DevOps. Bazy danych usługi Azure DevOps działają w relacji ze sobą, a jeśli tworzysz 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 programu 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, efektywnie korzystając z ograniczonych zasobów magazynu, możesz skonfigurować różnicowe kopie zapasowe, a także pełne kopie zapasowe danych. Jeśli używasz zawsze włączonego programu SQL Server, 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 zawiera część dziennika transakcji, dzięki czemu można odzyskać pełną kopię zapasową. Pełne kopie zapasowe są samodzielnie zawarte, ponieważ reprezentują całą bazę danych, ponieważ istniała 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 ostatniej pełnej kopii zapasowej bazy danych, która jest nazywana bazą różnicową. 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 zapasowych 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 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 Tworzenie kopii zapasowych 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 wysokim tempie 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 programu 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.
- Zbiorcza kopia zapasowa dziennika 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 serwera 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 serwera 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 projektu.
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 usługi Azure DevOps Server, przekierować kolekcje projektów w celu użycia nowej warstwy aplikacji i przekierować witryny portalu dla projektów.
Domyślne nazwy baz danych
Jeśli nazwy baz danych nie zostaną dostosowane, możesz użyć poniższej tabeli, aby zidentyfikować bazy danych używane we wdrożeniu usługi Azure DevOps Server. Jak wspomniano wcześniej, nie wszystkie wdrożenia mają wszystkie te bazy danych. Jeśli na przykład nie skonfigurowaliśmy serwera 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 programu System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, chyba że skonfigurujesz serwer Azure DevOps Server do obsługi zarządzania laboratorium. Ponadto bazy danych używane przez usługę Azure DevOps Server mogą być dystrybuowane w więcej niż jednym wystąpieniu programu SQL Server lub na więcej niż jednym serwerze.
Uwaga
Domyślnie prefiks TFS_ jest dodawany do nazw wszystkich baz danych, które są tworzone automatycznie podczas instalowania serwera Azure DevOps Server lub gdy działa.
| baza danych | opis |
|---|---|
| TFS_Configuration | Baza danych konfiguracji dla usługi Azure DevOps Server zawiera wykaz, nazwy serwerów i dane konfiguracji wdrożenia. Nazwa tej bazy danych może zawierać dodatkowe znaki między TFS_ a konfiguracją, takie jak nazwa użytkownika osoby, która zainstalowała serwer Usługi Azure DevOps. Na przykład nazwa bazy danych może być TFS_UserNameConfiguration |
| TFS_Warehouse | Baza danych magazynu zawiera dane do kompilowania magazynu używanego przez usługi Reporting Services. Nazwa tej bazy danych może zawierać dodatkowe znaki między TFS_ a magazynem, takie jak nazwa użytkownika osoby, która zainstalowała serwer Usługi Azure DevOps. Na przykład nazwa bazy danych może być TFS_UserNameWarehouse. |
| TFS_CollectionName | Baza danych kolekcji projektów zawiera wszystkie dane dla projektów w tej kolekcji. Te dane obejmują kod źródłowy, konfiguracje kompilacji i konfiguracje zarządzania laboratorium. Liczba baz danych kolekcji będzie równa liczbie kolekcji. Jeśli na przykład masz trzy kolekcje we wdrożeniu, musisz utworzyć kopię zapasową tych trzech baz danych kolekcji. Nazwa każdej bazy danych może zawierać dodatkowe znaki między TFS_ i CollectionName, takie jak nazwa użytkownika osoby, która utworzyła kolekcję. Na przykład nazwa bazy danych kolekcji może być TFS_UserNameCollectionName. |
| TFS_Analysis | Baza danych dla usług SQL Server Analysis Services zawiera źródła danych i moduły dla wdrożenia usługi Azure DevOps Server. Nazwa tej bazy danych może zawierać dodatkowe znaki między TFS_ i Analysis, takie jak nazwa użytkownika osoby, która zainstalowała usługi Analysis Services. Na przykład nazwa bazy danych może być TFS_UserNameAnalysis. Uwaga: możesz utworzyć kopię zapasową tej bazy danych, ale należy ponownie skompilować magazyn z przywróconej bazy danych TFS_Warehouse. |
| ReportServer | Baza danych usług Reporting Services zawiera ustawienia raportów i raportów dla wdrożenia serwera Azure DevOps Server. Uwaga: jeśli usługi Reporting Services są zainstalowane na innym serwerze niż azure DevOps Server, ta baza danych może nie być obecna na serwerze warstwy danych dla usługi Azure DevOps Server. W takim przypadku należy skonfigurować, utworzyć kopię zapasową i przywrócić ją oddzielnie od serwera Azure DevOps Server. Należy zsynchronizować konserwację baz danych, aby uniknąć błędów synchronizacji. |
| ReportServerTempDB | Tymczasowa baza danych usług Reporting Services tymczasowo przechowuje informacje podczas uruchamiania określonych raportów. Uwaga: jeśli usługi Reporting Services są zainstalowane na oddzielnym serwerze niż serwer Usługi Azure DevOps, ta baza danych może nie być obecna na serwerze warstwy danych dla usługi Azure DevOps Server. W takim przypadku należy skonfigurować, utworzyć kopię zapasową i przywrócić ją oddzielnie od serwera Azure DevOps Server. Należy jednak zsynchronizować konserwację baz danych, aby uniknąć błędów synchronizacji. |
| VirtualManagerDB | Baza danych administracji programu SCVMM zawiera informacje wyświetlane w konsoli administratora programu SCVMM, takie jak maszyny wirtualne, hosty maszyn wirtualnych, serwery biblioteki maszyn wirtualnych i ich właściwości. Uwaga: jeśli program SCVMM jest zainstalowany na osobnym serwerze niż serwer Usługi Azure DevOps, ta baza danych może nie być obecna na serwerze warstwy danych dla serwera Usługi Azure DevOps. W takim przypadku należy skonfigurować, utworzyć kopię zapasową i przywrócić ją oddzielnie od serwera Azure DevOps Server. Należy jednak użyć oznaczonych transakcji i zsynchronizować konserwację baz danych, aby uniknąć błędów synchronizacji. |