Overview and definitions
• 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 available drives on the FileCache are listed in a configuration file located under the FileCache installation folder in \config\ArchiveDrives.cfg.
The format for the drive list is in JSON format as follows:
{"ArchivePaths":["c:\\ArchiveCache","d:\\secondCache"]}
To add a third drive, add a third drive letter. Ex. f:\\MoreSpace
{"ArchivePaths":["c:\\ArchiveCache","d:\\secondCache", ;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 is 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 versions of the file stay online for download.
The “FileCache maintenance system” takes care of the number of file history versions that the company has “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:
• Age
• Number of version to retain online
• Storage limitations
Backup
• 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 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 has removed the files due to age, number of versions 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, it is a problem to restore files. The “restore” overwrites the files on normal shared drives.
Therefore, it is normally necessary to restore into a “Restore Temp folder” or similar. This makes it cumbersome for the users to find the restored file, as there could be several versions of it, 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-existent 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 accidentally 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. 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 has a full history of all files, there are no DB restore involved.
If there are several versions of the same file the same day, and they are all on the backup, then 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 the 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.
Notes:
Restoring 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.
Not all clients have the history feature yet.