Backups copy-only y restauración diferencial

Se crea un backup completo adicional para pruebas. Más tarde falla la restauración diferencial porque el plan todavía espera un full anterior. El problema no es que un full rompa la cadena del log: el full ordinario adicional cambió la base diferencial.

Seguir una secuencia concreta

Imagine full programado el domingo, full ordinario ocasional el martes y diferencial el miércoles. El diferencial depende del martes, no del domingo. Si el archivo del martes desaparece de un recurso temporal, domingo más miércoles deja de ser suficiente.

Con COPY_ONLY el martes, la base seguiría siendo domingo. Un full copy-only se restaura como un full, pero no se convierte en base de diferenciales posteriores. Conviene para copias puntuales fuera del calendario, no para todos los fulls programados: la estrategia diferencial necesita bases ordinarias deliberadas.

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;

La consulta muestra tipos, indicador copy-only y metadatos LSN. D, I y L representan completo, diferencial y log. Ayudan a investigar, pero no prueban disponibilidad real de archivos ni construyen automáticamente un plan válido.

Separar la cadena del log

Un full ordinario no rompe una cadena de backups del log existente. Los logs siguen siendo necesarios después del backup de datos elegido para alcanzar el objetivo. Cambios de recovery model y archivos faltantes son problemas diferentes.

Un log copy-only conserva el punto de archivo normal y no trunca el log. No reemplaza los backups rutinarios del proceso. Repetirlo tampoco soluciona reutilización pendiente que necesita copias normales.

Coordine herramientas. Un agente externo, mantenimiento y operador manual pueden generar archivos válidos sin que nadie conozca el conjunto completo. Centralice inventario y retención según recuperabilidad, no únicamente estados exitosos individuales.

Verificar dependencias reales

El historial puede sobrevivir a archivos borrados. El destino también puede carecer del historial msdb del origen. Examine cabeceras y todas las partes de un backup distribuido. Un nombre con full o diff no es metadato autoritativo. Confirme identidad, base, secuencia y material criptográfico.

Para una copia ocasional, use nombre nuevo y opciones correctas. La plantilla supone una base de práctica existente y ruta accesible al servidor. Sustitúyalas deliberadamente. Omite INIT para no indicar sobrescritura de medios existentes.

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

Tras introducir la copia ad hoc, restaure full programado y diferencial en destino aislado, seguido de los logs requeridos. Un backup exitoso o VERIFYONLY no demuestra por sí solo toda la recuperación del negocio.

Conserve bases mientras los diferenciales dependientes pertenezcan a la ventana prometida. Registre archivos y claves de una prueba exitosa. Compruebe que reglas de retención de herramientas distintas no borren dependencias necesarias. Incluya una prueba donde el destino no tenga historial previo y el operador deba reconstruir el conjunto desde archivos. Ese escenario revela procedimientos que dependen demasiado del servidor original. La fiabilidad exige una cadena explícita y probada, resistente a solicitudes habituales de copias adicionales.

Registre también la posición del conjunto cuando un archivo contiene varias copias. Una ruta correcta no identifica por sí sola la copia que necesita restaurar.

Referencias técnicas: Microsoft Learn: Copy-only backups · Microsoft Learn: Backup history.