Notice (27. Feb 2014): If you came here searching for “seafile lighttpd”: I wrote a comment on how to get it running on here, this article is only on my perceptions of seafile vs OwnCloud.
In the aftermath of the revelations about NSA spying, a few friends and I decided to buy a hardware (as opposed to virtual) root server together. We wanted to have a more private replacement for the majority of cloud services, most notably e-mail, Dropbox, rss reader and backup solutions.
Before getting the server I used a paid Dropbox account so for me moving away from paying Dropbox I would automatically save money to pay the server cost from. I needed paid because I kept around 30 gigagbytes of stuff on the Dropbox. My main requirement was to have a replacement that can handle large directories with tens of thousands of small files smoothly. I looked into two solutions:
I tried Owncloud, first in a virtualbox ubuntu on my local box. There it was rather ok, working with Dropbox-like performance. During the setup of the server I ran a copy on remotely and tested it with the contents of my Dropbox. I have a few sourcecode folders in there, which, including their git repositories amount to about 100k files, most of them very small. Over the internet, Owncloud was really slow. Analogue modem-like slow. In the end the transfer speeds were below 10kb per second. Really not what you want your 30gig full dropbox folder to sync with. The test folder of a few gigabyte (around 2) was still syncing after one day on a 10mbit connection. So it is not a problem of “getting up to speed”. The reason for this seems to be that Owncloud (currently) uses one request per file. And maybe these are not even parallelized, adding a lot of delay to the file transfers.
Seafile follows a different concept from most of the other selfhosted cloud storage solutions. Instead of a file-based system it uses a revision-based approach based on a modified version of git. If you know the github interface, you know the seafile (web-) interface. For seafile the test with the 100k file folder managed to max out my connection bandwidth. For me this clearly indicated seafile as the preferrable solution and it is what we are now running for “production”. I deployed it with lighttpd and wrote a short post on the seafile mailing list here.
Another plus of seafile is that it supports client-side encryption. This makes it interesting even for people who want to run it on untrusted hardware or on a hosted solution. The server never sees the plain text data after all.