This post is more than 5 years old
1 Rookie
•
39 Posts
0
5679
February 23rd, 2016 11:00
VSS and Windows FS plugin strategies.
I'm running Avamar 7.1 and I'm looking for some strategies on the use of VSS and Windows file system plugins. We are running W2K8 and W2K12
Is there an intended framework on how to use these in cooperation with each other? Our Windows admins insist that a VSS backup must be done every night along with the file system backup. This results in (2) jobs running each night. In a DR scenario, wouldn't a weekly VSS backup be sufficient (probably depends on what we want), but is a nightly VSS backup a 'reasonable request?'
I also understand to capture all applications, every volume with installed apps must be backed up via VSS. Does this imply that volumes containing application data be logically separated from application volumes to allow VSS to capture only what is needed to DR the server, and the 'data' be recovered via the fs plug afterwords?
Any guidance is appreciated.
ionthegeek
2 Intern
•
2K Posts
0
February 29th, 2016 11:00
There are several types of backups to talk about here.
It makes sense to run daily filesystem backups. You should exclude any application data (e.g. SQL databases) from filesystem backup. There is no guarantee that the application data is in a consistent state during a filesystem backup.
Applications should be backed up using the appropriate plug-in (SQL plug-in for SQL, MOSS plug-in for Sharepoint, Exchange plug-in for Exchange, etc.). Most of these plug-ins use the corresponding VSS writer. This ensures that the data is in a consistent state before being backed up. For applications that don't have a plug-in (e.g. PostgreSQL), you can use a "dump and sweep" strategy to back up the data using the regular filesystem client, i.e. dump a consistent copy of the data out to disk and back it up as normal.
You mentioned "VSS" which in this context probably means the VSS System State plug-in. This plug-in backs up the system state data (including the registry hives) plus any volumes that are deemed Critical by the Microsoft ASR VSS writer. The boot and system volumes are always critical. Any volume containing the binary for a service is also considered critical. For example, if you have Exchange or SQL installed, the volume where the service binaries for those applications are installed will be considered critical. VSS System State backups can only be used with the Bare Metal Restore ISO to perform a bare mental recovery. These backups cannot be used to recover files or application data.
I would consider a daily VSS backup a reasonable request -- filesystem and VSS backups take advantage of de-duplication and use the same caches so there won't be any significant effect on capacity utilization and the additional time shouldn't be significant unless the client has a lot of small files or a really high daily change rate.
Somebody else in the thread mentioned VMware Image backups -- these essentially replace VSS System State and filesystem backups. VMware Image backups are currently only crash consistent, not application consistent. Any applications have to be protected at a guest level or manually quiesced prior to the start of the image backup. Note that file level restore has a number of limitations, especially around the number of files that can be browsed or restored at one time so be sure to read the documentation thoroughly.
umichklewis
3 Apprentice
•
1.2K Posts
0
February 24th, 2016 10:00
How are your jobs structured, i.e., what's in the data set for your servers? In our case, I only have the System State selected in our VSS backups on our Windows servers and the filesystem backups are in a separate job.
If you have different Microsoft applications, i.e. SQL, Exchange, Sharepoint, etc., each one requires a different VSS plugin to backup the data specific to that application. In the case of other applications, however, it will depend on how they're built. For example, I have a Windows server with a UniDesk application that uses SQL on the backend. I have an SQL VSS backup, a System State BMR backup and a filesystem backup for this server. The SQL backup captures the database and transaction logs, and can be used to restore the UniDesk database back to the point of the backup. However, the SQL backup doesn't have the configuration files in the filesystem or the user profiles, so I need the filesystem backup to capture the application's files.
In the event we lost the whole VM, the recovery procedure we use in my group is to 1) do the bare-metal restore, 2) do the filesystem restore then 3) do the SQL restore. So far, this has worked pretty nicely for us.
While it is possible that our VSS backups have the same files as the filesystem backup, we know we want the filesystem backups for our data, because we run them shortly after a particular batch job writes data into the filesystems in the early morning. If we used the VSS backups from the early evening, we would miss this files.
Let us know if that helps!
Karl
BSeizer
12 Posts
0
February 24th, 2016 13:00
I also have Win2008 and Win2012 servers. Most of these servers are VM guest servers. About 300.
I have very few physical servers running Windows. About 5.
I dont do the VSS backup of a windows file system.
The VSS backup and the windows file system backup ARE 2 seperate backups. Even if you place both in the same Avamar dataset.
This is what I do.
Windows File Server:
If it only holds files, and not anything else like SQL, SHarePoint, or Exchange, then I use a Avamar proxy server and do a VMWare Image Level Backup (ILB).
Doing this will get you all of the config info of the server, and the registry, as well as the files.
Restoring the server is so much easier than trying to perform a VSS restore.
SQL:
SQL backup using the MS SQL plugin.
File system backup, excluding the MDB and LDB files.
VMWare Image Level Backup (ILB).
This server is backed up 3 different ways every night.
Exchange:
EXchange backup using the Exchange VSS plugin.
If you want to back up Public Folders, then youll have to make that a separate backup.
File system backup.
Do NOT perform a VMWare Image Level Backup (ILB) of this server. You will make Exchange angry.
This server is backed up 2 different ways every night.
SharePoint:
Sharepoint backup using the MOSS VSS plugin using the GLR function.
Only run on the Avamar foreground server. That one server will act as teh proxy for the entire farm.
My Sharepoint points to an instance on a separate SQL server, so the SQL server will get hit again.
Make sure you schedule this after your sure that the SQL backups are complete.
One backup per night for each farm.
VMWare Image Level Backup (ILB) of each server within the farm.
This farm is backed up 2 different ways every night.
J_H_
2 Intern
•
498 Posts
0
February 26th, 2016 09:00
depends on what VSS you are talking about.
if VSS is like system state, yes I take both
and I have them both in the same policy, because it can only take one backup of the server at a time, having them in two different jobs does not matter. (but you could do the FS in one with an early start time and the VSS with a latter start time to make sure the FS always gets backed up first.)
And the VSS (system state does not backup the whole system)
one of my servers for example the FS backup is 527 GB where the VSS is 41 GB
Now doing special backups like SQL Oracle Exchange can also be referred to as VSS because that is how they are referred to in Avamar.
So if you are referring to the VSS that is equilivant to System State, I do both in same policy but is it is not backing up the same stuff and it can be used different for a system recovery.
simple_gifts
1 Rookie
•
39 Posts
0
February 29th, 2016 11:00
Yes, I was referring to the file system VSS; We have scheduled both plugins in one dataset and I'm now questioning the wisdom behind that.
I don't think our admins were given much guidance to specifically separate data from applications; consequently, many of our VSS fs backups are as large as the filesystem backups (i.e. application data has been mixed in with application installs) Not optimal since it creates the possibility of (2) long running jobs, instead of just (1).for machines with a lot of data.
Your contributions have helped me, and I appreciate the time you have spent relaying your experiences.
Thank you.