Transaction Log Restores
vanderetto
Posts: 7 Bronze 1
Hi All,
I currently have the following backup schedule for a selected database:
Weekly FULL, Daily DIFF & Hourly LOGS
I was under the impression that any FULL backup that was done on the database without the "COPY_ONLY" option selected, would result in the backup chain being broken and would potentially impact any subsequent restore operations.
However, I have discovered that this does not appear to be the case.
For example, I created a "rogue" full backup (using SSMS) in between my hourly RedGate Transaction Logs, thinking that any attempt to restore subsequent Transaction Logs would fail, but the restore procedure does not complain about the fact I have this "rogue" backup and allows me to restore the full set of previous logs, differential and full backups.
So, my question is how does the restore not complain about the fact that a full backup in the middle of my Trans Log schedule has been done without the COPY_ONLY option?
Hope this makes sense.
Thanks,
Bob
I currently have the following backup schedule for a selected database:
Weekly FULL, Daily DIFF & Hourly LOGS
I was under the impression that any FULL backup that was done on the database without the "COPY_ONLY" option selected, would result in the backup chain being broken and would potentially impact any subsequent restore operations.
However, I have discovered that this does not appear to be the case.
For example, I created a "rogue" full backup (using SSMS) in between my hourly RedGate Transaction Logs, thinking that any attempt to restore subsequent Transaction Logs would fail, but the restore procedure does not complain about the fact I have this "rogue" backup and allows me to restore the full set of previous logs, differential and full backups.
So, my question is how does the restore not complain about the fact that a full backup in the middle of my Trans Log schedule has been done without the COPY_ONLY option?
Hope this makes sense.
Thanks,
Bob
Comments
In your example, there is nothing wrong with taking a full database backup. Neither SQL Server nor SQL Backup can ever know that only full backups taken by your scheduled jobs are considered 'valid', and other other backups should raise an error during the restore process.
If you need to know when full backups have been made by other users, you can refer to the backup history tables, as described here.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
Thanks for taking the time to reply.
Reading back my post, I don't think I explained particularly well what my query is - I'll try and clarify a bit better.
Let's say I have the following backup files (all created by RedGate):
Full_1
Log_1
Log_2
Log_3
Diff_1
Log_4
Log_5
Log_6
Full_2
Log_7
Log_8
Log_9
Diff_2
Log_10
Log_11
If I wanted to restore up to (and including) Log_6, I would restore Full_1, Diff_1, Log_4, Log_5 & Log_6. Pretty straightforward.
However, let's say that unknown to me, someone had taken a full backup of the database (via SSMS) after Log_4. Surely in this case, the "log chain" will have been broken, and my attempt at restoring using the same backup set would fail?
Hope that makes sense.
Thanks,
Bob
So, unless I'm mistaken, I could still use the same backup set for the restore without any problems.
:oops:
A full backup affects only the base from which your differential backups need to restore from. E.g. if a full backup was taken between Log_2 and Log_3, then Diff_1 would require that you restore that full backup first. Full_1 would be rendered redundant for Diff_1, unless that other full backup was made using the COPY_ONLY option.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
Makes perfect sense now.
Regards,
Bob