Select Page

You might be wondering – how has the Raspberry Pi NAS held up after 1 year, 9 months, and 29 days of traveling & heavy usage daily?

Surprisingly well actually. Roll up the sleeves and read on.

*** UPDATED 4/9/2016 *** rewrote lsyncd config for version 2.1.6, added systemd functionality, and upgraded to Raspberry Pi 3B

I’ve been lucky to have zero major issues with the Pi not booting up, stability of the Pi overall, and only minor software update problems (which were usually self-induced).

I did have two problems though.

1) For some strange reason, one of the drives failed to mount properly during boot, and lsyncd proceeded to sync blank data to the second drive. Doh. Good thing the first drive had no issues and I was able to copy everything back to the empty one.

2) Eventually the 2nd drive failed. Seagate was quick to send a replacement, but it made me question having selected  (due to cheap cost & increased failure rates) spinning drives in the first place.

The original article


Say you have some type of home NAS or drive array which houses valuable information. And let’s say you want to go traveling for a while (as I plan to do), but leave the box in storage. What’s the best way to bring your data with you, or just a bunch of free space for projects?

For most, ditching the drive in your laptop for something which has more capacity is good enough. But what if you wanted to maintain some level of redundancy for your data?

In my case, I was coming from a 3 x 1TB drive configuration in RAID 5 with battery backed write cache (Dell PERC 5/i), running Openfiler with NFS and SMB. The answer, of course – Raspberry Pi. Obviously the trade off is a drastic decrease in speed, but more than worth the effort to put this little setup together.

Also, due to the CPU overhead and complexity, I didn’t want to bother with software RAID and decided instead to use lsyncd.

The kit includes:

1 x Raspberry Pi
1 x Adafruit Pi case
2 x Seagate Slim Traveler 2TB USB drive
1 x Pluggable 4 port USB hub
1 x PowerGen 2.4-Amp USB wall charger

RPi alone doesn’t supply enough power for both drives, or even one for that matter. The powered USB hub is necessary for reliable operation of both drives. Before we begin, we’ll need to install a few packages:

Then make sure lsyncd starts on boot:

When working with a large directory structure as I was, upping the number of inotify watches was necessary to keep the lsyncd service from stopping unexpectedly.

Now comes the tricky part. When working with USB drives on the Raspberry Pi NAS, the first drive you plug in will always become sda, the second sdb, and so forth. We’ll need to mount each drive by ID, as opposed to sdX so that no matter the order they’re plugged in, each drive will always have the same mount point. I created a /media directory with directories usb001 & usb002. These will serve as mount points for each drive. I found the ID by plugging in one drive, then listing out /dev/disk/by-id. (It’s worth noting that I had already connected each drive to a Windows machine and formatted with NTFS.) Once you have the ID, you can assign the block device to a mount point in /etc/fstab. Then do the same for the second drive.

In my case, usb002 had all of my data and I didn’t want to risk accidentally syncing it with the empty drive; note the read-only (ro) flag in the options column. Once everything finishes, I’ll remove the flag and specify ‘defaults’ like usb001.

It’s now 2016 and my RPi is running RASPBIAN JESSIE (released February 2016) with kernel version 4.1.13.  There are a slew of new enhancements, not to mention keeping the release current with package updates, but it’s a really great thing they’ve dropped upstart init scripts in favor of systemd. If you haven’t gotten to play with systemd, it’s way more flexible and a better startup system overall.

I’ve adapted this NAS project to take advantage of a newer version of lsyncd (2.1.6) as well as systemd. Lsyncd version 2.1.6 wasn’t available from the repo (only 2.1.5) when this was written, so I built a package for RPi which you can download here: lsyncd-release_2.1.6-1_armhf.deb.

Installation is easy:

Just a note: if you’d like to compile your own version and install from source, you may need to install this package first:

Enable lsyncd on boot with systemd:

Here’s the 2016 updated lsyncd configuration for version 2.1.6.

The configuration takes advantage of new features in lsyncd. It’s designed to check each mount for consistency prior to the synchronization of any data. Also you’ll notice a third mount for Dropbox.

This is an SSHFS share (you can see it in fstab) which pushes data to a linux VM running on AWS, which then syncs with Dropbox. When you’re paranoid like me, can’t ever be too safe I guess. Probably overkill, but it’s working well for me so far.

Also worth mentioning, if either one of the mount groups fail the startup check, lsyncd will die and it won’t restart until all mount points exist and are clean.

Mounting & both drives

Start lsyncd:

Monitor the lsyncd service:

Monitor disk utilization:

Monitor disk space:

Here’s a bash script that spits out a percentage. You may need to modify per your own configuration.

Make it executable and then watch the process:

Once the drives sync up and everything looks good, remove the ‘ro’ attribute in /etc/fstab if you set it previously, and use the source drive as your primary Samba share. Lsyncd will automatically sync additional files, deletes, etc. with the second drive. If you experience any difficulty with the Raspberry Pi NAS, lsyncd, or drive complications, simply disconnect and plug directly into another machine.

Further thoughts


The Pi Model 3B became available (February 2016) and seems like a nice & inexpensive upgrade for this tiny platform that I like so much. I’m highly anticipating its arrival. Also, due to the failures that I’ve had with Seagate Traveler, I’m thinking they may not be so ideal for traveling or moving around that much after all.

I’ll still hold onto them, but I think they’ll eventually be replaced with a pair of SSDs. More expensive? Yes. Less capacity? Much. Can the Pi take advantage of blistering SSD speed? Definitely not. SSDs aren’t immune from failure either, but they’re a different breed of storage technology apart from spinning magnetic disks (which tend to break unforgivingly), or stop working at the most inopportune moment.

What’s next? Still kinda pricey, but I’d love to upgrade my Pi with a pair of these:  Samsung 850 EVO 1 TB 2.5-Inch SATA III Internal SSD

Current storage utilization on the Raspberry Pi NAS is 415GB remaining on 1.81TB. Must be all those drone videos!

Anyway, Pi is what it is, I’m happy with it, and I’m not looking to upgrade to a BananaPi, Hummingboard, or anything else, even if the other platforms have a lot more compute power.

I’m still on the fence about pulling the plug on Raspberry Pi NAS – the network cable, that is. Any other Pi users have a good experience with onboard wifi that comes with 3B? Or going wireless in general?