Базы данных, топологии развертывания и резервное копирование

Статья
03/25/2024

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

Вы можете защитить развертывание от потери данных, создав регулярное расписание резервного копирования для баз данных, от Azure DevOps Server зависит. Чтобы полностью восстановить развертывание Azure DevOps Server, сначала создайте резервную копию всех Azure DevOps Server баз данных.

Если развертывание включает SQL Server Reporting Services, необходимо также создать резервную копию баз данных, которые Azure DevOps использует в этих компонентах. Для предотвращения ошибок синхронизации или несоответствия данных необходимо синхронизировать все резервные копии, чтобы они имели одну и ту же отметку времени. Самый простой способ обеспечить синхронизацию — это использовать помеченные транзакции. Регулярно помечая связанные транзакции в каждой базе данных, вы создаете ряд общих точек восстановления в базах данных. Пошаговые инструкции по резервному копированию развертывания с одним сервером, использующего отчеты, см. в статье Создание расписания и плана резервного копирования.

Резервное копирование баз данных

Защитите развертывание Azure DevOps от потери данных путем создания резервных копий базы данных. В следующей таблице и сопроводительных иллюстрациях показаны базы данных для резервного копирования, а также приведены примеры физического распределения этих баз данных в развертывании.

Тип базы данных	Продукт	Требуется компонент?
База данных конфигурации	Azure DevOps Server	Да
База данных хранилища	Azure DevOps Server	Да
Базы данных коллекции проектов	Azure DevOps Server	Да
Базы данных отчетов	службы SQL Server Reporting Services	Нет
Базы данных аналитики	службы SQL Server Analysis Services	Нет

Технологии развертывания

В зависимости от конфигурации развертывания все базы данных, для которых необходимо резервное копирование, могут располагаться на одном и том же физическом сервере, как в данном примере топологии.

Примечание

Этот пример не включает Reporting Services или продукты SharePoint, поэтому вам не нужно создавать резервные копии баз данных, связанных с отчетами, анализом или продуктами SharePoint.

Простая структура базы данных Azure DevOps Server

Базы данных также могут быть распределены по нескольким серверам и фермам серверов. В данном примере топологии необходимо создавать резервные копии следующих баз данных, которые расположены на шести серверах или фермах серверов:

базы данных конфигурации;
базы данных хранилища;
базы данных коллекции проектов, расположенные в кластере SQL Server;
база данных коллекции, расположенная на автономном сервере под управлением SQL Server
баз данных, расположенных на сервере, на котором работают службы отчетов;
базы данных, расположенной на сервере, на котором работают службы аналитики.
административные базы данных продуктов SharePoint и базы данных семейства веб-сайтов для обоих веб-приложений SharePoint

Если базы данных SharePoint масштабируются на нескольких серверах, вы не сможете использовать функцию запланированного резервного копирования для их резервного копирования. Необходимо вручную настроить резервные копии для этих баз данных и убедиться, что эти резервные копии синхронизированы с Azure DevOps Server резервными копиями базы данных. Дополнительные сведения см. в статье Резервное копирование Azure DevOps Server вручную.

Сложная структура базы данных Azure DevOps Server

В обоих примерах не нужно создавать резервные копии каких-либо клиентов, подключающихся к серверу. Однако может потребоваться вручную очистить кэши для Azure DevOps Server на клиентских компьютерах, прежде чем они смогут повторно подключиться к восстановленной среде.

Базы данных, подлежащие резервному копированию

В следующем списке приведены дополнительные сведения о том, что необходимо выполнить резервное копирование в зависимости от ресурсов развертывания.

Важно!

Все базы данных в следующем списке являются SQL Server базами данных. Хотя вы можете использовать SQL Server Management Studio для резервного копирования отдельных баз данных в любое время, по возможности не следует использовать такие отдельные резервные копии. При восстановлении из отдельных резервных копий могут возникнуть непредвиденные результаты, так как все базы данных, используемые Azure DevOps, связаны. При резервном копировании только одной базы данных данные в ней могут быть не синхронизированы с данными в других базах данных.

Базы данных для Azure DevOps Server. Логический уровень данных для Azure DevOps Server включает несколько SQL Server баз данных, включая базу данных конфигурации, базу данных хранилища и базу данных для каждой коллекции проектов в развертывании. Все эти базы данных могут находиться на одном сервере, распределяться по нескольким экземплярам в одном SQL Server развертывании или распределяться между несколькими серверами. Независимо от конкретного физического распределения необходимо создавать резервные копии всех баз данных с одной и той же отметкой времени, чтобы предотвратить потерю данных. Резервное копирование баз данных можно выполнять вручную или автоматически с использованием планов обслуживания, запускаемых в указанное время или через указанные интервалы.

