1. Yes.
Per your images, it appears the system is using the default upload vault and it resides inside the Windchill load point. The master vault has a read-only root folder mount on the E drive and a read-write root folder mount on the F drive? The clearer picture would be the mount paths from Site > Utilities > Vault Configuration > Site > Master > Root Folders.
Provided drive letters and paths are not changing, you can just change the host names and not worry about path mappings.
### Vault Host Settings ###
source.fv.hostname.0={(as DB user) select hostname from FvHost where hostname not in ('masterDefault');}
target.fv.hostname.0={match syntax of source (server name or FQDN)}
Observations...
A. You can also skip file vault rehosting in the rehosting script and just do it by hand through the the Site > Utilities > Vault Configuration page. If you are doing it just once, do it by hand (3 minutes effort). If you are planning to rehost the dev system regularly, invest the time to use the rehosting script. Really, in your situation, assuming all the drives and paths don't change, all you are doing is renaming the master site's host. In Dev, after finishing the rehosting script, select Site > Utilities > Vault Configuration > Sites > Master > Hosts > double click on FQDN and rename it to the Dev server's name.
B. Always remove unreferenced files from production before cloning the database and file vaults to reduce the amount of content to copy. The database and file vaults must be in sync for a clean rehosting.
C. Using the default upload vault is a good practice. Leaving the default upload vault mapped to the OOTB default location is not recommended. PTC's perspective is they "own" the Windchill load point and it is their prerogative to change it at any time through software updates and upgrades. They have never moved the OOTB file vaults location and likely won't. But we should adhere to their perspective and place the file vaults somewhere outside of the Windchill_12.0 folder like D:\PTC\Vaults. Using the OOTB file vaults mappings also impacts temporary backup restore point copies of the Windchill load point. The current configuration unnecessarily includes however much content is in the default upload vault.
D. For an identical clone (what you are doing), all the file vaults need to be cloned to the Dev environment. Otherwise, Windchill will throw errors when a developer tries to retrieve data.
E. If disk space is an issue, the rehosting script can perform a partial vaults content rehosting, but it is terribly tedious to setup. I've used it before and relocated all my Development file vaults to D:\PTC\Vaults, eliminating additional vault partitions: E and F. Windchill needs the full folder structure for each root folder. The content files are only necessary when attempting to open content objects. The greatest challenge is copying administrative content objects like templates and other site/org level content. The entire process is just messy.
2. Through the Windows UI, use robocopy.
First, remove unreferenced files from production. Then run Robocopy.
Minimize robocopy logging will product the fastest robocopy command to clone Windchill file vault data .
robocopy /mir /mt:128 /ns /nc /ndl /nfl /np /r:1 /w:1 /log:C:\temp\robocopy.log {source path} {target path} /xd .unreferenced MOUNT_VALIDATION_DATA
IT can do full server clones and may have block-level copy capabilities (e.g. restore from backup) that would be faster for a single volume. But it usually takes longer to get a response out of IT than it does to run Robocopy to completion. Depending on your infrastructure, robocopy can clone 80 GB in just a few minutes and 2 TB in less than an hour.
