Building a low powered NAS/backup target using a Raspberry Pi
The Raspberry Pi is a great piece of hardware. It can be used for a wide range of projects. (We used the Raspberry Pi to build Screenly, a digital signage software powering thousands of screens.)
Since I already have a fair amount of experience working with the Raspberry Pi, I set out to see if it is viable to use the Raspberry Pi as a NAS for backups.
The short answer is yes, but only if you’re not concerned with read/write performance (think almost cold storage). The reason for this is that you’re limited to the USB2 bus for connecting the drives. Moreover, this bus is also shared with the network interface, resulting in that you get around ~20MiB/s in read/write speed (and even lower if you use RAID1).
- WD PiDrive Enclosure (comes with Raspberry Pi and SD card)
- One additional Additional PiDrive
- Optional: One pack of Sugru
- Optional: Anker USB Charger Power Port
Alternatively, you could a regular Raspberry Pi and connect to USB drives of the same size, but it will not look as clean.
Assembling the hardware
The WD PiDrive Enclosure is delivered in pieces, so you need to put it together. You’ll find that it is straight forward. The only fiddly part is to attach the second drive. You’ll noticed that the second drive fits on top of the first drive. This is where we’ll place it.
Since we want to provide some air flow between the two drives, we use some Sugru. Simply divide the Sugru into four equal ball and attach one on each corner of the first drive and then squeeze the two drives together just enough for the lid to fit.
You should then end up with something that looks like the photo below.
Setting up the software
Setting up OMV is as simple as flashing out the disk image to the SD card and then boot. There are however some defaults that you might want to change:
- Disable the swap by setting
/etc/dphys-swapfile. If you don’t, you will radically reduce the life span of your SD card. You want to reboot after this (or run
swapoff -a) and then also remove
/var/logto tmpfs and configure log shipping to something like Logentries or Loggly (or move it to your external drives).
Since my goal was to have a low powered backup storage, I decided to configure the two hard drives in a RAID1 (mirror) array such that I can survive a drive failure.
Doing this is very straight forward in the OMV web interface.
You can also configure things like users and shares directly from within the user interface. If you do use the backup method below, make sure that you tick the ‘SSH’ box for the user you created.
Intelligent backups with Borg
I’ve been a long fan of Attic. It’s a simple backup tool that allows you to create encrypted and de-duplicated backups. While Attic still works fine, it was abandoned by the author over two years ago. Fortunately the project was forked and Borg was born.
In order to use Borg, you need to install it both on the Raspberry Pi and the machine sending the backup. The only caveat is that Borg requires Python 3, which isn’t installed by default on many systems.
Here’s how my daily summary of a Borg run:
$ borg create [...]
Archive name: 2016-11-16
Archive fingerprint: abc123
Time (start): Wed, 2016-11-16 15:39:02
Time (end): Wed, 2016-11-16 16:00:33
Duration: 21 minutes 30.73 seconds
Number of files: 479655
Original size Compressed size Deduplicated size
This archive: 182.82 GB 149.64 GB 2.21 GB
All archives: 1.98 TB 1.65 TB 160.44 GB Unique chunks Total chunks
Chunk index: 353473 6359805
Does it work? Yes, I’m pleased so far. The I/O performance as mentioned in the intro isn’t great. This was however something I knew going into this. Doing a nightly backup with Borg takes ~20 minutes (see logs above), which I’d say is reasonable.
Should I ever need to read a larger amount of data, I can always attach the USB devices directly to a different computer with USB3 (which the drives supports).
If you are concerned about read/write speed, I’d recommend that you take a look at the Synology product line. They’ll give you a lot better performance, but you are giving up on the “hackability” of the device.