Backup history brokken with manual sql backupjob

sbssbs Posts: 5 New member
edited January 27, 2015 4:48AM in SQL Backup Previous Versions
Hello,
Can somebody tell me how to handle normal schedule backup jobs and manual SQL backup jobs?

I am running SQL Backup Pro 7.7.0.18
I schedule backup jobs as one weekly full and six daily differential.

The problem appear if someone do a manual SQL database backup by SQLs own tool. This breaks the backup history and my chances to restore after the manual job. I need to do a Full backup with Redgate, or wait for next full backup job, before restore again will success.

Any good advices?

Thanks.

Svend
· Share on Twitter

Comments

  • Eddie DEddie D Posts: 1,803 Rose Gold 5
    Thank you for your forum post.

    As you may know, each Differential backup has an association to the last Full Backup. In the situation you have described you have 3 choices:

    1. Restore the ad-hoc Full Backup created by native SQL Server, followed by the restore of the differential backup using SQL Backup. This will only work for you if you still have access to the Full backup file created by native SQL Server backup .

    2. If you wish to restore completely using SQL Backup sqb files via the restore history, you will need to take a Full Backup.

    3. You could wait for the next Full Backup, if you also take Transaction Log backups of your database. As you can restore the Full Backup created by SQL Backup, the Differential backup file created prior to the ad-hoc backup followed by the chain of transaction log backup files created since the differential backup file you restored.

    If you do not have access to the ad-hoc native SQL Backup file and also do not perform Transaction Log backups, you have a decision to make to between generating a new SQL Backup Full backup or waiting for the next weekly Full backup to run.

    Personally if I was in your shoes, I would take a SQL Backup Full backup (option 2).
    In my experience, if I did not have access to the native SQL Server backup file and wait for the next run of SQL Backup Full backup, knowing my luck something bad will occur, where I could not restore the database to the time period expected therefore instead of a small data loss potentially have a huge data loss. Hence why I would take a Full Backup which will save embarrassment, keep some of the pressure off and in the worst case scenario keep my job.

    I hope the above answers your question.

    Many Thanks
    Eddie
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
    · Share on Twitter
  • sbssbs Posts: 5 New member
    Perfect answer Eddie, thanks a lot.

    First choice is working for me, because I have the full backup file.

    My mistake was trying to do both full and diff restore jobs with the same tool.

    BR. Svend
    · Share on Twitter
Sign In or Register to comment.