I am sorry but this sounds so strange to me.
Just to explain my setting a bit so it might become more obvious what’s the culprit. I am working for a charitable club (that is financial is critical). There is already a Joomla web page running. Now there is a nextcloud storage needed as well to exchange data.
The webspace package booked has quite some spare storage size so ideally, the two parts (nextcloud and Joomla) could run off the same storage easily. However, it is a pure webspace package with PHP/MySQL. No root server or other fancy stuff.
The data in the NC installation might be personal and critical, it must not be compromised. As I am trusting the NC codebase much more than the Joomla codebase (with all the involved and installed packages), I fear an attacker could gain access to the joomla page (by whatever backdoor/bug/…) and access the critical NC data.
To overcome this, I had the idea to obtain a very small webspace package or VPS that will run the NC itself. The NC should encrypt the data and store them (in encrypted form) on the big web space. If any attacker might get to hack the Joomla instance, he might only get access to the encrypted files but not the real file content.
One way to go is to mount the big server’s storage somehow into the small VPS. Then nectxloud would not even get to know that there is another server involved. Unfortunately, I do not have an SSH/SFTP access of high speed to the big storage. Also, no other protocol I am aware of that can solve this issue (FTP might work but I do not know if it will work using a fuse mount or so).
Long story short: I cannot easily mount the big storage into the small VPS.
However, I think this is the solution with HA you were thinking of somehow. The problem is: I do not have a low trust server but a low trust webspace which is not as capable as a root server.
As far as I understand things correctly there is a way to transparently insert external storage to the Nextcloud instance. I have used it in my personal instance already to include a folder from the server’s file structure to the cloud. However Nextcloud provides a whole set of possible drivers for external storage like SFTP, FTP, WebDAV, SMB/CIFS, Amazon S3, … All these allow the admin to configure the NC instance to store the data (partly) off-server somewhere.
Now we are getting closer to the hairy part (at least from the linguistic part). To have read-write access to the bit data storage, my idea was to install an NC instance there as well. The NC on the small VPS/webspace can then include the big storage NC instance as a WebDAV or optimized nextcloud external storage. This is already working in my testing environment.
The idea of the server-side encryption is to protect just this type of outsourced data. So, I would in my understanding enable server-side encryption on the small VPS/webspace. This should cause all the write operations to any backend (be it Amazon S3 or a WebDAV storage) be encrypted. This is mainly intended against data leakage on these external storages, otherwise, the server-side encryption does not provide any security benefit.
So, you are right, the NC instance on the big storage has a user frontend. But has as well an API frontend called WebDAV. The instance on the small VPS is pretty capable of using this API to write remotely.
I cannot link the encryption with either frontend or backend. It is always associated to a whole NC instance. In my case the instance on the small VPS. This instance has a frontend (web and again API) and a backend (local native storage in nextcloud and the remote storage in the other nextcloud on the big web space). If all data is encrypted before been sent to the backend this should work as I intend it.
This paragraph is a disturbing one. How can encryption decrypt non-encrypted data? Assume a user wants to store a file in such a location on external storage (be it Amazon S3 or NC WebDAV). Da data comes into the frontend unencrypted (ok, it was transport encrypted by the HTTPS layer but forget about that). Then the NC instance on the small VPS will decide where to store and selects the big storage external location. The encryption should now encrypt the data and pass the result to the backend (which will open an HTTP(S) transaction to the second NC instance).
Or are you referring to the reading process? Then of course it must go vice-versa. But after writing some data using the chain described above, the data should not be readable when accessing the raw data on the second instance.