Vault Management for PRODUCTION and TEST systems?

I did a bunch of research on this several years ago and while it was very simple to do this on the unix/linux operating systems, it was much more difficult on Windows.  Storage space is cheap enough, and our vault is small enough (750 GB or so) that I just decided to copy the vault from one system to the other.  I can fire off a robocopy script and only the new/changed stuff actually gets copied.  Doesn't usually take too long.

If your vault is very large and/or you don't have sufficient space, I'd take a look at sharing the drive read-only at the VM level (assuming you're using VMware or something similar.)

Officially Windchill doesn't support mount of same folders to multiple Windchill environment.

But for your own risk, you can try, make sure that on the OS level test system has only read access to the shared production Vault folder. For the test system Vault status will be Invalid.

I would suggest you post this request in https://community.ptc.com/t5/Windchill-Ideas/idb-p/WindchillIdeas.

Also to reduce the cost of Vault storage you can use the AWS S3 bucket.

A few places I've worked we have shared the vault as read only to the test and then mounted as read only. This worked for Windows server and AIX

The Achilles heel of file vaults sharing between production and test systems is 'Remove Unreferenced Files'.  We can't hide/disable the option from the UI and it is necessary to periodically recover file vaults disk space in production.  So there needs to be at least two copies of the file vaults (production and non-production). Otherwise, the non-production systems need to be recloned/rehosted each time Remove Unreferenced Files is run against production.  There must also be a hard rule to never run Remove Unreferenced Files in a non-production system, or at least never against the first master root folder.

Sharing among multiple test systems is possible/practical.  As you mentioned, at the time of cloning/rehosting, mark the master root folder as read-only and create a second root folder (i.e. active) for that system's unique content files.  Going forward, never run Remove Unreferenced Files against the first master root folder in any of the non-production systems.  Additional file vaults rehosting steps may be needed if using the defaultUploadVault.

Going another direction...  NetApp and other hardware vendors offer block level cloning/file de-duplication capabilities.  These solutions don't actually clone the full set of file vaults.  Instead, they snapshot the LUN (disk) and track changes going forward or they point multiple operating systems to the same file on disk.  I've seen Windchill systems cloned in minutes using these types of technologies.  Unfortunately, they aren't free and almost never on IT's radar when scoping hardware for Windchill environments.

You can actually mount your production vault to a test system in read-only mode. The only issue you'll face is that mount validation will not work on a read-only vault (if it's controlled by the OS and not by the application), so you'll have to manually update the mount status to valid in the database in case it switches to invalid. We're using this method for a while now to save 60tb+ storage space. No issues found so far.