Video Screencast Help

Explain the "Perform full VSS backup" option

Created: 27 Feb 2008 • Updated: 21 May 2010 | 8 comments
I've looked for information about this option and found very little. Most information seems to indicate it applies to Exchange.  I'm running SQL 2005, what affect is checking vs. unchecking this option going to have (if any) on backing up these servers?
I'm not running this checked on any system at the moment. What advantage would it give me with Exchange?

Comments 8 CommentsJump to latest comment

RahulM's picture
For information on VSS with BESR please refer to APPENDIX B of the BESR Administrator's Guide
Download the Backup Exec System Recovery 8 User Guide (Implementation Guide)
RBall's picture
I've read appendix B, it does not mention why you would turn the "Perform full VSS backup" on or off in the Advanced tab while setting up the backup job.  I was under the impression that BESR automatically recognizes (and the appendix seems to agree) VSS aware applications like Exchange and SQL and functions correctly. In fact, the option is unchecked on all my servers and they seem to be backing up just fine.
I was wondering... should I be checking this option for my Active Domain Controllers, Exchange and SQL database servers?  It seems to make no difference when I tried my SQL server both ways.
So... Can someone explain the "Perform full VSS backup" option?  What advantage is there to checking it?
RahulM's picture
This option was included to allow for additional interoperability with other applications that use VSS to perform backup operations.  We always use VSS to quiesce the system regardless of whether this option is checked or not.  When this option is checked however, we will do a full backup, and request truncation of transaction logs through the VSS API.
polycue's picture
If the "Perform full VSS backup" option is not selected what is omited from the backup image as compared to the image created with  the "Perform full VSS backup" option turned on?
AndrewPBG's picture
If I follow correctly, there is never anything omitted from the backup, but rather some extra maintenance tasks may be run by VSS aware applications when a "full" backup is run. In SQL's case (and I can only imagine this being the most common case by far), this maintenance would include the truncation/flushing of transaction logs for any databases using the "Full" recovery model.
David F's picture

AndrewPBG that is correct

BJ A's picture

What is the benefit of the "truncation/flushing of transaction logs for any databases using the "Full" recovery model?  Is this activity one of the "extra maintenance tasks" AndrewPBG refers to, and would/should I use this "full VSS backup" for a 2007 Gateway laptop if I were to use the backup to fully rebuild my computer if I had to?  I don't have the vocabulary, but we all have to be somewhere!

marcogsp's picture

BJA -- The benefit of truncating and flushing the transaction logs and committing transactions to the database(s) before backup is a matter of consistency.  Think of putting a database in a consistent state in the same light as that of an airline pilot going through the checklists before taxiing the plane on the runway and taking off.  If anything on that list is not corrected, then it is not safe to take off.  For databases that use transaction logs, it is best to "go through the checklist"  and prepare the database for backup.  A restored database that is in an inconsistent state will not mount until that condition can be corrected.  The process can be quite tedious, so it it always best to do it right the first time.

Unless you are running databases programs that BESR does not recognize, chances are you do not need to run a full VSS backup.  My understanding of the full VSS backup is this:  BESR natively recognizes several VSS aware databases (sorry I don't have the complete list) and will invoke VSS automatically while imaging.  However if you have a VSS aware database program that is not in the native list, then running a full VSS backup will cause BESR to query all the VSS writers in order to backup the databases in a consistent state

The alternative to to using VSS is to stop the database services which will automatically truncate, flush and commit.  Of course this has to be done via command file or script before imaging and then again after the snapshot is taken or after imaging in order to restart the database services.  MSSQL 2000 databases have to be imageed with BESR in this manner.  You can also do this with Pervasive SQL databases, but as a general rule, I don't.  I have several Pervasive SQL 8.0 databases that I backup with BESR without stopping the services.  As long as the databases are not open and no transactions are being written to them, I've always had good luck in doing hot backups of Pervasive SQL without any other intervention