Backup history brokken with manual sql backupjob
sbs
Posts: 5 New member
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
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
Comments
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
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
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