Barracuda backups, VMWare and Backup Device Type 7
-
Greetings,
We have Standard 2016 running on VMWare boxes, being backed up two ways. The first is normal SQL BACKUP commands, the second is via Barracuda Backups at a VM level. What is pasted below is from msdb.dbo.backupmediafamily and is showing the normal backups to disk, plus the BBS backups - considered as a device_type=7. At first blush I was alarmed as it appears the backup/log chain is broken by the bolded backup (which is from BBS), and 2. I have no access to that file. As I've been thinking about it, I am beginning to wonder if I am chasing my tail on this. Tell me your thoughts...My understanding is that BBS invokes the VMWare snapshot process, which in turn invokes the VSS snapshots on the SQL server. This causes an entry in this dictionary table. But I wonder if it's not really a file and simply a marker that the data was quiesced/snapped by vss. So if I needed to roll forward from an earlier (actual) backup file, it would not take that entry into consideration and simply move past it. (Yes I know I should be testing this, and I will, I thought I'd get the question out first though... And yes I need to find an article on how mssql uses vss).
Any thoughts, anyone?
thanks,
philphysical_device_name device_type physical_block_size mirror backup_set_id
\\xxxxxxxxxx\dbabkprod\MSQL_BKUP\xxxxxxxxxx\DBAUtil_20181009_2205_log.bak 2 512
\\xxxxxxxxxx\dbabkprod\MSQL_BKUP\xxxxxxxxxx\DBAUtil_20181009_2105_log.bak 2 512
\\xxxxxxxxxx\dbabkprod\MSQL_BKUP\xxxxxxxxxx\DBAUtil_20181009_2005_log.bak 2 512
{DB337215-6547-473A-A72F-A946A78B51FA}11 7 1024
\\xxxxxxxxxx\dbabkprod\MSQL_BKUP\xxxxxxxxxx\DBAUtil_20181009_1905_log.bak 2 512
\\xxxxxxxxxx\dbabkprod\MSQL_BKUP\xxxxxxxxxx\DBAUtil_20181009_1805_log.bak 2 512
\\xxxxxxxxxx\dbabkprod\MSQL_BKUP\xxxxxxxxxx\DBAUtil_20181009_1705_log.bak 2 512 -
Most likely it's a "virtual" device. My backups are (currently) handled by Commvault Backup with a SQL Server plug-in, and the backup device for all my backups shows as something similar to what you're seeing.
It's not a "file" that you can access, nor is it something you can choose to restore from, not within SQL. Within the backup application that created it, however, you could restore it.
As for whether or not this might be breaking your backup chain, the only way to be sure would be to test, test, test.
-
Sigh, I think I answered my own question. This document clarifies VSS: https://msdn.microsoft.com/en-us/library/cc966520.aspx
This gif cements it, seems to me the only activity in SQL server is the IO is frozen (and an entry is made in the dictionary). Any thoughts?
pg
-
I am not familiar with Barracuda. so I may be completely off-base. But, having used almost every other one at some point, here is what to dig into
The log chain is likely broken by this. At minimal, if you need to perform a point in time restore, you will need to get the log backups from both places. Test!
If Barracuda is using VSS, the momentary "File I/O is frozen" may cause an issue in your systems if there is a high enough level of activity. I have had to stop doing this on some of the more active systems. That freeze was enough to cause issues in the applications. Again, these were vary busy systems, with thousands of users connecting 24/7.
It sounds as if you need to work with the team that controls the Barracuda backup, and determine the best course of action. The only valid test is to perform a point in time restore and validate the data.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/ -
Just reemphasizing the single most important idea here... Test your restores. Test a point in time recovery. Validate that none of this results in you violating your RPO & RTO that you've negotiated with the business.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
Folks,
Thanks for the good words, I agree Testing, there is no substitute. I have contacted Barracuda support and they have confirmed their docs are unclear.
In this particular case, it is as I mentioned before - the only activity in the database is the device type 7 entry indicating the VSS system was invoked. There are no log backups, thus the log chain does not appear to be broken.
I will post Barracuda's clarifying statement when they send it.
thanks & regards,
phil -
From Barracuda:
Hello Phil,
I have send out an internal e-mail to our product manager, here is the body of the e-mail:I have send out an internal e-mail to our product manager, here is the body of the e-mail:
"A concern was raised by our customer Phil Godfrin about one of our documentation on the SQL/Exchange backup modes. "A concern was raised by our customer Phil Godfrin about one of our documentation on the SQL/Exchange backup modes.
The article in question: The article in question: https://campus.barracuda.com/product/backup/doc/78156821/backup-scheduling/?sl=AWZjWPX0BDp2IHciO-yP&so=5https://campus.barracuda.com/product/backup/doc/78156821/backup-scheduling/?sl=AWZjWPX0BDp2IHciO-yP&so=5
Under the SQL/Exchange part we would like to make it clear that those modes (smart, complete, log) apply only for the Agent Based backups. The current wording does not make it clear that is the case – could it be adjusted to say that it only affects Agent based backups. As it stands now, it may be interpreted as also being able to affect agentless backups (VM)."Under the SQL/Exchange part we would like to make it clear that those modes (smart, complete, log) apply only for the Agent Based backups. The current wording does not make it clear that is the case – could it be adjusted to say that it only affects Agent based backups. As it stands now, it may be interpreted as also being able to affect agentless backups (VM)."One of our product managers may be reaching out to you in this regard. Let me know if you have further questions.One of our product managers may be reaching out to you in this regard. Let me know if you have further questions.
D R
TIER 2 Technical Support Representative, Ann ArborTIER 2 Technical Support Representative, Ann Arbor -
So, have you tried a restore yet?
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Nope. I will.
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply