Being new to SQL and trying to teach myself via the excellent tutorials on SQL Central, I created a test database using the full recovery model and created a single table which I populated on an ongoing basis. The aim of this was to practice the concept of backups and ultimately restores so that I could get to grips with the idea of taking a full DB backup followed by multiple log backups.
I had my test DB running for a few days and started the chain with a full DB backup. At random times during the day as the table within the test DB grew I would take log backups.
A couple of days of log backups (7 in total) and I figured I was ready to practice restoring. I deliberately "broke" the DB by renaming the mdf file after stopping the server. After restart I first did a "tail log" backup using the NORECOVERY and NO_TRUNCATE options.
So far, so good.
I next restored using the full database backup I had first taken to begin the restore chain.
No problem. All the time I am using the NORECOVERY option on the T-SQL RESTORE commands being used.
However, once I try to restore the 4th log backup in the chain an error is reported. The restore apparently completes, but an error message telling me that the DB was not able to initialize was issued. Checking the error log for more details as suggested did not yield any more information.
After scratching my head for a while and thinking back over what I'd done over the period covered by the log chain, I remembered that between log backup 3 and 4 (the one where the restore failed) I had created 3 filegroups with associated .ndf data files for the DB. Subsequent attempted restores of log backups beyond the failed one seem to spit out errors which also mention the new filegroup logical filenames, so I'm wondering if the transaction log chain cannot recreate new filegroups as part of the transaction roll forward.
Can anyone please help or clarify what's going on?