Moving a shared folder from one drive to another retaining all permissions.

[kennysarmy]

I have a VM Running Server 2019.

 

It has a D:\ drive of almost 2 Tb which only has 50 Gb remaining.

 

I've created a new empty 1 Tb E:\ drive.

 

I wish to move the folder D:\data\Resources to the new drive, so it will become E:\data\Resources

 

The folder D:\data\Resources is shared on the server with the share name resources$ and permissions are set to allow various people and groups to save or not to folders within.

 

Are there any robocopy experts out there who can confirm how to do the copy so that all permissions are retained?

 

Once copied would it then just be a simple case of unsharing the original location and resharing the new one? Or would you remove the share first, reboot the server to ensure no one is updating any files?

It would be my intention to do the copy over the Bank Holiday Weekend when less students/staff will be needing access to the data.

 

Cheers.

[kennysarmy]

I've found this post on the Internet...

 

Here's the command I typically use when I want to retain all permisions, ownership and timestamps of the entire folder structure and data:

 

robocopy source destination /E /ZB /DCOPY:T /COPYALL /R:1 /W:1 /V /TEE /LOG:Robocopy.log

Here's what the switches mean:

source :: Source Directory (drive:\path or \\server\share\path).

destination :: Destination Dir (drive:\path or \\server\share\path).

/E :: copy subdirectories, including Empty ones.

/ZB :: use restartable mode; if access denied use Backup mode.

/DCOPY:T :: COPY Directory Timestamps.

/COPYALL :: COPY ALL file info (equivalent to /COPY:DATSOU). Copies the Data, Attributes, Timestamps, Ownser, Permissions and Auditing info

/R:n :: number of Retries on failed copies: default is 1 million but I set this to only retry once.

/W:n :: Wait time between retries: default is 30 seconds but I set this to 1 second.

/V :: produce Verbose output, showing skipped files.

/TEE :: output to console window, as well as the log file.

/LOG:file :: output status to LOG file (overwrite existing log).

[Cache]

This is the command I used recently for migrating our file server:

 

Mapped the drive as z: first

 

robocopy z:\shared e:\shared /copyall /e /r:0 /dcopy:t /secfix /purge

 

I ran it a couple of times to prestage it before the final switchover, hence the purge and secfix.

[ricki]

I have a VM Running Server 2019.

 

It has a D:\ drive of almost 2 Tb which only has 50 Gb remaining.

 

I've created a new empty 1 Tb E:\ drive.

 

I wish to move the folder D:\data\Resources to the new drive, so it will become E:\data\Resources

 

The folder D:\data\Resources is shared on the server with the share name resources$ and permissions are set to allow various people and groups to save or not to folders within.

 

Are there any robocopy experts out there who can confirm how to do the copy so that all permissions are retained?

 

Once copied would it then just be a simple case of unsharing the original location and resharing the new one? Or would you remove the share first, reboot the server to ensure no one is updating any files?

It would be my intention to do the copy over the Bank Holiday Weekend when less students/staff will be needing access to the data.

 

Cheers.

Hi would you not be better using DFS to sync the two folders.

https://docs.microsoft.com/en-us/windows-server/storage/dfs-namespaces/replicate-folder-targets-using-dfs-replication

 

Richard

[djm968]

RoboCopy $srcDoc $dstDoc /E /ZB /DCOPY:T /COPYALL /R:1 /W:1 /V /TEE /log+:$logFile

 

Where $srcDoc is your source folder and $dstDoc is your destination folder. This will also output results to the log file specified in $logfile if you want.

 

I would test the command on a small selection of files/folders first.

[chaplic]

to answer the last bit of your question, do the robocopy (at least) twice

 

First time well ahead of planned migration to get the bulk of data across and highlight any iffy permissions and similar problems. I would also use /mt:64 to multi thread it and expect the odd virus alert.

 

 

Then declare an outage on old, at the share level make it read only and kill and open connections, and do the robocopy again (it will only copy files changed).

 

I would then change the old share to hidden with a different for a few days to stop any 'ooh my files are missing' panic by having it easily accessible to the client.

[kennysarmy]

to answer the last bit of your question, do the robocopy (at least) twice

 

First time well ahead of planned migration to get the bulk of data across and highlight any iffy permissions and similar problems. I would also use /mt:64 to multi thread it and expect the odd virus alert.

 

 

Then declare an outage on old, at the share level make it read only and kill and open connections, and do the robocopy again (it will only copy files changed).

 

I would then change the old share to hidden with a different for a few days to stop any 'ooh my files are missing' panic by having it easily accessible to the client.

 

 

Done the work today - all seemed to go smoothly

[TwistedHelixis]

Bit late, but could you not just expand the size of the D drive?

[kennysarmy]

Bit late, but could you not just expand the size of the D drive?

 

Fraid not, it was 2 Tb and at it's limit (MBR)