Exporting the Registry file probably would work, especially for the small number of file servers you need to recover. I used that as my method for a large number of file server migrations that I have done in the past. (Now it's mostly on NetApp NAS, so we don't have that luxury.)
I'm sure the replicated SAN works fine for a file server DR solution, but none of the Windows servers we restore in DR testing are file servers. If it's a SQL server, domain controller, application server, etc. it will take more than just the data itself on a disk to do a recovery. We restore about 40 servers, including 12 Windows, in a site 250 miles away and we have three days to do it. I'm curious about the SAN replication. How far apart are the sites? Is the replication done over Ethernet? We do have some apps that need to be available immediately if our data center is down. For those servers we use vSphere Replication, but that is over Ethernet to a site about a mile away. Eventually we'll probably spring for the cost of replication to a remote site for all servers that need to be recovered in a DR scenario, since it keeps getting harder each year to reach our recovery time requirements. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Leone Sent: Thursday, August 07, 2014 3:24 PM To: [email protected] Subject: Re: [NTSysADM] Fwd: Saving share permissions, and re-applying them On Thu, Aug 7, 2014 at 3:13 PM, Charles F Sullivan <[email protected]> wrote: > I have always just exported this Reg key: > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shar > es Of course you could easily script the export using reg.exe in a > batch file. > > As long as the file server at both ends is Windows, as opposed to say > a NAS or SAMBA Server, I don't think it should matter what version of > Windows the source and target are. No, they will be Windows servers. A 1 node cluster, actually, as the DR for the 2 node production cluster. > This is awfully simple, but it has always worked for me. Just > remember to restart the Server service after you import the Reg file. > > In my DR testing I don't have to do anything like this, to be honest, > since the backup software includes the System State. True, but we won't be running restores. We have 2 sites, and SAN replication set up between them So the data on disk exists at the other site already. We would need to fire up the Windows boxes there; rename them to have the production server name; mount the SAN volume as disk drive. Import the share settings. And no users should be the wiser. They still see a server with the same name; the share permissions are the same as before; the NTFS folder permissions are already there on the disk. If you can afford it, this is the way to do DR. :-) No long wait for restores. I have 1 file server that has something like 4TB of data and 3M+ files (user folders and departmental shares). That would take forever to restore - open, write, close, verify all those small files ...
