I've actually been researching this issue a lot lately, in an effort to figure out the best/most practical way of backing up DFS replicated data.
A big disadvantage of backing up DFS data via the Shadow copy components, if you are running Backup Exec 11 or 10 is that you CANNOT redirect data during restores. In v. 12 and above you can according to the tech docs.
If you back up DFS user data through the shares as Mitch pointed out you can redirect. The only drawback to this method is that you lose security attributes for files and folders. You are also bypassing the remote backup agent, which would probably result in a reduction in performance (compared to backing up files normally via the agent).
A third option is to stop the DFS service on the remote server via the Pre/Post job configuration page. Basically you issue a pre command of “NET STOP DFSR” followed by a “NET START DFSR” as a post command when the job finishes. This will allow you backup the replicated data directly via the normal volume level backup resulting in quicker backups, retention of security information, and allows for restore redirects. The downside is that stopping the DFS service results in loss of DFS data used for calculating which files to replicate and to which sites. Basically it will slow down the replication process. A Microsoft tech support agent recommended against this option.
We’re currently investigating a fourth option, where we disable communication between the DFS replicating hosts. In theory this should allow us to backup the data at the volume level without the problems of the other methods. But we have not had a chance to test this out yet.
For more details see:
http://seer.entsupport.symantec.com/docs/304981.htm,
http://seer.entsupport.symantec.com/docs/296168.htm, and
http://seer.entsupport.symantec.com/docs/309537.htm