While you should always have an external backup plan for your CentreStack and file servers, CentreStack does provide some safety against data loss by storing the files in multiple locations due to its architecture, versioning functions, and retention policies. However, even with all the necessary precautions, sometimes files do get deleted by accident by users and the files may not be missed until after the retention policy has purged them.
I assume that you already tried to recover your deleted files from the web portal's Trash Can while logged in as the administrator, or the user who deleted the file. And, either the Trash Can is not available, the file was already purged, or you are getting errors that prevent the recovery process from succeeding. In any event, the first priority is to attempt to recover the missing files as soon as possible since there might be a pending purge on schedule. Then, you can open a support ticket by sending an email to firstname.lastname@example.org so we can try to determine what happened (via log collections) and figure out what can be done to prevent it from happening again.
Here are the different locations where you should search to try to recover any missing files. DARE encryption (data-at-rest) on the server or client end-points will complicate the restoration process and might actually make it impossible, since going through the cache or backend storage circumvent the user-interface interactions that actually perform the encryption and decryption of the data.
Backend Storage and File Servers
If you have in-place versioning enabled on the Tenant's backend storage settings, the deleted files and folders of administrators and users will be moved to a hidden "__vers__" folder inside of the folder where they reside. Their names inside of the __vers__ folder will be appended with "@@" followed by a Unix timestamp. If the deleted item is a folder, only the top folder will be appended with this special string and all of the sub-folders and files will remain intact.
If you have in-place versioning disabled on the Tenant's backend storage, files and folders deleted from the adminstrator's root will be moved to a special folder called "g_trashbin" (instead of a __vers__ folder). This will cause a Trash Can folder to appear on the root of the File Browser on the web portal.
Sub-users from a Tenant without in-place versioning enabled will have their deleted root files moved to a special sub-folder called "gsync_69FCD26E-63FF-4E11-814A-518774F26F12". Files inside of this sub-folder will be decorated with an "@m#", a numeric timestamp, a "^" (carret), and the user's global unique identifier string. The "@d#" files are just empty markers. Deleted root folders from sub-users accounts will be moved to the g_trashbin folder.
Server agents without proxy mode also create redundancy by storing the contents of attached folders on the cloud. These attached folders get placed inside of the Tenant Storage root in the following path:
43811DCD-8C5A-4EF9-B903-2EEA9CE88487\gsync_[name of attached folder here]
Any deleted files inside of the gsync_ folder will have the same @d# marker as above. Any deleted folders inside of a gsync_ folder will remain unmarked, but will have a dummy file with the folder's name followed by "_$$folder$$" in the same location.
In summary, a deleted file can be found in multiple places in the backend storage and file server (attached folders), so you may want to generate a recursive directory listing in order to find the files. Removing the special file name markers and moving the files back to their original locations will restore them on the cloud. If the storage is on a Microsoft Windows file system and a missing file was called "budget.doc", you could run the following command prompt to in order to look for all instances of files containing the string "budget" in their paths.
DIR /S /B /A-D "C:\CentreStack\*budget*.*" > "C:\temp\results.txt"
You can run this on the attached folder or any other locations by substituting the C:\CentreStack part of the path above. The output will be saved in a text file called results.txt.
Desktop Client's Local Cache
Another place where you might find a copy of a missing file is in the local cache of any devices that accessed the file prior to its disappearance. For Windows Clients, the path is:
Any user who opened or edited the file via the mounted drive would have a full version of the file saved in his/her local cache. This may not coincide with the head version of the file, but it is worth checking if you have no other options or backups of the file. Server agents are similar to Windows Clients, but cache the data in the following directory instead of the local user's profile:
For the Mac Clients, press Command + Shift + H on the Mac's Finder to go to the Home directory. Then, navigate to:
\gladinet\[email address here]\filesys_cache
File Change Logs
It may be useful to generate a report from the Tenant Dashboard while logged in as an administrator on the web portal to see what happened to the file. To do so, go to the File Change Logging reports page and filter the output by the parent folder name. This report is subject to the retention policies of your tenant and may not have a complete history of what happened. However, it may contain some important clues. The exportable CSV report has a limit of 2000 rows, so you will want to filter the output accordingly to avoid getting incomplete results.
Once you know who deleted the file and where it was located prior to the deletion, you can do two things:
- Look for a copy of the file in the local cache of the user's Windows or Mac Client
- Attempt to undelete the file at the operating system level from the local cache and/or the CentreStack backend storage using a third-party software that recovers unreferenced data. You can search for the file in the last directory where it resided prior to its deletion. I recommend a freeware from CCleaner called Recuva for this last hope scenario. For Recuva in particular, you can specify the directory where it should scan with wildcards, such as "C:\CentreStack\*budget*.*"
You may want to enable the scan to search for files inside of hidden system directories under the Recuva options because both the g_trashbin and _vers__ folders are hidden in the backend storage. Please note that we have no affiliation with CCleaner. Use this at your own risk and only if you are desperate enough. You can run Recuva on both the backend storage and the windows client local cache (%localappdata%\gteamclient\cache) folder. Good luck!