Важно!

Список баз данных Azure DevOps не является статическим. При каждом создании коллекции создается новая база данных. При создании коллекции обязательно добавьте базу данных для этой коллекции в план обслуживания.
Базы данных для служб Reporting Services и Analysis Services . Если развертывание использует SQL Server Reporting Services или SQL Server Analysis Services для создания отчетов для Azure DevOps ServerНеобходимо создать резервную копию баз данных отчетов и анализа. Однако после восстановления некоторые базы данных (например, хранилище данных) придется создавать повторно.
Ключ шифрования для сервера отчетов . На сервере отчетов есть ключ шифрования, который необходимо создать. Этот ключ защищает конфиденциальные сведения, хранящиеся в базе данных сервера отчетов. Можно вручную создать резервную копию этого ключа, используя средство конфигурации служб отчетов или программу командной строки.

Расширенная подготовка к резервному копированию

При развертывании Azure DevOps необходимо хранить записи о создаваемых учетных записях, а также о всех указанных вами именах компьютеров, паролях и параметрах настройки. Кроме того, следует сохранять в безопасном расположении копии всех материалов для восстановления и документов, а также резервные копии баз данных и журналов транзакций. Для защиты от аварии, например пожара или землетрясения, следует хранить дубликаты резервных копий серверов в расположении, отличном от расположения серверов. Такая стратегия будет способствовать защите от потери критически важных данных. Рекомендуется хранить три копии резервных носителей, как минимум одна из которых должна храниться за пределами площадки в контролируемой среде.

Важно!

Периодически выполняйте пробное восстановление данных для проверки правильности резервного копирования файлов. Пробное восстановление может выявить проблемы с оборудованием, которые не отображаются при проверке только программного обеспечения.

При резервном копировании и восстановлении базы данных резервные копии данных необходимо создавать на носителях с сетевым адресом (например, лентах и дисках, к которым предоставлен общий доступ как к сетевым дискам). План резервного копирования должен включать решения по управлению носителями, например:

План отслеживания и управления хранением и утилизацией резервных наборов данных.
Расписание перезаписи резервных носителей.
В многосерверной среде — решение о централизованном или распределенном резервном копировании.
Способ отслеживания срока службы носителей.
Процедура для минимизации последствий при утере резервного набора данных или резервных носителей (например, ленты).
Решение о хранении резервных наборов данных на площадке или за ее пределами и анализ потенциального влияния этого решения на сроки восстановления.

Так как данные Azure DevOps хранятся в SQL Server базах данных, вам не нужно создавать резервные копии компьютеров, на которых установлены клиенты Azure DevOps. Если произойдет сбой носителя или авария с этими компьютерами, можно повторно установить клиентское программное обеспечение и повторно подключиться к серверу. После повторной установки клиентского программного обеспечения пользователи получат более чистую и надежную альтернативу восстановлению клиентского компьютера из резервной копии.

Вы можете создать резервную копию сервера с помощью доступных функций запланированного резервного копирования или вручную создать планы обслуживания в SQL Server для резервного копирования баз данных, связанных с развертыванием Azure DevOps. Базы данных Azure DevOps работают друг с другом, и если вы создаете план вручную, их следует создать и восстановить в то же время. Дополнительные сведения о стратегиях резервного копирования баз данных см. в статье Резервное копирование и восстановление баз данных SQL Server.

Типы резервного копирования

Понимание типов доступных резервных копий помогает определить оптимальные варианты резервного копирования развертывания. Например, при работе с большим развертыванием, чтобы защититься от потери данных и одновременно эффективно использовать ограниченные ресурсы хранилища, можно настроить создание разностных резервных копий, а также полных резервных копий. Если вы используете SQL Server Always On, вы можете создавать резервные копии базы данных-получателя. Можно также попробовать использовать сжатие резервных копий или разбиение резервных копий на несколько файлов. Ниже приведено краткое описание возможных вариантов резервного копирования:

Полные резервные копии данных (базы данных)

Для восстановления развертывания требуется полная резервная копия базы данных. В полную резервную копию входит часть журнала транзакций, что позволяет восстановить полную резервную копию. Полные резервные копии являются самодостаточными в том смысле, что они представляют полную базу данных, существующую на момент создания ее резервной копии. Дополнительные сведения см. в разделе Полное резервное копирование базы данных.

