- All companies, are given a unique id
- All shares, are given a unique id
- All uploaded versions of a file, are given a new unique id
- All files are stored on FileCache servers
All files are stored in a path combining the company unique Id, the share unique Id and the unique file id
Therefore, on the FileCache server you cannot find the original name of a company, a share or a file.
The files are stored on multiple drives on the individual FileCaches.
The individual files are not segmented. However, depending on the configuration, the files from the same share,
can be spread over several drives and FileCaches.
The avalible drives on the Filecache are listed in a configuration file located under the Filecache installation folder
The format for the drive list is in JSON format as follows:
To add a third drive, add a third drive letter. Ex. f:\\MoreSpace
All file events (create, rename, update etc.) are stored in a database on the DomainMaster. For files, the specific
FileCache location is a part of the event information.
This means that there a history of all file uploads (and all other events) with the corresponding FileCache location,
stored in the database.
Deleting a file, does
not remove it from the FileCache!
All history version of the file stays online for download.
The “FileCache maintenance system” take care of the number of file history versions, the company have “online”.
A configuration controls how and when a version of a file is deleted from the FileCache and thereby becomes “offline”.
Configuration parameters vary but include:
- Number of version to retain online
- Storage limitations
- Backup all configured drives on all the FileCache servers
- This ensures that the files and all the versions of the files can be restored
- Backup the MongoDB directory on the DomainMaster
- This ensures that the shares, companies, file- FileCache location, users , ACL’s etc. can be restored
Recovery of a FileCache
Create the server
If the drives are not on the physical/virtual machine
- Connect the drives as before, and the files are accessible
If the drives are on the on the physical/virtual machine
- Restore the files into the corresponding drives, and the files are accessible
Recovery of a DomainMaster
Create the server
Restore the MongoDB directory
Start the MongoDatabase
- The shares, user etc. are now accessible
Restore in general
Why is a restore necessary?
If the FileCache maintenance system have removed the file, due to age, number of version to retain online
or storage limitations, the files become “offline”, meaning the file is not “online” for download.
Restoring the file(s) is necessary.
A common problem
Normally this is a problem to restore files. The “restore” overwrites the files on normal shared drives.
It is therefore, normally, necessary to restore into a “Restore Temp folder” or similar. This makes it
cumbersome for the users to find the restored file, there could be several versions of the file, the same
day, and only the latest version of the file is on the backup!
This normally spawns a new restore request for the same files the previous day, so the user can get a
“better” version and have to assemble a view of the changes over several restores.
These perils are non-existing on the RushFiles Cloud Drive system.
As all versions of files, are named individually, it is not possible to “overwrite” a file with a wrong or different
version of the file. If a file that is already on the system is accidently overwritten, it would be with the same
data and no harm is done.
If the version of the file is not removed from the FileCache then the file is accessible from the “file history
viewer” on the client’s. The history version of the file, can be “opened” as a normal file in read mode.
This makes it possible to have both the current and several older versions of the file open at the same
time for compression and more.
Restore of files from “a specific day” (the daily backup)
As the system have a full history of all files. There are no DB restore involved.
Are there several versions of the same file the same day, and they are all on the backup, restoring the full
backup will make all the file versions from that day “online” for download.
The CompanyId and or the ShareId are used to be more specific in the restore. These Id’s are found in the
company configurator, and should be a part of the restore request.
Restore individual files
Restoring a single file or multiple files should not be necessary as the restore procedure is designed to be on a share level.
However, the file unique version id together with the FileCache, company and share, can be found in the
“history viewer” on the client, and should be a part of the restore request.
Restore a full directory and all its subdirectories, is a complex operation, and it’s recommended to use the
restore procedure for “a specific day”.
After a restore the “size” of the company’s drive is not correct. Normally it’s not necessary to change it as the
files, will removed again by the
Not all clients have the history feature yet.