Backups copy-only e restauração diferencial

Um backup completo adicional é criado para testes. Depois, a restauração diferencial falha porque o plano ainda espera um full anterior. O problema não é que um full quebre a cadeia do log: o full comum adicional mudou a base diferencial.

Seguir uma sequência concreta

Imagine full programado domingo, full comum pontual terça e diferencial quarta. O diferencial depende de terça, não de domingo. Se o arquivo de terça desaparecer de um compartilhamento temporário, domingo mais quarta deixa de ser suficiente.

Com COPY_ONLY na terça, a base continuaria domingo. Um full copy-only restaura como full, mas não vira base de diferenciais posteriores. É útil para cópias pontuais fora da agenda, não para todos os fulls programados: a estratégia diferencial precisa estabelecer bases comuns intencionalmente.

SELECT TOP(50) database_name,type,is_copy_only,
 backup_start_date,backup_finish_date,first_lsn,last_lsn,
 database_backup_lsn,differential_base_lsn
FROM msdb.dbo.backupset
WHERE database_name=N'YourPracticeDatabase'
ORDER BY backup_finish_date DESC;

A consulta mostra tipos, indicador copy-only e metadados LSN. D, I e L representam completo, diferencial e log. Ajudam na investigação, mas não provam existência dos arquivos nem montam automaticamente um plano válido.

Separar a cadeia do log

Um full comum não quebra uma cadeia de backups de log existente. Logs continuam necessários após o backup de dados escolhido para atingir o objetivo. Mudanças de recovery model e arquivos ausentes são problemas diferentes.

Um log copy-only preserva o ponto normal de arquivamento e não trunca o log. Não substitui backups rotineiros do processo. Repeti-lo não resolve reutilização pendente que depende de cópias normais.

Coordene ferramentas. Agente externo, manutenção e operador manual podem gerar arquivos válidos sem que alguém conheça o conjunto completo. Centralize inventário e retenção pela recuperabilidade, não apenas pelo sucesso de jobs individuais.

Verificar dependências reais

Histórico pode sobreviver a arquivos excluídos. O destino também pode não ter o histórico msdb da origem. Examine cabeçalhos e todas as partes de um backup distribuído. Um nome contendo full ou diff não é metadado autoritativo. Confirme identidade, base, sequência e material criptográfico.

Para uma cópia pontual, use nome novo e opções adequadas. O modelo pressupõe banco de exercício existente e caminho acessível ao servidor. Substitua ambos deliberadamente. Ele omite INIT para não indicar sobrescrita de mídia existente.

BACKUP DATABASE [YourPracticeDatabase]
TO DISK=N'D:\Backups\YourPracticeDatabase_adhoc_unique_name.bak'
WITH COPY_ONLY,CHECKSUM,COMPRESSION,STATS=10;

Depois da cópia ad hoc, restaure full programado e diferencial em destino isolado, seguidos dos logs necessários. Backup bem-sucedido ou VERIFYONLY não demonstra sozinho a recuperação completa do negócio.

Preserve bases enquanto diferenciais dependentes fizerem parte da janela prometida. Registre arquivos e chaves de um teste bem-sucedido. Confira se políticas de ferramentas distintas não removem dependências ainda necessárias. Inclua um teste em destino sem histórico, obrigando reconstruir o conjunto pelos arquivos. Esse cenário revela procedimentos excessivamente dependentes do servidor original. Documente também quem pode localizar backups antigos quando o operador habitual estiver ausente. Confiabilidade exige cadeia explícita e testada, resistente a solicitações comuns de cópias adicionais.

Registre também a posição do conjunto quando várias cópias compartilham um arquivo. O caminho correto sozinho não identifica a cópia necessária para a restauração.

Referências técnicas: Microsoft Learn: Copy-only backups · Microsoft Learn: Backup history.