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:
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.