Community
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

UnReplicate Files

UnReplicate Files

Once a file\folder is replicated from one site to another, the challenge is to unreplicate.

 

Currently there appears to be 2 options to unreplicate a file.

1) In the ADMS Console, edit the "Replicated Folder" and untick the folder that you want to unreplicate, then delete the file(s) from the vault, re-add it to the "unreplicated" folder. This will prevent the file from being replicated in future

2) Disable the Vault on the site, delete the local filestore, Enable it. This can be dangerous if the file is not present on at least one other site. Its OK if you know all files are replicated to at least one site.

 

The wish is to untick a folder in the "Replicated Folder" dialogue for that site and for the ADMS Console to check to see if that file appears on another site before allowing the Admin to unreplicate the folder. Once the check is completed, the files in the selected folder are removed from that sites filestore.

 

If you think this would be a useful enhancement, add a comment to this thread...

12 Comments
ihayesjr
Community Manager
Status changed to: Accepted
 
ericlynch7405
Contributor

This would be extremely helpful. We have limited storage capacity at several of our AVFS sites and a very large Vault(1TB+). If someone manually replicates a top level folder to their site, we lose GB's worth of storage at that site with no way of recovering it unless we delete the entire filestore. Deleting the filestore is messy and all info that should be replicated has to be re-replicated.

elliskit
Explorer

I agree that this would be a very useful option. It just makes sense that, if you can choose a file\folder to be replicated, you should have an option to un-replicate.

tgreenland
Community Visitor

this would be really useful

Edoardo.Baima
Enthusiast

Imho it would facilitate Vault Administrators in their task, enhance productivity of the companies, reduce admin user-errors and will make replicated environments more reliable.

Thanks

ihayesjr
Community Manager
Status changed to: Future Consideration
 
abt102
Participant

Absolute Notwendigkeit bei kleineren Standorten.

 

 

abt102
Participant

Ergänzung: Aus Sicherheitsaspekten auch sehr wichtig.

ihayesjr
Community Manager

@abt102 What safety concerns would this solve?

abt102
Participant

 

@ihayesjr 

 

Der Aspekt Sicherheit kommt dann zum Tragen, wenn der Zugriff auf den Vault Abo-Server mit seinem Filestore für externe Firmen für ein begrenztes Projekt zur Verfügung gestellt wird. Nach dem Abschluss des Projekts kann zwar die Replikation der Projektordner aufgehoben werden, aber die Dateien sind immer noch im Vault Filestore vorhanden und stehen damit für Zugriffe beim nächsten Projekt offen. Ein nicht autorisierter Zugriff mit dem entsprechenden Wissen zum Filestore und den Vault Datenbank Tabellen – damit Datendiebstal - ist somit möglich. Die Sicherheit von firmenkritischen Daten ist somit nicht gewährleistet. Aktuell ist dieses Problem im laufenden Betrieb nur mit einem erheblichen Arbeitsaufwand außerhalb der normalen Arbeitszeiten möglich (jeweils manuell Site löschen, Filestore löschen, Site neu erstellen und Ordner neu replizieren), der für die betroffenen Firmen inakzeptabel ist.

 

Ein clevere Lösung hierfür wäre der originäre Vorschlag des "Unreplicate" mit automatischer Löschung der betroffenen Dateien (inkl. aller Versionen) aus dem Filestore des Abo-Servers.

 

English translation:

The security aspect comes into play when access to the Vault subscription server with its filestore is made available to external companies for a limited project. After the project is complete, the replication of the project folder can be canceled, but the files are still in the Vault Filestore and are therefore available for access in the next project. Unauthorized access with the appropriate knowledge of the filestore and the Vault database tables - thus data theft - is possible. The security of company-critical data is therefore not guaranteed. Currently, this problem is only possible during ongoing operations with a considerable amount of work outside of normal working hours (each time manually deleting sites, deleting filestores, recreating sites and replicating folders), which is unacceptable for the companies concerned.

 

A clever solution for this would be the original proposal of "Unreplicate" with automatic deletion of the affected files (including all versions) from the filestore of the subscription server.

ihayesjr
Community Manager

@abt102 

The file store is only accessible to any users that have direct access to the server where the file store is located. The user is usually a server administrator. Once the project is complete, you should remove the Read permission from any user who should no longer see the files. If they cannot see the files in the Vault client, they cannot download the files even if they still exist on the file store.  If there are concerns about the security of the files, should the file store ever be located on an external server?  If they are located on the external server, the files could be stolen at any time.

Tobias-42
Explorer

Option to purge the file stores on Subscriber-Vaults. We only need the PDF’s /DXF (attachments) and the latest version of the files on the subscribers, everything else the user can get again from the publisher if needed. An option like the purge function but only for the file store would be useful to reduce the size on the subscriber sites.

Tags (3)

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Autodesk Design & Make Report