Bancos de dados, topologias de implantação e backup

Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020

Você pode ajudar a proteger sua implantação contra perda de dados criando uma agenda regular de backups para os bancos de dados dos quais o Servidor de DevOps do Azure depende. Para restaurar completamente a implantação do Servidor de DevOps do Azure, primeiro faça backup de todos os bancos de dados do Servidor de DevOps do Azure.

Se sua implantação incluir o SQL Server Reporting Services, você também deverá fazer backup dos bancos de dados que o Azure DevOps usa nesses componentes. Para evitar erros de sincronização ou erros de incompatibilidade de dados, você deve sincronizar todos os backups para o mesmo carimbo de data/hora. A maneira mais fácil de garantir uma sincronização bem-sucedida é usando transações marcadas. Ao marcar rotineiramente as transações relacionadas em cada banco de dados, você estabelece uma série de pontos de recuperação comuns nos bancos de dados. Para obter orientação passo a passo para fazer backup de uma implantação de servidor único que usa relatórios, consulte Criar uma agenda e um plano de backup.

Fazendo backup de bancos de dados

Proteja sua implantação do Azure DevOps contra perda de dados criando backups de banco de dados. A tabela a seguir e as ilustrações que a acompanham mostram quais bancos de dados devem fazer backup e fornecem exemplos de como esses bancos de dados podem ser fisicamente distribuídos em uma implantação.

Tipo de banco de dados	Produto	Componente necessário?
Banco de dados de configuração	Azure DevOps Server	Yes
Base de dados do armazém	Azure DevOps Server	Yes
Bases de dados de recolha de projetos	Azure DevOps Server	Yes
Bases de dados para relatórios	SQL Server Reporting Services	Não
Bases de dados de análise	SQL Server Analysis Services	Não

Topologias de implantação

Com base em sua configuração de implantação, todos os bancos de dados que exigem backup podem estar no mesmo servidor físico, como neste exemplo de topologia.

Observação

Este exemplo não inclui o Reporting Services ou os Produtos do SharePoint, portanto, não é necessário fazer backup de nenhum banco de dados associado a relatórios, análises ou Produtos do SharePoint.

Estrutura de banco de dados simples do Azure DevOps Server

Como alternativa, os bancos de dados podem ser distribuídos em muitos servidores e farms de servidores. Neste exemplo de topologia, você deve fazer backup dos seguintes bancos de dados, que são dimensionados em seis servidores ou farms de servidores:

O banco de dados de configuração
a base de dados do armazém
os bancos de dados de coleção de projetos localizados no cluster do SQL Server
o banco de dados de coleta localizado no servidor autônomo que está executando o SQL Server
os bancos de dados localizados no servidor que está executando o Reporting Services
o banco de dados localizado no servidor que está executando o Analysis Services
as bases de dados administrativas dos produtos do SharePoint e as bases de dados da coleção de sites para ambas as aplicações web do SharePoint

Se os bancos de dados do SharePoint forem dimensionados em vários servidores, você não poderá usar o recurso Backups Agendados para fazer backup deles. Você deve configurar manualmente os backups para esses bancos de dados e garantir que esses backups sejam sincronizados com os backups de banco de dados do Servidor de DevOps do Azure. Para obter mais informações, consulte Fazer backup manual do Azure DevOps Server.

Estrutura complexa do banco de dados do Azure DevOps Server

Em ambos os exemplos, não é necessário fazer backup de nenhum dos clientes que se conectam ao servidor. No entanto, talvez seja necessário limpar manualmente os caches do Servidor de DevOps do Azure nos computadores clientes antes que eles possam se reconectar à implantação restaurada.

Bancos de dados para backup

A lista a seguir fornece detalhes adicionais sobre o que você deve fazer backup, dependendo de seus recursos de implantação.

Importante

Todos os bancos de dados na lista a seguir são bancos de dados do SQL Server. Embora você possa usar o SQL Server Management Studio para fazer backup de bancos de dados individuais a qualquer momento, evite usar esses backups individuais quando possível. Você pode ter resultados inesperados se restaurar a partir de backups individuais, porque os bancos de dados que o Azure DevOps usa estão todos relacionados. Se você fizer backup de apenas um banco de dados, os dados nesse banco de dados podem não ser sincronizados com os dados nos outros bancos de dados.

Bancos de dados para o Servidor de DevOps do Azure - A camada de dados lógica para o Servidor de DevOps do Azure inclui vários bancos de dados do SQL Server, incluindo o banco de dados de configuração, o banco de dados de depósito e um banco de dados para cada coleção de projetos na implantação. Esses bancos de dados podem estar todos no mesmo servidor, distribuídos em várias instâncias na mesma implantação do SQL Server ou distribuídos em vários servidores. Independentemente da sua distribuição física, deve-se fazer uma cópia de segurança de todos os bancos de dados para a mesma marca temporal para garantir contra a perda de dados. Você pode executar backups de banco de dados manual ou automaticamente usando planos de manutenção executados em horários ou intervalos específicos.

Importante

A lista de bancos de dados do Azure DevOps não é estática. Um novo banco de dados é criado toda vez que você cria uma coleção. Ao criar uma coleção, certifique-se de adicionar o banco de dados dessa coleção ao seu plano de manutenção.
Bancos de dados para Reporting Services e Analysis Services - Se sua implantação usa o SQL Server Reporting Services ou o SQL Server Analysis Services para gerar relatórios para o Azure DevOps Server, você deve fazer backup dos bancos de dados de relatórios e análises. No entanto, você ainda deve regenerar determinados bancos de dados após a restauração, como o depósito.
Chave de criptografia para o servidor de relatório - O servidor de relatório tem uma chave de criptografia da qual você deve fazer backup. Essa chave protege as informações confidenciais armazenadas no banco de dados do servidor de relatório. Você pode fazer backup manualmente dessa chave usando a ferramenta Configuração do Reporting Services ou uma ferramenta de linha de comando.

Preparação avançada para backups

Ao implantar o Azure DevOps, você deve manter um registro das contas criadas e de todos os nomes de computador, senhas e opções de configuração especificados. Você também deve manter uma cópia de todos os materiais de recuperação, documentos e backups de banco de dados e log de transações em um local seguro. Para se proteger contra um desastre, como um incêndio ou um terremoto, você deve manter duplicatas dos backups do servidor em um local diferente do local dos servidores. Essa estratégia ajudará a protegê-lo contra a perda de dados críticos. Como prática recomendada, você deve manter três cópias da mídia de backup e deve manter pelo menos uma cópia externa em um ambiente controlado.

Importante

Execute uma restauração de dados de avaliação periodicamente para verificar se o backup dos seus arquivos está correto. Uma restauração de avaliação pode revelar problemas de hardware que não aparecem com uma verificação apenas de software.

Ao fazer backup e restaurar um banco de dados, você deve fazer backup dos dados em mídia com um endereço de rede (por exemplo, fitas e discos que foram compartilhados como unidades de rede). Seu plano de backup deve incluir provisões para gerenciar mídia, como as seguintes táticas:

Um plano de rastreamento e gerenciamento para armazenar e reciclar conjuntos de backup.
Um cronograma para substituir a mídia de backup.
Em um ambiente multisservidor, uma decisão de usar backups centralizados ou distribuídos.
Uma forma de acompanhar a vida útil dos media.
Um procedimento para minimizar os efeitos da perda de um conjunto de backup ou mídia de backup (por exemplo, uma fita).
Uma decisão de armazenar conjuntos de backup no local ou fora do local e uma análise de como essa decisão pode afetar o tempo de recuperação.

Como os dados do Azure DevOps são armazenados em bancos de dados do SQL Server, não é necessário fazer backup dos computadores nos quais os clientes do Azure DevOps estão instalados. Se ocorrer uma falha de mídia ou um desastre que envolva esses computadores, você poderá reinstalar o software cliente e se reconectar ao servidor. Ao reinstalar o software cliente, seus usuários terão uma alternativa mais limpa e confiável para restaurar um computador cliente a partir de um backup.

Você pode fazer backup de um servidor usando os recursos de Backups Agendados disponíveis ou criando manualmente planos de manutenção no SQL Server para fazer backup dos bancos de dados relacionados à sua implantação do Azure DevOps. Os bancos de dados do Azure DevOps funcionam em relação uns com os outros e, se você criar um plano manual, deverá fazer backup deles e restaurá-los ao mesmo tempo. Para obter mais informações sobre estratégias de backup de bancos de dados, consulte Fazer backup e restaurar bancos de dados do SQL Server.

Tipos de backups

Compreender os tipos de backups disponíveis ajuda a determinar as melhores opções para fazer backup de sua implantação. Por exemplo, se você estiver trabalhando com uma implantação grande e quiser se proteger contra perda de dados enquanto usa eficientemente recursos de armazenamento limitados, poderá configurar backups diferenciais, bem como backups completos de dados. Se você estiver usando o SQL Server Always On, poderá fazer backups do seu banco de dados secundário. Você também pode tentar usar a compactação de backup ou dividir backups em vários arquivos. Aqui estão breves descrições das opções de backup:

Backups completos de dados (bancos de dados)

