We are having trouble with our backups after we switched from NBU 8 to Veeam 9.5. Previously using the enterprise vault plugin in NBU, backups were great. We moved to Veeam because of our heavy VMware infrastructure and some of our other needs, so our we’ve moved Vault backups to it as well.
We got the trigger bit working to put the vault system in backup mode, back it up with Veeam, and remove it from backup mode. That seems to work, but the vault server is complaining that it thinks it hasn’t been backed up in 19 days (the amount of days on Veeam). This is an example of two of the errors, both seem SQL related.
EventID 41011 – “The SQL database for Vault Store 'VaultMailStore' has not been backed up for 19 days. The information in this database is at risk until the database has been backed up.”
EventID 41012 - “The SQL database transaction log for Vault Store 'VaultMailStore' has not been backed up for 19 days. The information in this database is at risk until the database has been backed up.”
I think its related to the archive bit (which is separate from the trigger bit? We are still learning) possibly not being set right. Can anyone that is using Veeam now successfully help us understand at a high level what jobs are involved in backing everything up this way? I feel like maybe we are missing a SQL backup component now, that was unnecessary with NBU. We are concerned about our data – please help!
*edit* One other related issue with Veeam that might be an easy answer from the same person – it seems like the Veeam job analyzes all ~7 years of archived content we have which is around 6TB. It seems like this might be making the job take longer, and it seems unneccesary to backup all the closed partitions. The job is set to ‘entire computer’ and pointed at the vault server. Should we change it to Volume level backup and just target the open volumes?
Any advice is much appreciated!
These would related to the SQL DB backups themselves from the SQL server side. It does not relate to the index or partition backup.
Have you confirmed that SQL backups are running properly?
For the backup of closed partitions it would depend on whether the partitions are being Collected into CAB files (set on the partition properties) and if you are running Storage Expiry. This will cause the data in the volumes to fluctuate so it is a good idea to keep them the backups the same as the SQL backups so that records match up to the data in the partition.
Thanks for the reply. With NBU I dont think there has ever been any scheduled SQL maintenance - reason being is we switched from NBU to Veeam, and then it started complaining the next day with these SQL errors, we didnt change anything on the SQL side at the time of the change over.
It seems like NBU's enterprise vault policy might have been taking care of that - but now that we are using a 'less intelligent' (from Vaults perspective) backup solution, we have to set that up?
Regardless - I cant find anything about the timing of the SQL side. If we configure backups, matinenace etc. on the SQL side - does it matter when it runs? Does it have to be run during the time vault is in 'backup mode' ? I couldnt find guidance on this - really appreciate any thoughts you have on it.
THanks for your comments on the closed partitions as well Patrick - it looks like we do have collection setup. We do have expiry running. Do you backup the closed partitions on the same frequency as your open partitions?
The original message you posted is related to SQL backup. Usually, you backup the Transaction log several times a day (we do it every 3 hours). See https://www.veritas.com/support/en_US/article.100022023
for guidelines. I am not a DBA, but I believe transaction log backup needs to also shrink the transaction logfile.
In regards to Storage Expiry, see https://vox.veritas.com/t5/Articles/A-Gentle-Approach-to-Storage-Expiry/ta-p/813574 and also https://vox.veritas.com/t5/Articles/How-collections-and-sparse-collections-work/ta-p/810837
That last article explains what happens when running expiry when you use collections.