April 17, 2023 at 8:13 pm
We have a Datto back appliance backing up our SQL servers. It's set to do "Application Aware" backups, meaning it runs a full backup, and I see backup type 'D' in the system backup history tables.
I am also doing native SQL FULL backups, and native DIFF backups. When my DIFF runs immediately after the Datto "Full" my Diff fails.
Why does my DIFF not recognize the Datto FULL that was recently run ?
Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 15.0.4298.1 for 64-bit Copyright (C) 2019 Microsoft. All rights reserved. Started: 11:45:00 AM Error: 2023-04-11 11:45:04.02 Code: 0xC002F210 Source: Back Up Database Task Execute SQL Task Description: Executing the query "BACKUP DATABASE [MyDatabase] TO DISK = ..." failed with the following error: "Cannot perform a differential backup for database " MyDatabase ", 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 correctly. End Error Error: 2023-04-11 11:45:04.08
I am in the process of convincing the Network people to stop the Datto "Application Aware" backups and only backup the rest of the server. And let native SQL handle database backups.
April 17, 2023 at 8:55 pm
It appears Datto also runs "DIFFs" during the day, but they also show as type 'D' in the SQL backupset table, not 'I' , and do not impact the native SQL DIFFs.
I am not clear about what Datto is actually doing.
April 18, 2023 at 10:38 am
Our network team have just installed their new backup system, called Cohesity, on one of our servers. It seems to work in a similar way to Datto. My backup routine immediately detected the differential LSNs did not tie up with my last full backup and started doing full backups once a day instead of once a week. Datto must be using the SQL Server VSS writer service and not setting the COPY_ONLY flag.
Your options are:
Pro tem I have disabled the VSS Writer for Cohesity backups and am still using native backups. This means if the VM is ever restored from Cohesity the database files are likely to be in an inconsistent state and require a restore from the native backups.
To be fair Cohesity, and presumably Datto, actually look good. The documentation mentions incremental backups which as far as I can make out mean a full VSS backup is done and then compared to the previous VSS full backup with only the differences being saved. It also seems to handle log backups and point in time recovery.
Cohesity also has a REST API with PowerShell wrappers. Before I can switch my database backups to Cohesity I will need to learn how to use the API to:
A lot of testing will also be required.
In conclusion, you can solve your immediate problem by disabling the SQL Server VSS Writer service on the server. Just be aware you will need to restore from native SQL Server backups after a VM restore. You can then contact Datto support to see if there is a way to toggle the COPY_ONLY flag for a full backup or disable the SQL Server VSS writer just for Datto backups. When you get time you should probably look at switching your database backups to use Datto. These types of backup system, with immutable storage, seem to be required for compliance and insurance.
April 18, 2023 at 3:05 pm
Thanks for the comprehensive reply.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply