I’ve succesfully installed Nextcloud. Im am struggling with the datafolder. I wanted to use Digital Oceans Spaces which i did succesfully, but:
First implementation was through replacing the datadirctory with adding a objecctstore to the config.php. It worked right away! I had some issues with this approach:
I dont know how to select a sub-directory in my Spaces to mount instead of using the root of S3.
The files become unreadable from online as the files are probably becoming encrypted.
example:
The second implementation was through s3fs wich was working the way i wanted! But… it was verrrrrrrry veryyyy slow and not worthy for production use.
so i am in a bit of a junction here. Does anybody know where i can use the best of both worlds (readable from digital oceans dashboard, starting in subdir and fast!).
I found out that s3fs from the Debian repository was version 1.82 (releasedate may 2017) so i build it from github instead (https://github.com/s3fs-fuse/s3fs-fuse/releases). Although the speed improved slightly (again not enough), the problem seemingly are the small files that come with the appdata folder.
Perhaps its better to be able to split the userdata and appdata?!
Again i would love to use the objectstore solution, but i would also want the files to be unencrypted.
Yes the small files kill S3 performance and redis isn’t much help. What you need to do is enable cache on your webserver (typically nginx). I’ve also found nuster cache to work well which is based off HAProxy.
Varnish would probably work but haven’t tested it yet.
The files are not encrypted. Nextcloud uses urn:oid:id as the S3 format. You need to regularly take backups of your database or you will have to recover it file by file by hand and good luck with that.
The reason for this is pre-sharding. S3 needs filenames to be very specific for pre-sharding to work. Once the file names are correct it can automatically spread your bucket evenly across the sub-namespace…
I dont think cache is going to help as writing the appdata already gives errors writing some of the files for the first time. Im trying to understand why the appdata is in the same container as the userfiles and if they can be spread. I dont see the issue if the appdata can be placed outside of the datafolder as it would speed up nextcloud dramatically. Perhaps use s3fs and symlink the appdata folder to another folder outside the file container would work…
I understand about the files but would be happier if all name/folder integrity stayed intact for backup purposes and failsafe when nextcloud bursts and i am left with urn:oid:id
backup of s3 objects? i don’t know about digital oceans spaces but in aws i would simply turn on region replication and hope that the database backup is in sync.
Im talking about a clean install. The appdata needs to be written for the first time. with s3fs it cannot finish its job because of all the small files. Caching is only possible for files that already exsist.
Ive seen s3ql i did not test it yet. I’ve also red that riofs has a minimum of 20x more speed than s3fs… it gives hope
i rather have a backup. replication is a mirroring job wich is awesome for loadbalancers. when someone loses a file i want it to get back easily instead of hoping replication did not happen yet.
well to restore it easily i probably have to mount it with s3fs/s3ql/riofs because mounting the s3 directly as object-store makes files unreadable urn:iod:### etc. this is not an option for me btw. I would like to be able to use the files even if i choose to ditch nextcloud.
a deleted files exist still as an entry in the database?
nope. to my knowledge the translation urn:ido:xxx to “real name” is an entry in the database. that’s not something s3 is doing. that’s the way nextcloud works.
as we are talking about s3 as primary storage.
if you mount your s3 bucket to let’s say: /var/www/nextcloud/data and use this folder as primary storage you’ll have the same structure (folders, file names) in your s3 bucket.
you could use s3 as external storage. you may try. but as far as I remember it’s not practical with a lot of user.
