Overview and definitions



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

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 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:

  • 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 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.


Notes:

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.