S
ScottyDM
Hi Hank;
I assume you are using DFS to get at the FRS (replication)
feature of Windows Server. Pretty darn good for a
Unix/Linux guy!
The purpose of DFS is to pull a bunch of scattered shares
(public volumes) into one place and arrange them logically
so users can find them. For this to work as intended, the
users will mount the DFS root folder as a network drive.
FRS can run within this environment so you can create
locally replicated data sets across the enterprise (the
main idea being that you save WAN bandwidth between branch
offices). It does not sound like you are wanting to use
DFS/FRS this way -- I don't use it this way either. ;-)
What you can do is have the user *not* mount the DFS root
folder, but to mount the original share just as they've
always done. This way the user forces which physical
machine they read/write to (this of course, defeats the
purpose of DFS, but so what). You can still have your
DFS/FRS replicated folders set up. To exclusively access
the replicated volume, just mount the share of the backup
machine.
There is a problem with this entire approach though: If
by "clobbered the machine" you mean the boss pretty much
trashed the whole volume (perhaps he reformatted it), then
you'll be safe. Such a tramatic event will break the
replication process and the files will remain safe on the
backup machine. But if you mean he deleted the files, then
in this case the replication process will dutifully delete
the files on the backup machine as well.
This kind of comes down to the same issues as when RAID
works well -vs- when backup works well (FRS being a sort
of RAIDish kind of service). Oh yea, FRS is *real slow*
compared to most kinds of mirroring, this might be a
feature. Also defrag is *seriously* toxic to FRS and the
two processes will "fight" each other, burn up a lot of
disk bandwidth, flood the network with unnecessary
replication traffic, and in rare cases overwrite new files
with older versions. MS claims to have fixed this in
Windows 2003 Server. MS also claims that FRS is *not* a
good idea for rapidly changing data or data with multiple
authors. It is a "master/master" type replication and
there is NO WRITE LOCKING. I look at FRS as "the Notepad
of file mirroring", that about says it all.
I use DFS/FRS to mirror websites from my public server
back to my LAN server, which has a big fat fast tape
drive. Then I back them up to tape. Also if the public
server dies I can diddle my DNS and the firewall, then
turn on IIS and FTP on the LAN server and bring the
functionallity of the public server back online.
I suspect though that DFS/FRS is probably not quite the
right approach for your particular problem. Can you do
backup to hard disk on a seperate machine using your
backup software? (Then do backup 7 days a week.) Maybe
incrementals to hard disk daily and full to tape once per
week.
ScottyDM
I assume you are using DFS to get at the FRS (replication)
feature of Windows Server. Pretty darn good for a
Unix/Linux guy!
The purpose of DFS is to pull a bunch of scattered shares
(public volumes) into one place and arrange them logically
so users can find them. For this to work as intended, the
users will mount the DFS root folder as a network drive.
FRS can run within this environment so you can create
locally replicated data sets across the enterprise (the
main idea being that you save WAN bandwidth between branch
offices). It does not sound like you are wanting to use
DFS/FRS this way -- I don't use it this way either. ;-)
What you can do is have the user *not* mount the DFS root
folder, but to mount the original share just as they've
always done. This way the user forces which physical
machine they read/write to (this of course, defeats the
purpose of DFS, but so what). You can still have your
DFS/FRS replicated folders set up. To exclusively access
the replicated volume, just mount the share of the backup
machine.
There is a problem with this entire approach though: If
by "clobbered the machine" you mean the boss pretty much
trashed the whole volume (perhaps he reformatted it), then
you'll be safe. Such a tramatic event will break the
replication process and the files will remain safe on the
backup machine. But if you mean he deleted the files, then
in this case the replication process will dutifully delete
the files on the backup machine as well.
This kind of comes down to the same issues as when RAID
works well -vs- when backup works well (FRS being a sort
of RAIDish kind of service). Oh yea, FRS is *real slow*
compared to most kinds of mirroring, this might be a
feature. Also defrag is *seriously* toxic to FRS and the
two processes will "fight" each other, burn up a lot of
disk bandwidth, flood the network with unnecessary
replication traffic, and in rare cases overwrite new files
with older versions. MS claims to have fixed this in
Windows 2003 Server. MS also claims that FRS is *not* a
good idea for rapidly changing data or data with multiple
authors. It is a "master/master" type replication and
there is NO WRITE LOCKING. I look at FRS as "the Notepad
of file mirroring", that about says it all.
I use DFS/FRS to mirror websites from my public server
back to my LAN server, which has a big fat fast tape
drive. Then I back them up to tape. Also if the public
server dies I can diddle my DNS and the firewall, then
turn on IIS and FTP on the LAN server and bring the
functionallity of the public server back online.
I suspect though that DFS/FRS is probably not quite the
right approach for your particular problem. Can you do
backup to hard disk on a seperate machine using your
backup software? (Then do backup 7 days a week.) Maybe
incrementals to hard disk daily and full to tape once per
week.
ScottyDM