Hello,
I have a client who uses NetApp's SnapManager to take backups of their production SQL Server 2012 SP4 production database. They then take that backup and use the "CREATE DATABASE ... FOR ATTACH" to create a copy of that database in their non-production environment every Saturday (Jan 26th, Feb 2nd, Feb 9th and Feb 26th).
Then they take a native SQL Server backup after the attach is done. In some cases, we see that the backup's "last_lsn" is the same as the previous backup's:
We know they have taken a new backup because the backup_set_uuid has changed. The problem we see here is that the last_lsn is jumping around as highlighted. It was 5233000003916000001 on January 26th. It started incrementing like you would expect if there were changes in the database. Then on February 16th when they attach another copy, it jumps back to 5233000003916000001.
I have not been able to reproduce this issue outside of NetApp SnapManager unless I make a physical copy of the databases files (log, data and index) and attach an untouched copy twice which doesn't make sense in the context of their described workflow. It does not appear that they have restored a backup on their production environment or we would expect the last_recovery_fork_guid to change.
I don't have access to or experience with SnapManager. Is this type of behavior expected? Has anyone experienced something similar?
Thanks,
Neal