Um backup completo do banco de dados é necessário para a capacidade de recuperação de sua implantação. Um backup completo inclui parte do log de transações para que você possa recuperar o backup completo. Os backups completos são independentes, pois representam todo o banco de dados tal como ele existia quando você fez o backup. Para obter mais informações, consulte Backups completos de banco de dados.

Backups diferenciais de dados (bases de dados)

Um backup de banco de dados diferencial registra apenas os dados que foram alterados desde o último backup completo do banco de dados, que é chamado de base diferencial. Os backups diferenciais de banco de dados são menores e mais rápidos do que os backups completos de banco de dados. Essa opção economiza tempo de backup ao custo de maior complexidade. Para bancos de dados grandes, os backups diferenciais podem ocorrer em intervalos mais curtos do que os backups de banco de dados, o que reduz a exposição à perda de trabalho. Para obter mais informações, consulte Cópias de segurança diferenciais da base de dados.

Você também deve fazer backup de seus logs de transações regularmente. Esses backups são necessários para recuperar dados quando você usa o modelo de backup de banco de dados completo. Se você fizer backup de logs de transações, poderá recuperar o banco de dados até o ponto de falha ou para um ponto anterior no tempo.

Backups de log de transações

O log de transações é um registro serial de todas as modificações que ocorreram em um banco de dados, além da transação que executou cada modificação. O log de transações registra o início de cada transação, as alterações nos dados e, se necessário, informações suficientes para desfazer as modificações feitas durante essa transação. O log cresce continuamente à medida que as operações registradas ocorrem no banco de dados.

Ao fazer backup dos logs de transações, é possível recuperar o banco de dados para um ponto no tempo anterior. Por exemplo, você pode restaurar o banco de dados até um ponto antes que dados indesejados tenham sido inseridos ou ocorra uma falha. Além dos backups de banco de dados, os backups de log de transações devem fazer parte da sua estratégia de recuperação. Para obter mais informações, consulte Backups de log de transações (SQL Server).

Os backups de log de transações geralmente usam menos recursos do que os backups completos. Portanto, você pode criar backups de log de transações com mais frequência do que backups completos, o que reduz o risco de perda de dados. No entanto, às vezes, um backup de log de transações é maior do que um backup completo. Por exemplo, um banco de dados com uma alta taxa de transações faz com que o log de transações cresça rapidamente. Nessa situação, você deve criar backups de log de transações com mais frequência. Para obter mais informações, consulte Solucionar problemas de um log de transações completo (Erro 9002 do SQL Server).

Você pode executar os seguintes tipos de backups de log de transações:

Um backup de log puro contém apenas registros de log de transações por um intervalo, sem alterações em massa.
Um backup de log em massa contém páginas de log e dados que foram alteradas por operações em massa. A recuperação no tempo específico não é permitida.
Um backup de tail-log é retirado de um banco de dados possivelmente danificado para capturar os registros de log que ainda não foram copiados. Realiza-se um backup de tail-log após ocorrer uma falha para evitar a perda de dados e pode conter dados de log puros ou em massa.

Como a sincronização de dados é crítica para a restauração bem-sucedida do Servidor de DevOps do Azure, você deve usar transações marcadas como parte de sua estratégia de backup se estiver configurando backups manualmente. Para obter mais informações, consulte Criar uma agenda e um plano de backup e Fazer backup manual do Servidor de DevOps do Azure.

Backups de serviços de camada de aplicação

O único backup necessário para a camada de aplicativo lógico é para a chave de criptografia do Reporting Services. Se você usar o recurso Backups agendados para fazer backup de sua implantação, o backup dessa chave será feito como parte do plano. Você pode supor que você deve fazer backup de sites usados como portais de projeto.

Embora você possa fazer backup de uma camada de aplicativo mais facilmente do que uma camada de dados, ainda há várias etapas para restaurar uma camada de aplicativo. Você deve instalar outra camada de aplicativo para o Azure DevOps Server, redirecionar coleções de projetos para usar a nova camada de aplicativo e redirecionar os sites de portal para projetos.

Nomes de banco de dados padrão

Se você não personalizar os nomes de seus bancos de dados, poderá usar a tabela a seguir para identificar os bancos de dados usados em sua implantação do Servidor de DevOps do Azure. Como mencionado anteriormente, nem todas as implantações têm todos esses bancos de dados. Por exemplo, se você não configurou o Servidor de DevOps do Azure com o Reporting Services, não terá os bancos de dados ReportServer ou ReportServerTempDB. Da mesma forma, você não terá o banco de dados para o System Center Virtual Machine Manager (SCVMM), VirtualManagerDB, a menos que configure o Azure DevOps Server para dar suporte ao Lab Management. Além disso, os bancos de dados que o Azure DevOps Server usa podem ser distribuídos em mais de uma instância do SQL Server ou em mais de um servidor.