Quantcast
Channel: File Services and Storage forum
Viewing all articles
Browse latest Browse all 13565

Storage migration 2008 R2 - DFSR DB implications

$
0
0

Hello,

I have storage migration which requires some DFSR changes.  I am unsure of how these changes will affect the DFSR DB and would like to get some thoughts. It’s is a bit complicated and hope this makes sense.  This applies to Win 2008 R2 Sp1.

Here is the scenario.  We have multiple fileservers for around 1500 users at 1 location. These servers store user H drive data and replicate to a DFS replica server in our DR site.

The 4 host (live) site servers are for users and broken down by last name.

Server1:  UsersA-F

Server2 : UsersG-L

Server3:  UsersM-R

Server4:  UsersS-Z

There are only 2 replica site servers.  So shares UsersA-F and UsersG-L replicate to a single server with separate drives for each.

The issue is that the host site drives are almost full. I have a new SAN mounted drives and plan to split off the data as such.

Server1: D:\UsersA-F becomes D:\UsersA-C and K:\UsersD-F. Server2: F:\UsersG-L becomes F:\UsersG-I and L:\UsersJ-L

The replica site has 2 new drives and will now store 4 drives of replicated data. UsersA-C, UsersD-F.  UsersG-I, UsersJ-L.

I will just focus on 1 server for this – UsersA-F on server1.  I have plenty of experience with Robocopy preseed and checking hashes.

Here are my high level steps:

  1. Copy data to new drives using Robocopy Preseed command (host and replica side)
  2. Check File hashes
  3. Re-sync as needed (using Robocopy /xo switch)
  4. Share new root folders (on new drives)
  5. Delete existing Replication Group(s)
  6. Un-share, re-name, re-share existing root shares – UsersA-F renamed to UsersA-C
  7. Configure new DFS links/targets etc
  8. Create new replication groups(s)
  9. Once replication is happy delete un-needed (redundant data) from each drive

-         Delete D-F data from existing drive so it only holds A-C data

-         Delete A-C data from new drive so that it only holds D-F data

The part that I’m unsure about is #6 - Un-share, re-name, re-share existing root shares. 

The existing share is UsersA-F.  I will have to re-name this share to UsersA-C which means I have to un-share it first. Then re-name, and then re-share.  I have to do similar work on the replica side. I’m worried how this will affect the existing DFSR Database?  When I create the new replication group, will it do the initial sync (check file hashes) like normal and then catch up on replication or will it get confused since the root is has been un-shared and re-named? The DFSR Database will see new replicated folders (A-F replaced by A-C and D-F). Will it just re-replicate everything over?  That is my big worry.

Thank you!

 

 


Viewing all articles
Browse latest Browse all 13565

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>