So long as users don't have destroy rights, you can recover files deleted by mistake through the 'deleted items' tab when you select properties through a right click of a folder or vault icon. For users who do have destroy rights, I would avoid using shift-delete (destroy) in the first instance, that way if the file is needed they can be restored.
I personally do no like the rollback feature. I would avoid checking out files and then getting older versions as well, if you are on revision 5 of a part and want to restore its geometry to revision 2, it will overwrite the revision related info on the datacard.
I don't give users delete or destroy rights. I only give them the option to rename in our first state. They have to put DELETEME_ as a prefix for the file and once a week I go through and delete the files. I still don't destroy the files. This way they have to be certain they want to delete something and I can still recover the file. I have done this across the last few companies and I have never had to go back to an actual backup of the database or filestore.
There is also the rollback feature as well. It destroys versions when you rollback. This might be something you don't like, but being an admin, I make it crystal clear about the destroying of previous versions before I rollback. With this, I have never had someone ask if they can rollback the rollback. To avoid this, there is always the option of getting a previous version, saving it outside of PDM, checking the file out, opening that old version file and saving over the top of the checked out newer version.
I agree, none of our users have delete rights (apart from admin).
For your rollback, is that only if a file has been revised in error? We avoid it as to not have a lower revision effectively superseding a higher revision (in the event the higher revision has already been issued).
I agree that getting versions can be used, but requires a workaround. In your case you'd need to open the affected file(s) and input the correct revision & rev comment (unless I am missing something).
You can also create a workflow state called "Deleted" and give the users the ability to "Change State" via a transition like "Delete file(s)". Then take away everyone's read access to the "Deleted" state. Easy to fix later buy just having a transition back to your working states. Then as admin you don't have to cleanup after the users and only get involved if they accidentally deleted something via the change state.
For a restore from backup to work you would have to have a backup of the complete archive folder structure and the database to go along with it.
The reason for this is that the archive server does not have the vault on it the way the vault view shows it. The archive folder has a list of folder from 0 to F (Hex). In each of those folders are some sequentially generated folders. Then the files is stripped of its real name and is placed in the next folder. The path and file name are stored in the database. When you open the vault in the client it builds a folder tree that represents what the vault looks like from the information stored in the database.
If the user deleted a file and you went onto the archive server and somehow restored that D:\Archive\0\000a5a00\00000001.sldprt file the database would not recognize it as being there. The only way that would work is if the file somehow got corrupted, but the database still knew it was there. The question is how would you possible know where it was in the archive.
Files are usually corrupted when saved or on check-in. If you run into a corrupt file you are most likely going to loose some work. You can rollback to a previous version that is not corrupt, but you will be hard pressed to restore it from somewhere. If it is in the vault corrupt it was most likely corrupt on the machine that checked it in.
If you really want to be able to restore individual files you would need to setup some sort of backup task from the client vault view. This could be on a client machine or the server. You would need to have the local view get the latest of all the files and then do some sort of copy out to a different folder. You might be able to use Copy Tree and retain the folder structure, but I think that only works on assemblies. You would probably have to enter the vault view and then select all the root level folders and copy/paste them to a different folder. You could then backup that copy and be able to restore specific files from it. The file would of course come in as the next version. Hope that helps.