Log Shipping SQL Server 2012

Soy desarrollador en una pequeña tienda que no tiene un DBA y estoy tratando de hacer que el envío de registros con sql server 2012 funcione. Estoy tratando de descargar los informes del sistema de transacciones a un nuevo almacén de datos y usaré esta base de datos como área de preparación.

Ejecuté el asistente de envío de registros y los trabajos principales de copia de seguridad y copia de archivos funcionan cada vez. El trabajo de restauración secundario parece fallar aleatoriamente.

El servidor primario solo tiene el trabajo de registro de una transacción. La copia de seguridad diferencial está desactivada (no estoy seguro si eso es importante) pero tiene una copia de seguridad completa.

El servidor secundario es una instalación nueva sin planes de mantenimiento, copias de seguridad o usuarios activos.

¿Hay alguna manera de forzar la copia de seguridad de nuevo en sincronización, o siempre asegurarse de que permanece sincronizada?

Simplemente parece tan frágil. Por favor avise.

Registro redactado a continuación:

*Starting transaction log copy. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving copy settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieved copy settings. 
Primary Server: '', 
Primary Database: 'db', Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder', 
Last Copied File: '\\server\folder\db_20160105070002.trn'
Starting transaction log restore. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving restore settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Copying log backup files. 
Primary Server: 'server', Primary Database: 'db', 
Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder'
Retrieved common restore settings. 
Primary Server: 'server', 
Primary Database: 'db', 
Backup Destination Directory: '\\server\folder', 
File Retention Period: 14400 minute(s)
Retrieved database restore settings. 
Secondary Database: 'db', 
Restore Delay: 10, 
Restore All: True, 
Restore Mode: Standby, 
Disconnect Users: True, 
Last Restored File: \\server\folder\db_20160105060002.trn, 
Block Size: Not Specified, 
Buffer Count: Not Specified, 
Max Transfer Size: Not Specified
Disconnecting users. 
Secondary DB: 'db'
Copying log backup file to temporary work file.
 Source: '\\server\folder\db_20160105080001.trn', 
Destination: '\\server\folder\db_20160105080001.wrk'
Renamed temporary work file. 
Source: '\\server\folder\db_20160105080001.wrk',
Destination: '\\server\folder\db_20160105080001.trn'
Checking to see if any previously copied log backup files that are required by the restore operation are missing. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
The copy operation was successful. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7', 
Number of log backup files copied: 1
An error occurred restoring the database access mode. (Alter failed for Database 'db'. )
The file '\\server\folder\db_20160105070002.trn' is too recent to apply to the secondary database 'db'. 
(The log in this backup set begins at LSN 52498000002221000001, which is too recent to apply to the database. An earlier log backup that includes LSN 52498000002197900001 can be restored.
RESTORE LOG is terminating abnormally.)
Searching for an older log backup file. 
Secondary Database: 'db'
Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105060002.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105050001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105040001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105030001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105020000.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105010001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105000001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104230001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104220001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104210001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104200001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104190004.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104180000.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104170002.trn'

Could not find a log backup file that could be applied to secondary database 'db'.
Deleting old log backup files. Primary Database: 'db'

The restore operation completed with errors. Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'*

ACTUALIZACIÓN: Ejecutando debajo de la consulta hay una copia de seguridad del registro de transacciones extrañas (tal vez)

El NUL es lo que está en la mesa. No tengo idea de por qué no es NULL

Este es el tiempo de finalización de copia de seguridad, dispositivo, tipo

2016-01-08 02: 00: 01.000 D: \ Folder \ DB_20160108090001.trn Registro

2016-01-08 01: 00: 01.000 D: \ Folder \ DB_20160108080001.trn Registro

2016-01-08 00: 00: 00.000 D: \ Folder \ DB_20160108070000.trn Registro

2016-01-07 23: 46: 41.000 Registro NUL

2016-01-07 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 Base de datos

2016-01-07 23: 00: 01.000 D: \ Folder \ DB_20160108060001.trn Registro

Simplemente parece tan frágil.

Logshipping se prueba y se prueba desde los días 2000 del servidor sql (e incluso anteriores) No es frágil.

Mira los errores ...

Último archivo restaurado: \ server \ folder \ db_201601050 60002 .trn,

Logshipping está intentando restaurar

Destino: '\ server \ folder \ db_201601050 80001 .trn'

Esto significa que tiene un espacio en la secuencia de registro . Puede haber copias de seguridad de registro ad hoc que están rompiendo la cadena de registro.

Consulte mi respuesta: ¿Cómo sabe el envío de registros para realizar un seguimiento ?

Incluso puede restringir a los usuarios para que COPIEN SOLAMENTE copias de seguridad de registros , de modo que las copias de seguridad de registros ad hoc no rompan la cadena de registro. También,

@ Spörri hizo un punto válido para deshabilitar el servicio de escritura VSS de SQL, para que la herramienta de respaldo de terceros no pueda interactuar con SQL. ¡Es un dolor descubrir eso, ya que los softwares de terceros son locos a veces !

Para descubrir lagunas en sus copias de seguridad de registros, puede usar la consulta a continuación

SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = 'databaseNamePrimaryServer')
ORDER BY 
    s.backup_finish_date DESC;

Otra consulta útil:

-- http://sqlblog.com/blogs/tibor_karaszi/archive/2014/11/03/can-you-restore-from-your-backups-are-you-sure.aspx
-- modified by Kin to include backup start and finish dates
SELECT TOP(100)
database_name
,CASE bs.TYPE
   WHEN 'D' THEN 'Full'
   WHEN 'I' THEN 'Differential'
   WHEN 'L' THEN 'Log'
   WHEN 'F' THEN 'File or filegroup'
   WHEN 'G' THEN 'Differential file '
   WHEN 'P' THEN 'Partial'
   WHEN 'Q' THEN 'Differential partial'
END AS backup_type
,bs.is_copy_only
,bs.is_snapshot
,bs.backup_start_date
,bs.backup_finish_date
,DATEDIFF(SECOND, bs.backup_start_date, bs.backup_finish_date) AS backup_time_sec
,mf.physical_device_name
,bs.database_name
FROM msdb.dbo.backupset AS bs
  INNER JOIN msdb.dbo.backupmediafamily AS mf ON bs.media_set_id = mf.media_set_id  
  where database_name = 'master' -- change here for your database 
ORDER BY backup_finish_date DESC;