It is redundant and useless.
If the server crashes during a file transfer, you will at best have half a file, which will in most situations not be much better than no file at all. The only situation where this configuration could help, is one where a crash happens between receiving the last byte and writing it to disk. Assuming that you are streaming files to disk while receiving them (as opposed to storing them in a buffer and writing them after the transfer is completed, but that would be stupid, because it would easily result in memory exhaustion when multiple large files are uploaded at the same time), we are talking about milliseconds here (microseconds with SSDs).
You can further reduce that time-window by having the FTP server store files on a SAN or NAS disk via network. Most of these systems will cache filestreams in memory before writing them to disk, which means that they will behave pretty much like the proposed in-memory databases.
This plan will in fact reduce reliability, because with hbase/redis you have another component in the system which can potentially fail or cause bugs.
But what you could propose as a compromise is:
- The ability to store received files in multiple file locations simultaneously for redundancy. Admins can configure as many locations as they want.
- Adapters for treating redis/hbase as file locations
That way your manager could set up a configuration which writes files both to redis/hbase and the filesystem (as pointless as that might be from a reliability perspective), while saner people would get two useful other features:
- Have your FTP server replicate to offsite location(s) automatically, for example an offsite backup location or a global content distribution network
- Use your FTP server as a middleware for dumping files directly into their favorite NoSQL database without the detour via a "normal" filesystem. This could be useful for integrating a system which only speaks FTP with a NoSQL database.