Need to replace DAS that DFS data sits on.

I need to replace the physical hardware that the DFS data sits on. The
server will stay, just new direct attached storage that has more space. I
cannot find any documentation on how to properly handle this without causing
DFSR to see everything as needing to be replciated. What would be the
supported option:

1. Add the new DAS unit, with the old one still attached and hosting the
data. Then create new shares and new links on new unit and let DFS replciate
the data? Final step, delete the old DAS target in DFS management?

2. Stop DFSR and copy everything from one DAS to the other? Remove old,
restart DFSR service? (This may take a long time...over 1 TB of small files
to copy.)

3. Ghost and reimage the DAS storage? (same thing...expect this to take a
long time.)

4. An option i am missing?

I need to accomplish the following:

1. Introdce new hardware.
2. Have minimal downtime (cant be hours).
3. Prevent replication of all DFS shared folders. (i.e. DFS thinking that
there's 1 TB of new files and they all need to be copied again, thus killing
performance, bandwidth and service to the end user.)

Appreicate any assistance.

please reply to chris(dot)rapp(dot)ctr@autec(dot)navy(dot)mil

Set up a robocopy script to copy the data from the server to be removed to
the new DAS. I would create a robocopy log to be sure everything gets
copied. Once done, delete the replication group containing the server you
want to replace, then recreate the replication group so it points to the new
DAS.
Robocopy can be ran periodically during the week to keep things up to date,
deleting and recreating the replication group will take only a couple of
minutes. By prestaging the data using robocopy DFSR will not try to
replicate everything.

If you prestage the new DAS using the robocopy script during the week, you
can delete and recreate the replication group in a matter of minutes on
Friday evening.


hth
DDS


"AUTEC_chris" <> wrote in message
news:3EBC5DC6-F051-4665-A5C0-...
>
> I need to replace the physical hardware that the DFS data sits on. The
> server will stay, just new direct attached storage that has more space. I
> cannot find any documentation on how to properly handle this without
> causing
> DFSR to see everything as needing to be replciated. What would be the
> supported option:
>
> 1. Add the new DAS unit, with the old one still attached and hosting the
> data. Then create new shares and new links on new unit and let DFS
> replciate
> the data? Final step, delete the old DAS target in DFS management?
>
> 2. Stop DFSR and copy everything from one DAS to the other? Remove old,
> restart DFSR service? (This may take a long time...over 1 TB of small
> files
> to copy.)
>
> 3. Ghost and reimage the DAS storage? (same thing...expect this to take
> a
> long time.)
>
> 4. An option i am missing?
>
> I need to accomplish the following:
>
> 1. Introdce new hardware.
> 2. Have minimal downtime (cant be hours).
> 3. Prevent replication of all DFS shared folders. (i.e. DFS thinking that
> there's 1 TB of new files and they all need to be copied again, thus
> killing
> performance, bandwidth and service to the end user.)
>
> Appreicate any assistance.
>
> please reply to chris(dot)rapp(dot)ctr@autec(dot)navy(dot)mil

Your response has "server" and "das" used to reference the same thing. We're
really referencing one server that has a direct attached storage (i.e. RAID)
unit that has run out of space. It sounds like your suggestion is to coneect
both the old and the new RAID (that has more space) at the same time,
Robocopy/RichCopy the data over, stop DFSR service, delete the Replication,
Recreate the replication pointing to the new RAID. DFS will see the data and
not replicate it, but I would guess that the scan of this much data will take
quite a bit of time.

I also suppose removing old and adding new might be best thus keeping the
shares the same, not having to recreate them.

Did i understand you correctly?

Could I add the new RAID to the exisitng server, place new shares on it and
add it to the replication group? Thus it would have to replicate within the
server essentially doing what RoboCopy/RichCopy is doing. Is that supported?


"Danny Sanders" wrote:

> Set up a robocopy script to copy the data from the server to be removed to
> the new DAS. I would create a robocopy log to be sure everything gets
> copied. Once done, delete the replication group containing the server you
> want to replace, then recreate the replication group so it points to the new
> DAS.
> Robocopy can be ran periodically during the week to keep things up to date,
> deleting and recreating the replication group will take only a couple of
> minutes. By prestaging the data using robocopy DFSR will not try to
> replicate everything.
>
> If you prestage the new DAS using the robocopy script during the week, you
> can delete and recreate the replication group in a matter of minutes on
> Friday evening.
>
>
> hth
> DDS
>
>
> "AUTEC_chris" <> wrote in message
> news:3EBC5DC6-F051-4665-A5C0-...
> >
> > I need to replace the physical hardware that the DFS data sits on. The
> > server will stay, just new direct attached storage that has more space. I
> > cannot find any documentation on how to properly handle this without
> > causing
> > DFSR to see everything as needing to be replciated. What would be the
> > supported option:
> >
> > 1. Add the new DAS unit, with the old one still attached and hosting the
> > data. Then create new shares and new links on new unit and let DFS
> > replciate
> > the data? Final step, delete the old DAS target in DFS management?
> >
> > 2. Stop DFSR and copy everything from one DAS to the other? Remove old,
> > restart DFSR service? (This may take a long time...over 1 TB of small
> > files
> > to copy.)
> >
> > 3. Ghost and reimage the DAS storage? (same thing...expect this to take
> > a
> > long time.)
> >
> > 4. An option i am missing?
> >
> > I need to accomplish the following:
> >
> > 1. Introdce new hardware.
> > 2. Have minimal downtime (cant be hours).
> > 3. Prevent replication of all DFS shared folders. (i.e. DFS thinking that
> > there's 1 TB of new files and they all need to be copied again, thus
> > killing
> > performance, bandwidth and service to the end user.)
> >
> > Appreicate any assistance.
> >
> > please reply to chris(dot)rapp(dot)ctr@autec(dot)navy(dot)mil
>
>
> .
>

