Customer is running Avamar 7.3.0-233, client is Windows 2008 and 2012. They are virtual fileservers and they customer has EVERYTHING in the C: drive instead of adding a 😧 for the fileserver. (I already know that this is not the 'right' way to do this). The 'issue' is that they are running a filesystem backup as well as a VSS 'system state' backup...the VSS backup is going through the entire 1.4TB just like the filesystem backup is...my question is this...is there anything we can exclude or a parameter we can change that will allow the VSS backup to NOT take as long as the FS backup?
What it sounds like to me your doing a bare metal restore (BMR) backup which includes all critical volumes which would be the entire C: drive.
What is the goal of backing up a file server system state? In my experience its not needed for a file server. In a disaster its not a big deal to build new OS and restore the files. Or if its a VM back it up as a VM instead of system state. You can do both file and VM if you want.
a VSS backup is not JUST to rebuild a server.
we had a recent issue where some issue with key broke the server application.
MS recomended the restore from the System State backup rather than the FS backup.
(I am not a windows person do don't know why this important), the first restore was from the FS and they had still had issues.
did the restore from the SS backup and they were able to fix the system.
As to an exclude, I don't think you can add an exclude to a SS or VSS backup.
I've never really investigated it in detail, but I always figured that one could potentially do the following:
1) If one is performing a VSS backup and one knows for certain that the C: drive is going to be backed up, one could probably just set up the dataset to perform the VSS system state backup and "not bother" with performing a file system backup on the C:\ drive; this could potentially apply to other "critical volumes" on the server as well
2) With all of the "critical volumes" being "pulled in" during the VSS backups, the filesystem backup could be focused on whatever other "non-critical volumes" were on the server; this would address the "duplication of effort"
However, I believe that the "best practice" (not sure if it is spelled out anywhere) is to perform the VSS backup for system state as well as the overall filesystem backups; I think the logic behind that reasoning is that with deduplication, the repeat backups should run quickly enough that the duplication of effort is not a big deal.
VSS System State backups can't be restored at a file level so skipping filesystem backups would not be an effective strategy if you ever needed to restore individual files stored on critical volumes.