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

Artigo
03/25/2024

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

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

Se sua implantação incluir 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 com o mesmo carimbo de data/hora. A maneira mais fácil de garantir a sincronização bem-sucedida é usando transações marcadas. Ao marcar transações relacionadas rotineiramente em cada banco de dados, você estabelece uma série de pontos de recuperação comuns nos bancos de dados. Para obter diretrizes passo a passo para fazer backup de uma implantação de servidor único que usa relatórios, consulte Criar um agendamento 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 acompanham mostram quais bancos de dados fazer backup e fornecem exemplos de como esses bancos de dados podem ser distribuídos fisicamente em uma implantação.

Tipo de Banco de Dados	Produto	Componente necessário?
Banco de dados de configuração	Azure DevOps Server	Sim
Banco de dados do warehouse	Azure DevOps Server	Sim
Bancos de dados de coleção de projetos	Azure DevOps Server	Sim
Bancos de dados de relatório	SQL Server Reporting Services	No
Bancos de dados de análise	SQL Server Analysis Services	Não

Topologias de implantação

Com base na 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 Reporting Services ou Produtos do SharePoint, portanto, você não precisa fazer backup de bancos de dados associados a relatórios, análises ou produtos do SharePoint.

Estrutura de banco de dados Azure DevOps Server simples

Como alternativa, os bancos de dados podem ser distribuídos entre 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
o banco de dados warehouse
os bancos de dados de coleção de projetos localizados no cluster SQL Server
o banco de dados de coleção localizado no servidor autônomo que está executando SQL Server
os bancos de dados localizados no servidor que está executando Reporting Services
o banco de dados localizado no servidor que está executando o Analysis Services
os bancos de dados administrativos de Produtos do SharePoint e os bancos de dados do conjunto de sites para ambos os aplicativos 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 backups para esses bancos de dados e garantir que esses backups sejam sincronizados com os backups de banco de dados Azure DevOps Server. Para obter mais informações, confira Backup manual do Azure DevOps Services.

Estrutura complexa do banco de dados Azure DevOps Server

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

Bancos de dados para fazer backup

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

Importante

Todos os bancos de dados na lista a seguir são SQL Server bancos de dados. Embora você possa usar SQL Server Management Studio para fazer backup de bancos de dados individuais a qualquer momento, evite usar esses backups individuais quando possível. Você poderá ter resultados inesperados se restaurar 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 poderão não ser sincronizados com os dados nos outros bancos de dados.

Bancos de dados para Azure DevOps Server – a camada de dados lógica para Azure DevOps Server inclui vários bancos de dados SQL Server, incluindo o banco de dados de configuração, o banco de dados warehouse 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 entre várias instâncias no mesmo SQL Server implantação ou distribuídos entre vários servidores. Independentemente da distribuição física, você deve fazer backup de todos os bancos de dados no mesmo carimbo de data/hora para ajudar a garantir a perda de dados. Você pode executar backups de banco de dados manual ou automaticamente usando planos de manutenção que são executados em intervalos ou horários específicos.

Importante

A lista de bancos de dados do Azure DevOps não é estática. Um novo banco de dados é criado sempre 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 a implantação usar SQL Server Reporting Services ou SQL Server Analysis Services para gerar relatórios para Azure DevOps Server, você deve fazer backup dos bancos de dados de relatório e análise. No entanto, você ainda deve regenerar determinados bancos de dados após a restauração, como o warehouse.
Chave de criptografia para o servidor de relatório – o servidor de relatório tem uma chave de criptografia que 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 de 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 quaisquer nomes de computador, senhas e opções de configuração que você especificar. Você também deve manter uma cópia de todos os materiais de recuperação, documentos e backups de log de transações e banco de dados em um local seguro. Para proteger contra um desastre, como um incêndio ou um terremoto, você deve manter duplicatas de seus backups de 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 manter pelo menos uma cópia fora do local em um ambiente controlado.

Importante

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

Ao fazer backup e restaurar um banco de dados, você deve fazer backup dos dados na 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 provisionamentos para gerenciar mídia, como as seguintes táticas:

Um plano de gerenciamento e rastreamento para armazenar e reciclar conjuntos de backups.
Uma agenda para substituir a mídia de backup.
Em um ambiente de vários servidores, uma decisão de usar backups centralizados ou distribuídos.
Uma maneira de acompanhar a vida útil da mídia.
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 SQL Server, você não precisa fazer backup dos computadores nos quais os clientes do Azure DevOps estão instalados. Se ocorrer uma falha de mídia ou desastre que envolvesse esses computadores, você poderá reinstalar o software cliente e reconectar-se ao servidor. Ao reinstalar o software cliente, os usuários terão uma alternativa mais limpa e confiável para restaurar um computador cliente 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 à implantação do Azure DevOps. Os bancos de dados do Azure DevOps funcionam em relação um ao outro e, se você criar um plano manual, faça backup deles e restaure-os 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 SQL Server.

Tipos de backups

Entender 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 proteger contra perda de dados usando com eficiência recursos de armazenamento limitados, poderá configurar backups diferenciais, bem como backups de dados completos. Se você estiver usando SQL Server Always On, poderá fazer backups do 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 de suas opções de backup:

Backups de dados completos (bancos de dados)

Um backup de banco de dados completo é necessário para a capacidade de recuperação da 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 como ele existia quando você o fez backup. Para obter mais informações, consulte Backups de banco de dados completos.

Backups de dados diferenciais (bancos 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. Backups de banco de dados de diferencial são menores e mais rápidos do que backups de banco de dados completos. Essa opção economiza tempo de backup ao custo do aumento da complexidade. Para bancos de dados grandes, 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 Backups de banco de dados diferenciais.

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 para o ponto de falha ou para um ponto anterior no tempo.

Backups do 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 realizou 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 de logs de transações, você pode recuperar o banco de dados para um ponto anterior no tempo. Por exemplo, você pode restaurar o banco de dados para um ponto antes de dados indesejados serem inseridos ou que ocorreu uma falha. Além dos backups de banco de dados, os backups de log de transações devem fazer parte da estratégia de recuperação. Para obter mais informações, confira Backups de log de transações (SQL Server).

Os backups de log de transações geralmente usam menos recursos do que 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 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 (SQL Server Erro 9002).

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 para 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 pontual não é permitida.
Um backup de log final é obtido de um banco de dados possivelmente danificado para capturar os registros de log que ainda não foram copiados. Um backup de log final é feito após uma falha para evitar a perda de trabalho e pode conter dados de log puro ou de log em massa.

Como a sincronização de dados é essencial para a restauração bem-sucedida do Azure DevOps Server, 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 um agendamento e um plano de backup e Fazer backup manualmente Azure DevOps Server.

Backups de serviço da camada de aplicativo

O único backup necessário para a camada de aplicativo lógico é para a chave de criptografia para Reporting Services. Se você usar o recurso Backups Agendados para fazer backup da implantação, essa chave terá backup para você 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 com mais facilidade 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 Azure DevOps Server, redirecionar coleções de projetos para usar a nova camada de aplicativo e redirecionar os sites do portal para projetos.

Nomes de banco de dados padrão

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