I have a maintenance plan that takes full backups on wed and sunday at 12am and a differential backups on Mon. Tues, Thur , Fri and Sat'day. The Problem i came across was when ever a full backup happens on wed and sun the differential backup plan fails specifically for 2 databases 'abc1' and 'abc2' with an error
Executing the query "BACKUP DATABASE XXX TO DISK = failed with the following error:
Cannot perform a differential backup for database "abc1", because a current database backup does not exist. Perform a full database backup by reissuing BACKUP DATABASE, omitting the WITH DIFFERENTIAL option. BACKUP DATABASE is terminating abnormally.
Possible failure reasons:
Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established... The package execution fa... The step failed."
I had to perform a manual full backup for these two databases and had to run the differential backup job manually.
Example : When a full backup job runs on sunday at 12am, the differential fails for the two databases with the above error on monday 12am and i had to manually take full backup on monday for the 2 databases and run the differential job and it run fine on tuesday at 12am and on wed'day when the full backup job runs again, the differential fails again for 2 databases on thur 12am with the same error and i had to do the manual process again.
Try stopping the "SQL Server VSS Writer" service and change the start up mode to manual.
You might want to restart your computer.
Related
We have several databases on the DB instance. All user DBs are in full recovery mode. The transaction log backup is done every 15 mins using Ola Hallengren backup scripts\jobs. Currently, we have one log backup job that backs up all db's sequentially. This works well for most of the time.
However, during our weekly DB maintenance routine, log backups on some of our databases take much longer to complete ( due to index routine generating high log activity). This is causing some of the other databases have their log backup taken delayed. We are okay with the log backup taking longer but would like the other DBs to be backed up without waiting. The DB's are part of AG, so, cannot switch the recovery model.
Found out that using Ola's scripts we can set multiple log backup jobs using DatabasesInParallel flag. Tested this internally but I think it is not addressing the scenario I mentioned above
Created two log backup jobs with each starting at 15 min mark.
9:00 - Both log backup job start ( Log 1 & Log 2) and each of them backup 10 DBs. Log 2 job finished at 9:10 but Log 1 job took about 40 mins due to Db 9 has high log activity to backup.
9:15 - Log 2 job ran but did not really backup any DB.
9:30 - Log 2 job ran but did not really backup any DB.
9:45 - Log 1 and Log 2 ran and backed up DBs as expected.
Can someone confirm if this is expected behavior when there are multiple log backup jobs.
My plan in having two log backup jobs was to have Log 2 job backup other DBs ( except DB 9) at 9:15 and 9:30 run.
I'm having an issue that only happens sometimes where my SQL Server differential backup job fails with an error message similar to
Msg 3035, Sev 16, State 1, Line 1 : Cannot perform a differential backup for database "MyDatabaseName", because a current database backup does not exist. Perform a full database backup by reissuing BACKUP DATABASE, omitting the WITH DIFFERENTIAL option. [SQLSTATE 42000]
Msg 3013, Sev 16, State 1, Line 1 : BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000]
I'm currently using Ola Hallengren's SQL Server Mantenance Solution script for backup's, integrity check's and index maintenance. I've scheduled the backup job's as such:
Full Backup of system databases every day # 1:30 AM
Full Backup of all user databases every week on Monday, Wednesday & Friday # 2:30 AM
Differential Backup of all user databases every week on Sunday, Tuesday, Thursday & Saturday # 2:30 AM
Transaction Log backup or all user databases every 30 minutes
I've also set the cleanup time to 168 hours...which is 7 days.
I know that usually when this error message comes up, it is due to a full backup not being present, or possible the recovery mode on a database being changed. I have checked both of these and neither seems to be the case. I can confirm that my Friday full backup was successful, however my Saturday and Sunday Differentials failed. There have also been no changes to the recovery model, and no manual backup taken through SQL Server.
It's worth noting that this only happens sometimes. Sometimes the differential backups work without a problem and other times they fail.
This server is a VM, and we are using VMWare vSphere/vCenter 6.5. I've talked to my server admin and asked how his backup is running an he told me that we are using Quest AppAssure which leverage VMWare snapshot technology, and that he is backuping the drives every x number of minutes, so it is possible that the time of his backup changes and eventually overlaps with mine.
We looked back at the time that his backups ran on the weekend and they happened within a few minutes before mine started. I'm wondering if this is causing my backup issues? if so is there a way to prevent this, or do we simply need to plan the backups at different times that don't overlap?
Thanks
We had another call with Quest today and figured out a solution to the problem.
It would seem that when configuring the backup through Quest Rapid Recovery, you have the option to do Machine level backups or Volume level backup. When it's configured to do volume level backups you can choose for it to either do a block level backup which isn't SQL Server aware, or for it to do a backup that is SQL Server aware, which ends up using the volume shadow copy service and these backups show up as Full (Copy Only) backups in the SQL backup history...even though you can't restore them from SQL Server.
Rapid Recovery can only do backups on a schedule, plus has the option to Truncate Logs after the backup complete to avoid filling the log files, but can't do transaction log backups, so you loose the ability to do a more granular recovery down to the second like with the native SQL Timeline Recovery...Which is why we chose to use native SQL Server Backups.
So to fix the issue, you need to either do a machine level backup which has not SQL Server Awareness/integration. Or you can do a volume level backup, but disable the SQL Server Writer extension, and the truncate logs options to remove the integration.
We've run a bunch of tests, and from the point/time that this change was done, we only see SQL Server backups and no longer the Rapid Recovery backups in the SQL Server Backup history.
So now i am in talks with my server/backup admin see if we can do a machine level backup once a day, so that we can do a machine level restore in case of disaster, and also add a volume level backup of my Backup drive, so that he captures my backups more frequently during the day. I think once this is complete, we'll have the best of both backup solutions.
Ability to do machine level restores (Rapid Recovery)
Retention of SQL Server Backups (Rapid Recovery)
Flexible point in time recovery (SQL Server)
Just wanted to post a update to this issue
We scheduled a call with Quest yesterday, and they assured me that their backup is only taking volume snapshots and will have no impact on my SQL backups. They said that the reason that i was seeing these errors is likely do to Rapid Recovery(I guess AppAssure was renamed to Rapid Recovery) and my SQL backup jobs both trying to use the volume shadow copy service at the same time and so we simply needed to stagger the backup jobs. I end up finding out that this wasn't completely true because the Rapid Recovery backups were configured to truncate my SQL Logs. I also told the guy from rapid recovery that when i queried the msdb backupset table that i was seeing backup jobs listed that lined up with the times of the rapid recovery backup. Still he assured me that it would have zero impact on my backups.
I was still concerned that the Rapid Recovery backups might be impacting the chain of my backup files, so in our test environment i right clicked on one of our databases and clicked tasks > restore >database just to see the recovery history. I see a database backup listed as type Full (Copy Only) which coincides with the rapid recovery backup, then a number of my transaction log backups.
It would seem to me that Rapid Recovery is definitely impacting my SQL Backups.
One other thing to note that i just tried in out test environment. I did a few tests backups using Full's , Transaction Log, Differentials and Full (Copy Only) just to see how things showed up in the restore window in SQL Server Management Studio.
So i realized that in the default restore screen, it tries to recover to the nearest point in time using the least combination of various backup files. To go past the last full backup, I have to use the Timeline option.
I could see the Full backup as the first item, and then the transaction logs backups.
Once i do the Differential backup, i see the Full plus the differential, but no more transaction log backups.... which makes sense since it's trying to get the the closest time possible for the recovery.
Next if i do another Transaction Log backup, I see the Full, Differential and the Transaction Log back
One thing that surprised me however is if i do a Full (Copy Only) followed by a transaction log backup, that i see these two item in the list of files for the recovery, yet if i do a differential after a Full (Copy Only) that it show me the last Full (non copy only), plus the differential. I expected that the backups would always be based off of the last full, both for transaction log and differential backups. I thought that the Copy Only backups would be ignored in the backup chain.
Next I decided to use the timeline restore feature and select a point in time during my tests where the Rapid Recovery backup wasn't part of the listed backups, and do a verify backup. As expected it was successful. After this i tried a restore to another point in time where the Rapid Recovery Full (Copy Only) backup was listed and the verify failed on the Full (Copy Only) backup file from rapid recovery, since it doesn't exist on the sql server.
Any recommendations on how to fix this? The point of the Rapid Recovery backup is supposed to be to backup the machine, in case we ever loose the server and have to restore the entire server, plus for it to pick up my sql server backups to keep for retention, since i only keep 7 days worth of backup on the server itself.
You can check the error log file.
Your job may be the victim of deadlock transactions.
Backup file location may not have enough permission.
So, you should check all the possible error log files.
I use SQL Server. There is a problem with my differential backups. I take full backup of my database at the end of the week and beside, i also take differential backup of the database daily. I have created a job which makes these backing up tasks automatically. After taking those full and diff bakcups, i restore them with a job schudelar every day & week. My full restore job task works successfully every week but when my other task,which is restoring daily differential backup, try to work, it fails with " The log or differential backup cannot be restored because no files are ready to rollforward. " error message.
I have two database servers. One of them is production server and the other one is reporting server. Reporting server contains the same database in the production db server. At the end of every week, I take full back up of the db in prodcution db server for reporting server. In the same way, every midnight, i also take differential back up of the db in prodcution server for reporting server. Next day,I restore the last diff back up to the db in the reporting server. I use visual cron tool for the process but it has failed with that error. I tried to restore manual but got same error message.
Here is my restoring commands.
EXEC [dbo].[DatabaseRestoreMany]
#Databases = 'DB_2004',
#BackupRoot = '\\BCKPSRVR\BKUP\',
#BackupTypes = 'DIFF',
#DataFileDirectory = 'D:\DBFILES\DB_2004\',
#LogFileDirectory = 'D:\DBFILES\DB_2004\',
#DirectoryPerDatabase = 'Y',
#RecoveryState = 'STANDBY',
#ReturnBackupList = 'N',
#ReturnTaskList = 'N',
#Execute = 'Y'
How can i solve this issue? Can you help me?
Thank you in advance.
You've got this error because no full backup was restored prior to your restore from differential backup.
Today is wednesday. I had restored the full back up of the db on
sunday.
You restored your full backup with recovery. Your database became operational, it's online, and no more log or differential backup can be restored now.
In order to restore your differential backup you should first restore your full backup with norecovery, and only then you can restore your differential backup.
Please refer this BOL article to understand how differential backup can be restored: Restore a Differential Database Backup (SQL Server)
To restore a differential database backup
Execute the RESTORE DATABASE
statement, specifying the NORECOVERY clause, to restore the full
database backup that comes before the differential database backup.
For more information, see How to: Restore a Full Backup.
Execute the RESTORE DATABASE statement to restore the differential
database backup, specifying:
The name of the database to which the differential database backup is
applied.
The backup device where the differential database backup is restored
from.
The NORECOVERY clause if you have transaction log backups to apply
after the differential database backup is restored. Otherwise, specify
the RECOVERY clause.
I started using Managed Backups on my SQL server. It has been working well for over a year. It seems to backup the dbs once a week, and take incrementals every 2 hours.
A month ago, we changed our VM backup solution to Azure Recovery Services. We started running it every night. When Azure Recovery Services runs in the evening, it looks like, from the Windows and SQL logs, it takes a backup of each database before it does a volume shadow copy. They are entered into the logs as TYPE=VIRTUAL_DEVICE: and a big GUID, and a new database lsn number is created. When this VM backup occurs my weekly Managed Backups are invalidated.
When I look in the msdb.dbo.smart_backup_files table where the SQL Managed Backup stores its records to keep track of its backups, I can see there are 2 fields that seem to be important. backup_type. When this equals 1 it is a full backup, and when it is a 2 it is a log. The next field is the backup_database_lsn. This field represents the full backup that the log can be applied to.
When the SQL Managed Backup runs its full backup once a week, a new lsn number is created, and every log file that is created afterwords, has a value in the backup_database_lsn number that points back to that lsn number of the full SQL Managed Backup for that week.
Now, when Azure Recovery Services runs nightly, a new full database lsn number is created from the TYPE=VIRTUAL_DEVICE line in the logs. When I look in the Managed Backup table (msdb.dbo.smart_backup_files) I can see that all then subsequent log files that used to point to the Managed Backup's full lsn number now point to the new lsn number for the VIRTUAL_DEVICE of the Recovery Services backup.
If I need to do a restore of the Managed Backups, I can only get the full backup and 1 days worth of logs. After that, all of the log files now point back to the Recovery Services VIRTUAL_DEVICE backup, which doesn't really exist.
I have looked for the VIRTUAL_DEVICE backup. When I open a database through Enterprise Manager, and click on Restore for a database, it pulls up the most recent full backup (in this case the Recovery Manager full backup), and its log files. If I click on the full backup entry, it believes the file is in the SQL Server backup folder with the name of the file being the GUID. That file does not exist, or it may exist in the night VM backup which I can't view in Azure Recovery Services. Either way, my weekly Managed Backup is invalidated for the rest of the week.
Does anyone know how to make these two work together? I would like to have a full VM backup in case something bad gets installed on the SQL Server and we need to do a full restore, and I'd like to have a weekly full backup with incremental log files in case we need to restore one database.
It sounds as if what you are looking for differential backups. Those would contain everything added to the database following the last full backup.
I.e. you take a full backup on Sunday evening, with a differential backup every day after. On Monday evening, your differential backup would contain everything added since the backup. On Tuesday, it'd contain everything it contained on Monday, as well as everything changed since then.
If you'd do the same using Transaction Log Backups, your Monday evening backup would actually be identical to the differential backup described above. However, the Tuesday version of the Transaction Log backup would only contain the changes from the time of the Monday transaction Log backup.
When it comes to restoring, this would mean that in order to restore to a point in time, you would have to restore the latest Full Backup (Sunday), followed by every transaction log backup since, in sequence (Monday, Tuesday, etc.).
Using Differential backups, though, you would restore the latest Full Backup (Sunday), followed by the latest Differential Backup (Tuesday, if you're restoring on Wednesday).
This is my final hopes for expecting answer. Question is: How to do automated incremental backup in SQL Server only for 5 days? and how to schedule in task schedule tool. Please help me.
You might be confusing differential backups with incremental Backups.SQLServer doesn't have a concept of incremental backups..
You might get incremental effect (only backup what has been changed,from last backup) using Tlog*..Idea goes like this..
1.Take a Full Backup
2.Each day, by the end of day take Tlog backup
To Clarify,When you need to restore the backups /make database usable,you will need to restore Fullbackup ,followed by Tlog backups in order
*This is very Risky since ,it reduces your risk of restoring to a point in time
You can create a maintenance plan in SQL Server containing 2 parts:
A back up task for executing a backup every day (or every 5 days)
A clean up task for deleting all the backups older than 5 days.
Once created, you can plan it as a job in SQL Agent. Here's a great example about how to do it: Create a maintenance backup plan in SQL Server 2008 R2 using the wizard by Kyle Laffoon.