> Your response has "server" and "das" used to reference the same thing.
> We're
> really referencing one server that has a direct attached storage (i.e.
> RAID)
> unit that has run out of space. It sounds like your suggestion is to
> coneect
> both the old and the new RAID (that has more space) at the same time,
> Robocopy/RichCopy the data over, stop DFSR service, delete the
> Replication,
> Recreate the replication pointing to the new RAID. DFS will see the data
> and
> not replicate it, but I would guess that the scan of this much data will
> take
> quite a bit of time.


You got it correct. If you were to cut over on a Friday I'm guessing the
scan of the data would be done by Monday.



> Could I add the new RAID to the exisitng server, place new shares on it
> and
> add it to the replication group? Thus it would have to replicate within
> the
> server essentially doing what RoboCopy/RichCopy is doing. Is that
> supported?

If I'm following you right, I think you can. Using DFSR to replicate the
data to the new RAID would take quite a while. I would suggest using
robocopy.


hth
DDS


"AUTEC_chris" <> wrote in message
news:FB06CA7F-921C-4C30-A21B-...
> Your response has "server" and "das" used to reference the same thing.
> We're
> really referencing one server that has a direct attached storage (i.e.
> RAID)
> unit that has run out of space. It sounds like your suggestion is to
> coneect
> both the old and the new RAID (that has more space) at the same time,
> Robocopy/RichCopy the data over, stop DFSR service, delete the
> Replication,
> Recreate the replication pointing to the new RAID. DFS will see the data
> and
> not replicate it, but I would guess that the scan of this much data will
> take
> quite a bit of time.
>
> I also suppose removing old and adding new might be best thus keeping the
> shares the same, not having to recreate them.
>
> Did i understand you correctly?
>
> Could I add the new RAID to the exisitng server, place new shares on it
> and
> add it to the replication group? Thus it would have to replicate within
> the
> server essentially doing what RoboCopy/RichCopy is doing. Is that
> supported?
>
>
> "Danny Sanders" wrote:
>
>> Set up a robocopy script to copy the data from the server to be removed
>> to
>> the new DAS. I would create a robocopy log to be sure everything gets
>> copied. Once done, delete the replication group containing the server you
>> want to replace, then recreate the replication group so it points to the
>> new
>> DAS.
>> Robocopy can be ran periodically during the week to keep things up to
>> date,
>> deleting and recreating the replication group will take only a couple of
>> minutes. By prestaging the data using robocopy DFSR will not try to
>> replicate everything.
>>
>> If you prestage the new DAS using the robocopy script during the week,
>> you
>> can delete and recreate the replication group in a matter of minutes on
>> Friday evening.
>>
>>
>> hth
>> DDS
>>
>>
>> "AUTEC_chris" <> wrote in message
>> news:3EBC5DC6-F051-4665-A5C0-...
>> >
>> > I need to replace the physical hardware that the DFS data sits on. The
>> > server will stay, just new direct attached storage that has more space.
>> > I
>> > cannot find any documentation on how to properly handle this without
>> > causing
>> > DFSR to see everything as needing to be replciated. What would be the
>> > supported option:
>> >
>> > 1. Add the new DAS unit, with the old one still attached and hosting
>> > the
>> > data. Then create new shares and new links on new unit and let DFS
>> > replciate
>> > the data? Final step, delete the old DAS target in DFS management?
>> >
>> > 2. Stop DFSR and copy everything from one DAS to the other? Remove
>> > old,
>> > restart DFSR service? (This may take a long time...over 1 TB of small
>> > files
>> > to copy.)
>> >
>> > 3. Ghost and reimage the DAS storage? (same thing...expect this to
>> > take
>> > a
>> > long time.)
>> >
>> > 4. An option i am missing?
>> >
>> > I need to accomplish the following:
>> >
>> > 1. Introdce new hardware.
>> > 2. Have minimal downtime (cant be hours).
>> > 3. Prevent replication of all DFS shared folders. (i.e. DFS thinking
>> > that
>> > there's 1 TB of new files and they all need to be copied again, thus
>> > killing
>> > performance, bandwidth and service to the end user.)
>> >
>> > Appreicate any assistance.
>> >
>> > please reply to chris(dot)rapp(dot)ctr@autec(dot)navy(dot)mil
>>
>>
>> .
>>