Snapshot Explanation!

A Windows 2003 NetBackup client typically has two types/methods of snapshot available:

VSP by Veritas/Symantec (you can choose not to install this by using the silentclient.cmd to create your own custom client install script - because the installation of VSP always requires a reboot, whereas if you don't install VSP, you can use the NetBackup client right away).

VSS by Microsoft, which I hear some people seem to have better results with on Windows 2003.

 

Both VSP and VSS are not used, and cannot be used, to take backups of databases, e.g. Exchange, SQL, Domino etc...  For these you either close the app down and secure using the plain client (i.e. NTFS disk backup), or you purchase the appropriate NetBackup database client "extension/option".  Incidentally, the licencing model for v6.5 has changed, and now a "database extension" licence can be used to backup any of the supported databases.

 

VSP and VSS are not snapshot tools in the old sense of the word.  What they both actually do is to save the old/original copy of data as updates are made to disk by other programs/systems.  I.e. when other applications write to disk, then the O/S is aware that the disk is being backup and that VSP/VSS is being used, and so the O/S performs a read of what is about to be overwitten and saves a copy of the "old" data (in the snapshot) before completing the disk write for the other app.  This way the NetBackup client can still backup what the disk originally looked like because the O/S I/O disk subsystem "rebuilds" the data, i.e. the NetBackup client is none the wiser, and thus backs-up/saves a copy of the original data when it comes to reading a file that has changed since the backup started.  Also, this means that the cached data-set can simply be discarded at the end of the backup.

 

My tips/notes (for VSP mostly, and a little for VSS):

 

1) The VSP cache file for a disk is always stored on another local disk.  If you have a system with only one local drive, then VSP will never be used.  I'm not sure about VSS.  (Can anyone else comment please?)

 

2) VSP cache files will never be saved to network drives, and VSP cannot be used to secure network drives.  I assume the same is true for VSS.

 

3) If you are using ALL_LOCAL_DRIVES and no multi-streaming then you don't need to worry about controlling how many backup streams run at once... but if you specify folders or disks separately or use ALL_LOCAL_DRIVES plus multi-streaming then you may want to look at specifying the maximum amount of concurrent backup jobs that the client can run at once (by using the "Client Attributes" tab of the master server properties).  The reason I say this is more for VSP (but I suspect the same is probably true for VSS)... for example, you have a big fast client with six local drives in seperate spindles/buses etc and the client could easily support all six disks being backed-up at once - but if you use VSP then the NetBackup client/VSP will not have anywhere to store a VSP cache file, because a VSP cache file (for any given disk) cannot be stored on any other disk for which VSP is being used to cache.  Makes sense?  So, in this example I would limit the number of streams to half the number of local drives, i.e. three backups - this way all backup jobs will each have another drive (that is not being backed up), upon which to store the VSP cache file.

 

4) VSP and/or VSS is not a way to read through locked files.  If a file is really locked down by an app or O/S then the NetBackup client is still not going to be able to read the file whether VSP or VSS is used or not.

 

5) Enabling VSP on a NetBackup client does not necessarily mean that it will be used.  The O/S (i.e. the VSP driver) needs to ensure that a disk is not being written to before it can insert itself into the I/O sub system.  I mean that the VSP driver needs to see specific period of quiet (no writes).  If the VSP driver does not experience the quiet period then VSP gives up and is not used, and the NetBackup client continues its backup without the use of VSP.  You can specify how long the quiet period needs to be, and you can specify how long to wait for the sufficiently long quiet period (see next item below).

 

6) By default VSP cache files can grow up to a max of 30GB.  I always configure the "VSP" tab in the client "Host Properties".  My preferred default settings are;

   - (no included or excluded drives)

   - specify size in MB

   - initial size 500 MB

   - maximum size 3000 MB

   - Leave the "busy file wait" at five seconds.  (The name of this item "busy file wait" is not very accurate/helpful, what it actually specifies is the length of time that the VSP driver should wait for a disk to be quiet (no writes) before interjecting in the I/O sub-system, i.e. actually turning on VSP.  This is a "quiesce wait", i.e. it specifies how long a period of time must pass of no disk writes.

   - "VSP busy timeout" 120 seconds (the default is 300 seconds).  This specified how long to wait for the "5 seconds of quiet" (above).  To my mind, if a disk isn't quite for a period of 5 seconds during a two minute window, then the disk probably isn't going to be quite for 5 seconds during a five minute window.   I'd rather VSP gave up sooner and let the NetBackup client move on and take the backup without VSP. 

   - I also add the client to the master server host properties "Client Attributes" tab and and then for the client in the "Windows Open File Backup" tab, for the "Snapshot error control" select "Disable Snapshot and continue" - so that backups during which VSP fails will at least try to continue.

On one or two busy clients (out of 150+) I have set max to 5000 MB to get it to work.

 

7) Always exclude the VSP cache files from anti-virus scanners.  This is the single biggest problem most people/sites come up against.  The trouble is that the "naming" of the VSP cache file has changed with several times with the different NetBackup client versions.  Here's what I have found so far:

   v4.5                   *:\VSPCache*.VSP 
   v5.1                   *:\_vxfiVspCacheFile_*.tmp
   v5.1 MP3aS2+  *:\_vxfiVspCacheFile_*.VSP
   v6.0                   *:\NBU_VSP_Cache\_vxfiVspCacheFile_*.vsp

   v6.5                   (Can anyone else confirm naming convention for v6.5 clients, please?)

Sometimes VSP cache files get left behind, and you don't want to back them up, so I usually add the above to each clients NetBackup exclusion list as well as the anti-virus scanner exclusion list.

 

8) I used to recommend adding drive letter "C" to the list of drives to be excluded from VSP, in the client "Host Properties" - but these days I would only consider it if the C drive was very low on disk space, and/or was constantly being thrashed or updated (written to) by other apps.  I.e. these days I let the C drive be used to host a.n.other volume's VSP cache file.   If you have other disk volumes that are constantly being updated by other apps you may want to consider excluding those particular drives too - because the VSP cache files will get very big quite quickly trying to hold all the old/original data that once existed.

 

9) Sometimes VSP cache files get left behind from failed snapshots and/or failed backups.  Sometimes these files cannot be deleted because the I/O kernel is still holding on to them.  A reboot will get rid of the lock, but doesn't always cause the file to be discarded - sometimes you still need to manually delete it after a reboot.  Supossedly the O/S's lock on a VSP cache file can be broken/severed by using a Sys Internals tool (now owned by MS) - but personally I'd have to be pretty desperate before doing that on a production system - hence I always configure a VSP maximum size.

 

10) I have a DOS script that can scout around Windows clients looking for old/orphaned VSP cache files.  Let me know if you want a copy.

 

11) MS Windows VSS does have a DOS command line enquiry tool, named "vssadmin" in WinXP and Win2003.  (Does anyone know if/how VSS is configurable?)

 

HTH,

Dave.