Thanks for your reply.
The issue with using (what I think you are suggesting with your links) is that if you restore (or mount) an instance of SQL server/a Veeam backup then run a .bak backup (which was my previous idea - restore from Veeam, take immediate split backup, use a single file from that split backup to initialise replication), the recovery fork does not match the expected fork - essentially SQL Server sees this as a new instance of the database and thus has no LSN relationship to the previous (in-use) replicated version and does not sync the changes that have occurred between backup time and where (when) the active database is now.
I haven't got to the level of checking the internals of the .bak - but I suspect it resets the LSN so it no longer has the data that SQL needs to know where (when) to sync the replication from. It works fine ongoing, but any replication between those times (timedate of the backup and timedate of now) are lost.
I was hoping you would tell me that I could control the backup specifics (allowing me to adjust the exact specification of the backup) using Powershell or something (not that I know Powershell that well, but it would be worth me learning if I could get our recovery down by a 64th of the time by using the split .bak method!)
It is kind of an SQL problem - why should I have to present an entire .bak file of TB of size - just for it to prune a single LSN value from it!??! Maybe I'll look for a way to hack the .bak so I can create my own or something.
Anyway, thanks for your response; yes please consider a way to alter the exact specifics of the .bak export. I realise my case is somewhat niche, but I also believe there may be other use cases for more flexibility in that area.
Here's a link for more on recovery forks in SQL server and some background on why I cannot use the "Instant Recovery > Backup as split files" method (doing this starts a new recovery fork, the backup must be from the active database, a restore then backup is not sufficient), just in case I did not explain it well:
https://dba.stackexchange.com/a/340840/51645
The issue with using (what I think you are suggesting with your links) is that if you restore (or mount) an instance of SQL server/a Veeam backup then run a .bak backup (which was my previous idea - restore from Veeam, take immediate split backup, use a single file from that split backup to initialise replication), the recovery fork does not match the expected fork - essentially SQL Server sees this as a new instance of the database and thus has no LSN relationship to the previous (in-use) replicated version and does not sync the changes that have occurred between backup time and where (when) the active database is now.
I haven't got to the level of checking the internals of the .bak - but I suspect it resets the LSN so it no longer has the data that SQL needs to know where (when) to sync the replication from. It works fine ongoing, but any replication between those times (timedate of the backup and timedate of now) are lost.
I was hoping you would tell me that I could control the backup specifics (allowing me to adjust the exact specification of the backup) using Powershell or something (not that I know Powershell that well, but it would be worth me learning if I could get our recovery down by a 64th of the time by using the split .bak method!)
It is kind of an SQL problem - why should I have to present an entire .bak file of TB of size - just for it to prune a single LSN value from it!??! Maybe I'll look for a way to hack the .bak so I can create my own or something.
Anyway, thanks for your response; yes please consider a way to alter the exact specifics of the .bak export. I realise my case is somewhat niche, but I also believe there may be other use cases for more flexibility in that area.
Here's a link for more on recovery forks in SQL server and some background on why I cannot use the "Instant Recovery > Backup as split files" method (doing this starts a new recovery fork, the backup must be from the active database, a restore then backup is not sufficient), just in case I did not explain it well:
https://dba.stackexchange.com/a/340840/51645
Statistics: Posted by MHarris — Oct 17, 2024 11:39 am
.jpeg)
