The great open-source tool Syncthing works very well for private DropBox-class capability, including optional file-multiversioning at one or more sync locations. I have some very used PC hardware which would work well enough for this, but then I was thinking, I could save the cost of a 24/7 150W light bulb at the very least, if my cute little Raspberry Pi 2 could do the job.

The end of the story is already here; it’s working beautifully. Here’s the elements I am using:

• One Raspberry Pi 2 with Raspbian installed in default fashion on its bundled microSD card, good passwords set, and fully up to date, including firmware. I have been finding considerable performance boosts with update of firmware, so I definitely recommend it.
• One USB flash drive big enough to hold your sync archive with satisfactory free space. It might work with a USB hard drive, but it didn’t work with my OEM-portablized Hitachi TravelStar, too much power demand…although I did limit the power use of the whole rig by using one 2.1A double-USB cell-phone charger for everything! :-) I’m now using a 32-gigabyte LEXAR USB flash drive, the archive is currently 17.5G.
• Wire or wireless to the Internet connection. I have not seen a major performance hit from wireless, but then again I’m using a pretty beefy wireless router and my wifi environment is not choked.
• The USB flash drive formatted BTRFS. (One does the format using mkfs.btrfs, and then sets the /etc/fstab for automount and auto-check at boot.) This is important, because one can find quite a large number of reports of USB flash drives failing when used as OS drives under ext3, ext4, and NTFS. I first set it all up using NTFS on the flash drive, and had noticed the flash drive’s LED flashing frankly all of the time, even in moments when there was no traffic according to Syncthing, and the incoming stream was forced to pause a lot. That concerned me, so I tried it in ext4, and it was just about as bad. So I did a bit of research, found the many reports of failures, found multiple flash-specific filesystems all of which admitted of various different downsides which I didn’t like very much, set it up again using BTRFS, and was really amazed. The LED went off a whole lot less, and the effective incoming bandwidth during full sync literally doubled, ~1-1.5M/s to ~3-3.8M/s depending on the moment, and no pauses visible.
• Special BTRFS attributes set up in /etc/fstab. I set these and did a reboot after the full sync was about one-third done, and was yet more amazed. Even when full sync was going on, the LED did not and does not flash more than a half-second or so every once in a long while, and incoming stream bandwidth remains very nice. I’m using ssd_spread, noatime, and space_cache. A USB stick can’t really count as an SSD because its circuitry hides a lot of things from the OS, so the attribute “ssd” does not take effect if set, but these three work just fine and should keep it running as long and reliably as possible.

Here it is on my bench at home, doing its so-quiet production work, not moved yet to its permanent location. Everything except the (temporary) screen is visible, the “power supply” is plugged into a two-prong extension cord; and those are CD blanks in the corner for a size comparison :-)

Try it, you’ll like it! :-)

More methods of the same, not tested yet:

https://www.seafile.com