Разностные резервные копии данных (базы данных)

Разностная резервная копия базы данных записывает только те данные, которые были изменены с момента последней полной резервной копии базы данных, которая называется разностной базой. Разностное резервное копирование баз данных компактнее и быстрее по сравнению с полным резервным копированием. Его использование позволяет сократить время резервного копирования за счет повышенной сложности. Для больших баз данных разностное резервное копирование может выполняться с меньшими интервалами, чем в случае полного резервного копирования, что сокращает вероятность потери рабочих данных. Дополнительные сведения см. в разделе Разностные резервные копии базы данных.

Также следует регулярно создавать резервные копии журналов транзакций. Эти резервные копии необходимы для восстановления данных при использовании модели полного резервного копирования баз данных. При резервном копировании журналов транзакций можно восстановить базу данных до точки сбоя или до более ранней точки во времени.

резервное копирование журналов транзакций.

Журнал транзакций — это последовательная запись всех изменений, произошедших в базе данных, а также транзакций, которые выполняли каждое изменение. В журнал транзакций записывается начало каждой транзакции, изменения данных и, при необходимости, достаточные сведения для отмены изменений, внесенных в ходе каждой транзакции. Журнал постоянно увеличивается по мере выполнения регистрируемых операций в базе данных.

Резервные копии журналов транзакций позволяют восстановить базу до предшествующего момента времени. Например, можно восстановить базу данных до точки, до того, как были введены нежелательные данные или произошел сбой. Кроме резервных копий базы данных, резервные копии журнала транзакция также должны быть частью стратегии восстановления. Дополнительные сведения см. в разделе Резервные копии журналов транзакций (SQL Server).

Резервные копии журнала транзакций обычно занимают меньше ресурсов, чем полные резервные копии. Поэтому резервные копии журналов транзакций можно создавать чаще, чем полные резервные копии, что снижает риск потери данных. Однако иногда резервная копия журнала транзакций занимает больше места, чем полная копия. Например, база данных с высокой скоростью транзакций приводит к быстрому росту журнала транзакций. В такой ситуации следует чаще создавать резервные копии журнала транзакций. Дополнительные сведения см. в статье Устранение неполадок с полным журналом транзакций (ошибка SQL Server 9002).

Далее перечислены типы резервных копий журналов транзакций, которые можно создавать:

Чистая резервная копия журнала содержит только записи из журнала транзакций за период времени, без каких-либо массовых изменений.
Резервная копия неполного журнала и массовых изменений содержит журнал и страницы данных, измененные массовыми операциями. Восстановление до заданной точки не допускается.
Резервная копия заключительного фрагмента журнала создается для вероятно поврежденной базы данных для перехвата записей журнала, которые еще не были подвергнуты резервному копированию. Резервная копия заключительного фрагмента журнала создается после сбоя для предотвращения потери рабочих данных и может содержать как данные только из самого журнала, так и данные массовых изменений журнала.

Так как синхронизация данных крайне важна для успешного восстановления Azure DevOps Server, при настройке резервного копирования вручную следует использовать помеченные транзакции в рамках стратегии резервного копирования. Дополнительные сведения см. в разделах Создание расписания и плана резервного копирования и Резервное копирование вручную Azure DevOps Server.

Резервные копии служб уровня приложений

Единственная резервная копия, необходимая для уровня логического приложения, — это ключ шифрования для Reporting Services. При использовании функции "Плановые резервные копии" для резервного копирования развертывания этот ключ будет копироваться в рамках настроенного плана. Вы можете предположить, что необходимо создать резервную копию веб-сайтов, используемых в качестве порталов проектов.

Хотя резервное копирование уровня приложений проще, чем уровня данных, восстановление уровня приложений выполняется несколькими шагами. Необходимо установить другой уровень приложений для Azure DevOps Server, перенаправить коллекции проектов для использования нового уровня приложений и перенаправить сайты портала для проектов.

Имена баз данных, используемые по умолчанию

Если имена баз данных не настраивались, можно использовать следующую таблицу для определения баз данных, используемых в развертывании Azure DevOps Server. Как уже говорилось, не во всех развертываниях имеются все перечисленные базы данных. Например, если вы не настроили Azure DevOps Server с Reporting Services, у вас не будет баз данных ReportServer или ReportServerTempDB. Аналогичным образом у вас не будет базы данных для System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, если вы не настроите Azure DevOps Server для поддержки управления лабораториями. Кроме того, базы данных, используемые Azure DevOps Server, могут быть распределены между несколькими экземплярами SQL Server или несколькими серверами.