Anybody able to answer the following questions regarding NetBackup and DFSR backups
1) What exactly does NBU look for to determine that the client should be treated as a DFSR client and not a standard client. The article listed below states that it detects the DSFR instace the question is how? Is it a registry entry, the presence of the VSS DFS Replication writer or something else?
2) Does NBU check this every time it starts a backup, on restart of the service or only on installation of the client ? Leading to the last question .....
3) If NBU has been installed and running on a client and that client is then configured to be a DFS node does/should NBU be re-installed to ensure the client is then treated correctly ?
The DFSR article
The reason for all the questions we have a couple of DSFR servers that NBU is backing up as normal Windows clients and is not doing the usual "Shadow Copy Components" backups normally expected with these type of servers.
Just visiting, and saw your query, so thought I would give some in site.
DFSR is a service setup on a windows server.
you can tell if it has it by looking for the DFS Management in Administrative tools from the start menu.
When this DFSR is set up it does create registry entries.
you do not need to do anything special for Netbackup to see that it has DFSR - it sees that when the backups start. A normal backup - say backing up the E drive - that as a DFSR directory on it will skip the DFSR directory when backing up the E drive. You can see this bay going to the BAR and looking at the E drive, you will NOT see your DFSR dir.
The SCC job will pick it up by default - and you can see that in the BAR ( see the article you referenced).
The article is good but leaves out one important point.
If you have multiple DFSR dirs with the same name it does not go so smooth if you try setting up the special policy
here you have 3 dfsr directory with the same name 'mydfsr'
if you specify the special backup selection to get mydfsr it will only get the first one and not the others.
but if you specify the SCC dir above mydfsr it will get them all but will have the name and you have to look at each one to figure out where which dir you are really wanting to do the restore from.
so just beware of that when setting up any special policies.
JH, Thanks for responding I thought everybody was ignoring me.
I've got all that and do have successfull DFS backups on most of our DFS servers. However you'll see I'm trying to dive a bit deeper into how NBU detects and treats a client as DFS.
It's not that I cannot find the DFS data under the SCC part of the client in the BAR it's not there. The DFS host is being treated by NBU as a normal client and backing up the DFS files as if they were a standard drive.
i.e. When I look in the BAR under SCC it only has "System Service" the "User Data" is not there, when I look under the drive Ident the data has been backed up. This would normally get excluded when it's treated as a DFS client.
did you first add the servers, or have you taken over for someone else who set this up.
A lot of people, me included, could not get the large servers to backup the DFSR data in a timely manner.
Had one server that took 4 days in a single stream.
and because I had mulit dfsr dirs with the same name the braking into different streams did not work.
So many have gone with the first solution to the DFSR issue.
Turn DFSR off before the backup starts. Turning this off caused the drive to get backed up like a normal drive, and the the SCC job does NOT back it up.
This is done by using the bpstart and bpend scripts.
so for me it was
a policy just for my big dfs server.
on that server I made a bpstart and bpend to match that server policy
bpstart would turn off the dfsr - the backup would then work like a normal server.
when the job finished the bpend would turn it back on.
now you get to the issue of multi streams.
it would run the bpstart for each stream, and the bpend for each stream.
did not cause me any issues, but some people wrote into the script the testing of how many streams so it only ran each once.
then once dfsr is turned back on, it they works at getting caught back up.
the original doc was 290900, but this one also has the info, you have to create a registry entry as well as turn dfsr off.
so look to see if you have this bpstart and bpend and the registry entry on that server,
that would explain why it is getting it as a normal backup.
or DFSR us just not running on that server.
Yes I inherited the server and did'nt set it up originally. However it's a V18.104.22.168
To clear up one of my queries I completely un-installed NBU from the server yesterday and did a fresh re-install. It still doesn't work.
I have checked the registry to see if anything was left behind but it cleared everything out and the registry keys for BEDS are now Veritas|NetBackup|BEDS..... not Veritas|Symantec|BEDS showing that it's a V7 install. So it's not being forced to do the backup the old way.