August 26, 2015 at 2:25 pm
I tried setting up log shipping less than 24 hours ago and set the backups for every hour. When I look at the history of the agent job on the Secondary server I see a lot of these:
2015-08-26 15:25:05.73Skipped log backup file. Secondary DB: 'SFIDataLS', File: '\\VSQL3\SFIDataLSBackup\log\SFIData_20150826181000.trn'
Looks like it tries every log that was copied to the share. The next to last entry in the history log is:
2015-08-26 15:25:06.03Skipped log backup file. Secondary DB: 'SFIDataLS', File: '\\VSQL3\SFIDataLSBackup\log\SFIData_20150826191000.trn'
2015-08-26 15:25:06.03Could not find a log backup file that could be applied to secondary database 'SFIDataLS'.
2015-08-26 15:25:06.03The restore operation was successful. Secondary Database: 'SFIDataLS', Number of log backup files restored: 0
2015-08-26 15:25:06.03Deleting old log backup files. Primary Database: 'SFIData'
2015-08-26 15:25:06.04The restore operation was successful. Secondary ID: '196ba8d9-a5f5-4632-9091-d3f4a5e3501c'
2015-08-26 15:25:06.05----- END OF TRANSACTION LOG RESTORE -----
Exit Status: 0 (Success)
When I try to restore the oldest file in the share from SSMS, I get:
"Restore failed for server VSQL3....
System.Data.SqlClient.SqlError: The log in this backup set begins with LSN ....578340001, which is too recent to apply to the database. An earlier log backup that includes LSN ......4432500001 can be restored.
Does this mean I'm scrapping this and starting over? I can see the dates and times on the logs, so I know when they are taken. I've read before how to relate the LSN to the log, but I don't know if I have a log.
Wallace Houston
Sunnyland Farms, Inc.
"We must endeavor to persevere."
August 27, 2015 at 3:27 am
Are the LSCopy jobs working? Are the missing logs still on the primary? If so you might be able to manually copy them over and rerun the LSRestore job to see if it picks up and restores them.
Joie Andrew
"Since 1982"
August 27, 2015 at 6:29 am
Joie,
Yes, the copy job has worked all along(see caveat below) and I checked the backup folder against the restore folder on the Secondary. They have the exact same files. Yesterday, I even copied the original full backup and the .tuf file to the restore folder. Obviously, it didn't work and I knew I was grasping at straws.
caveat: When I first started the job I had an error on the copy (if I remember correctly). It was access privileges and I corrected it thinking that the next time the job ran (hourly) it would pick up where it left off. From the job history I can see that the job tries every .trn file in the restore folder, but skips each one because it's apparently looking for the first one. This line puzzles me:
2015-08-27 08:25:08.44Deleting old log backup files. Primary Database: 'SFIData'
I don't know where it's deleting them from. It looks like all the original .trn files are in the backup folder on the primary.
I think I'm gonna have to scrap it and start over.
Wallace Houston
Sunnyland Farms, Inc.
"We must endeavor to persevere."
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply