Noções básicas sobre garfos de recuperação no SQL Server: significado e importância

Pelas informações que reuni, entendo que esses GUID são uma espécie de DNA do banco de dados e não importa o quão longe na linha de parentesco o banco de dados esteja, ele compartilha informações para identificar a si mesmo e ao primeiro ancestral.

O artigo de Stuart Moore contém algumas informações relacionadas a forks e backups de recuperação:

Você restaura um banco de dados SQL Server e inicia duas coisas novas:

• Um novo garfo de recuperação
• Uma nova cadeia LSN

Todos os bancos de dados estão rodando em um Recovery Fork (identificado por um RecoveryForkGUID), mesmo um novo terá um. Você executa uma restauração e o SQL Server irá gerar um novo Recovery Fork nos bastidores. Assim como os Ghostbusters, o SQL Server não permite cruzar streams

Conforme abordado em outra parte aqui , o SQL Server usa LSNs (Log Sequence Numbers) para rastrear ações de banco de dados e, como os backups são ações de banco de dados, eles também estão vinculados a LSNs. Você levará o banco de dados de volta para um LSN no passado e reiniciará a contagem a partir daí. É por isso que o SQL Server usa o fork de recuperação. Mesmo que você tenha a sorte de ter backups começando no mesmo LSN (e é o tipo de sorte que eu pediria os números da loteria), você ainda não conseguirá usar o backup.

Fiz alguns testes que me trouxeram algum entendimento sobre o assunto. Este laboratório pode ajudar você a entender o uso de garfos de recuperação:

--CREATE THE NEW DATABASE

CREATE DATABASE LabRecoveryFork;
GO

SELECT d.name, dsr.*
FROM sys.database_recovery_status AS dsr
INNER JOIN sys.databases AS d ON dsr.database_id = d.database_id
WHERE d.name = 'LabRecoveryFork';
GO

Ele cria nosso banco de dados LabRecoveryFork e mostra informações sobre database_guid, family_guide recovery_fork_guid. Observe que family_guide recovery_fork_guidsão iguais, significa que esse é o banco de dados original, é o primeiro dessa "linhagem".

O documento sys.database_recovery_status diz algo sobre database_guid:

RESTORE sempre gera um novo GUID quando você restaura um banco de dados que ainda não existe.

--RESTORING A DATABASE THAT ALREADY EXISTS--

BACKUP DATABASE LabRecoveryFork TO DISK = 'C:\Backup\LabRecoveryFork.bak';
GO

RESTORE DATABASE LabRecoveryFork FROM DISK = 'C:\Backup\LabRecoveryFork.bak'
WITH replace;
GO

SELECT d.name, dsr.*
FROM sys.database_recovery_status AS dsr
INNER JOIN sys.databases AS d ON dsr.database_id = d.database_id
WHERE d.name = 'LabRecoveryFork';
GO

Você verá que database_guid, family_guidsão iguais a antes, mas recovery_fork_guidsão diferentes, e agora temos algumas informações novas: last_log_backup_lsn, first_recovery_fork_guide fork_point_lsn.

--RESTORIG A NEW DATABASE

RESTORE DATABASE LabRecoveryFork_2 FROM DISK = 'C:\Backup\LabRecoveryFork.bak'
WITH 
MOVE 'LabRecoveryFork' TO 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\LabRecoveryFork_2.mdf',
MOVE 'LabRecoveryFork_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\LabRecoveryFork_2.ldf';
GO

SELECT d.name, dsr.*
FROM sys.database_recovery_status AS dsr
INNER JOIN sys.databases AS d ON dsr.database_id = d.database_id
WHERE d.name LIKE 'LabRecoveryFork%';
GO

Agora temos um diferente database_guidjá que o banco de dados restaurado não existia antes (como dizia a documentação), mas family_guidainda é o mesmo, pois indica de qual banco de dados este foi originado. Além disso, last_log_backup_lsn, first_recovery_fork_guide fork_point_lsnsão os mesmos de antes, pois esse banco de dados foi originado do mesmo backup. Novamente, temos um arquivo diferente recovery_fork_guid.

Finalmente, criamos o terceiro banco de dados a partir de um backup do segundo, em vez do backup original:

--RESTORIG A THIRD DATABASE FROM THE BACKUP OF THE SECOND DATABASE IN LINE

BACKUP DATABASE LabRecoveryFork_2 TO DISK = 'C:\Backup\LabRecoveryFork_2.bak';
GO

RESTORE DATABASE LabRecoveryFork_3 FROM DISK = 'C:\Backup\LabRecoveryFork_2.bak'
WITH 
MOVE 'LabRecoveryFork' TO 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\LabRecoveryFork_3.mdf',
MOVE 'LabRecoveryFork_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\LabRecoveryFork_3.ldf';
GO

SELECT d.name, dsr.*
FROM sys.database_recovery_status AS dsr
INNER JOIN sys.databases AS d ON dsr.database_id = d.database_id
WHERE d.name LIKE 'LabRecoveryFork%';
GO

Neste último caso todas as informações foram alteradas, exceto family_guid. Aqui está o resultado que obtive desta etapa final:

Com essas informações, você pode emitir um RESTORE HEADERONLYpara descobrir como um backup se relaciona com o banco de dados:

RESTORE HEADERONLY FROM DISK = 'C:\Backup\LabRecoveryFork_2.bak';

Você pode comparar informações relacionadas a recovery_fork e LSN para verificar com qual bifurcação esse backup está relacionado (e pode ser usado).

Este artigo responde de alguma forma a algumas de suas perguntas - embora indiretamente: https://stuart-moore.com/please-clean-down-your-sql-server-backup-history/

Se você entender o modelo de Backup e Recuperação para SQL Server, entenderá melhor os forks de recuperação - é basicamente apenas uma maneira do SQL Server garantir que o método/ordem de recuperação seja mantido (por exemplo: que o backup mais recente do log de transações que você está tentando restaurar é consistente para o momento do banco de dados que você está tentando recuperar). Uma bifurcação de recuperação começa no ponto de uma restauração completa ou criação de um banco de dados e alguns outros cenários relacionados ao cluster (acredito que quando você faz um failover completo em um cluster, o SQL Server iniciará uma nova bifurcação de recuperação).

Aparentemente, respostas de IA não são permitidas no DBA Stack Exchange - mas encontrei as melhores respostas para suas perguntas no ChatGPT - então, se você tiver acesso, sugiro que use essa ferramenta. Não sou um fã muito entusiasmado de IA - mas ela pode ser valiosa para resumir conhecimentos como suas perguntas - coloquei suas perguntas (conforme apresentadas) no ChatGPT 4o e ele deu respostas melhores e mais compreensíveis do que qualquer outro lugar que eu pudesse encontrar diretamente no a teia.