What are the challenges you face when working across database platforms? Take the survey
Options

Transaction Log Restores

vanderettovanderetto Posts: 7 Bronze 1
edited June 27, 2013 12:09PM in SQL Backup Previous Versions
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

Comments

  • Options
    peteypetey Posts: 2,358 New member
    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?
    Any problems pertaining to backup 'rules' will be raised by SQL Server during the backup process, and reported by SQL Backup. SQL Backup by itself does not perform any validation of the 'rules'. E.g. if your database is running the simple recovery model and you attempt to back up that database's transaction log using SQL Backup, it is SQL Server that raises the error, and SQL Backup simply reports it.

    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • Options
    vanderettovanderetto Posts: 7 Bronze 1
    Hi Peter,

    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
  • Options
    vanderettovanderetto Posts: 7 Bronze 1
    Just done some further reading on this and discovered that my understanding of my restore scenario is wrong.

    So, unless I'm mistaken, I could still use the same backup set for the restore without any problems.

    :oops:
  • Options
    peteypetey Posts: 2,358 New member
    Yes, you can still restore up to Log_6 using the same sequence you described earlier, or you could restore using that 'other' backup and subsequently just Log_5 and Log_6.

    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • Options
    vanderettovanderetto Posts: 7 Bronze 1
    Thanks Peter.

    Makes perfect sense now.


    Regards,
    Bob
Sign In or Register to comment.