> > It's really only an issue if you manually list these VSS savesets in a
> > client definition.
> 
> My background is UNIX & Linux so my only exposure to VSS has been 
because
> I'm our primary NetWorker expert.  I've let our Windows admins handle
> all aspects of backing up our Windows clients.
> 
> With that level of inexperience in mind, could you explain why you chose
> to list the VSS savesets specifically, rather than just using "All"? 

With a windows client, especially Win2008 and later, a saveset of ALL 
includes the pre-defined DISASTER_RECOVERY: saveset. This is primarily 
everything defined as "system files" - pretty much "C:\Windows", 
"C:\Program Files" .. .and anything else that registers itself as a 
"critical" system program. In my case, Lotus Notes defines itself as 
"system critical" (i.e., needed for a disaster recovery recover), 
including all the mailboxes.

So here's the problem - DISASTER_RECOVERY: includes the D: folder 
structure that contains all the mailboxes. And if you use the ALL, you get 
DISASTER_RECOVERY: (meaning my 700G+ of mailboxes) .. and then get it 
again, as D: is now included in ALL.

So I have 2 jobs - one with a directive that only lists specific folders 
on D: drive, and one that SKIPS those same folders, and also gets C: (and 
the VSS I listed). That way, if a new folder gets created somewhere on D:, 
that is not in the Notes/Domino folder structure, I will still get it.

> I ask because our Windows admins have typically gone the other route: 
they
> specifically list C: and any other volumes they wanted backed, rather 
than
> using "All", specifically so they *don't* get the VSS savesets.
> 
> My understanding is that they have no intention of doing a bare-metal
> recovery if we had a catastrophe on a Windows client, so they see no 
value
> in the VSS savesets. 

In the specific case of a Notes DR, I would agree. Notes (well, Domino) is 
written in "old school" Windows - ini files and all. So our DR plan is to 
just re-install Windows clean; install Notes; Domino; restore the D: 
drive; and go ... which probably obviates the need for the explicit 
listing of VSS settings, given that we won't be doing a BMR recovery. But 
it won't hurt for them to be there, as long as I don't want to use them in 
a BMR scenario ...

> We don't have Exchange, our SQL Server systems
> currently are backed up after they do a SQL dump to a file (so no "hot" 
or
> point-in-time recovery, which we're currently OK with). 

We do both. Yes, on the same SQL servers. :-) I have half a dozen I do a 
"hot" backup with, using the NW SQL Module. They also write out the 
flat-file copy (the ".bak" file aka a file dump) every night, on a 
scheduled SQL Agent task. And I back that up, too ...

> About the only
> place we use the VSS savesets is for backing up our AD servers.
> 
> I'm just wondering if there's some advantage to listing them 
specifically
> that I'm not aware of.

Probably not, at least not in your case, and probably not mine, either ...