Almost there

The second edition of the Raspberry Pi Home Server series should be finished and published this weekend. I just wanted to give everyone a heads up. I got a fire lit under me last night when it seems my series was linked to by a certain Wil Wheaton, the patron saint of geeks. My version 2 posts were mostly done, but I’m really pushing now to get the final versions out this weekend.

If you briefly saw a post about Syncthing, sorry about that. I don’t know why WordPress decided that one didn’t need to be a draft anymore. It was totally not finished yet, and you shouldn’t take my word for it on that part yet. It’s a new section I’m considering for the series this time around as an alternative to BitTorrent Sync, but I’m still evaluating its performance on the Pi. I’ve heard mixed reviews, and found about three different ways of installing it. It looks good so far, though. I’ll unleash it on my public share and let it cook for a while before releasing my findings. You can expect that one in the coming weeks.

P.S. CrashPlan on the Pi is still a big ball of fail. There are workarounds, but I dislike all of them. I’m working on the total end-run of the workarounds, which requires nothing from the pi but a share. Let’s see them break THAT.

Posted in Computers and Internet | Leave a comment

State of the Blog

I wanted to post an update here to let people know what’s going on with the blog, and the Raspberry Pi Home Server series in particular. I realized a while ago that the Pi world moves incredibly fast, and my articles keep getting out of date. This affects some articles more than others.

The worst one is the CrashPlan installation. Code42 does not support ARM-based devices, and in the last year or so seems to have really cranked up the frequency of their releases. With each release, CrashPlan auto-updates itself, destroying all of the necessary tweaks that were done to make it work in the first place. There’s no good solution to this problem. There are, however, some “kinda bad but they’ll have to do” solutions. I’ve heard mixed reviews about the success or failure of the different approaches, and have been trying to crowdsource a consensus out of my comments, which now dwarf the articles they are attached to.

I’ve also just recently had a hardware failure. The SD card in my own server croaked, and while I DO have backups, Raspbian has moved significantly onward since I first wrote these articles. I’m taking this as an opportunity to rebuild from scratch, document it all again, and release an updated set of articles with new ordering, advice, and screenshots. This is going to take a little while, but I’m working on it.

It’s time to declare comment bankruptcy and publish the RPHS v2 series, and it starts right now with me rebuilding my own server from scratch, and documenting it all like I did the first time.

In the meantime, the old articles are still perfectly valid, and should get you where you need to be. Just make sure you read the Updates sections that now appear on pretty much all of the articles. I think my plan now is to do less updating in-place, and publish new versions of the articles instead. This will let me occasionally reset the long tail of comments each article has grown, and start over with a fresh set for each update. It’s worth a shot.

Posted in Computers and Internet | 2 Comments

Raspberry Pi Home Server: Changes

A lot of exciting changes are happening, and at least one major disappointment. There’s a new Raspbian image out(, and it brings a new desktop along with it ( The Pixel desktop is a Pi-optimized LXDE variant, and it looks pretty much like what you’re used to if you’ve built a Pi since the beginning of the year. There are some notable changes, though.

Chromium Browser: This is the open-source version of Chrome, and while we’ve always had the ability to install it ourselves, it’s there by default now. Not only that, but it’s got some plug-ins preconfigured to make the web more Pi-friendly. In particular, it’ll force YouTube to send videos in a format that the Pi can decode more easily using hardware acceleration. That doesn’t really mean much to a server, but it’s a welcome upgrade.

Built-in VNC: That whole chapter I wrote about x11vnc? Yeah, you can forget that now. You now have a working remote desktop included in Raspbian out of the box. Just download the RealVNC Viewer and connect. It might be possible to use other viewers like UltraVNC, but it’ll take some configuration. The RealVNC viewer is small, portable (no need to install it), and works immediately. I’ve made the switch.

And now for the bad news. The folks at Code42 have been pushing updates to CrashPlan at an increasing rate, and every time CrashPlan updates itself, it breaks all of the patching and tweaking we had to do to get it running. At first, this was merely annoying. Now it’s become unmaintainable. I can’t trust my backup machine if it can be brought down at any time by a silent, compulsory update. I’m working on a new blog post about alternative approaches to using CrashPlan at home, and I’m hoping that the Pi can still be a part of that setup.

In the meantime, if you want to continue holding the Pi’s hand, and diving into the guts of CrashPlan roughly once a week, be my guest, but I won’t be putting any more time into maintaining the CrashPlan instructions unless I hear that Code42 has either started supporting ARM-based devices directly, or at least given us an alternative to stop the constant updates from undoing everything.

Posted in Computers and Internet | 4 Comments

Backing up a Pi that boots from the hard drive

I get this question a lot, and figured it’s about time to address it. Once you’ve finished a Raspberry Pi Home Server, and have it booting from the hard drive, how are you supposed to take backups? After all, you can’t just pop out the SD card and just run it through Win32DiskImager anymore.

If your main computer is a Mac or Linux machine, then you can simply shut down the Pi, hook it up to your main computer, and use the “dd” command to make a copy of the OS partition in the same way you wrote the SD card in the first place, but with the “if” and “of” parameters reversed.

If your main computer is a Windows machine, then one answer is to create a secondary, minimal SD card or the Pi. You can use Raspbian Lite for this, since you won’t need anything but the command line. Then, you just shut down the Pi, drag it back over to your desk and hook it back up to the monitor and keyboard, swap the SD cards, boot up using the new SD card, and use the “dd” command to write a backup of the OS partition to the Data partition on the same drive, or mount a flash drive, and back up to there.

But wait… there’s a much simpler option. You can just attach the hard drive to your Windows computer, and use Win32DiskImager to take a backup of the whole hard drive. You’ll get a snapshot of the complete working state of the system this way. If the drive attached to the Pi is very large, then I realize this may not be an option, but let me tell you about my current setup.

My Raspberry Pi Home Server has two drives these days. The first is a smallish SSD (like 60GB small) that I have long since “traded up” from. It still has two partitions on it, a 16GB OS partition, and a Data partition, but that’s not where most of my actual stuff goes. I use the Data partition on this first drive for things like the swap file, MiniDLNA’s database, and CrashPlan’s metadata, but my actual music, movies, pictures, and CrashPlan backup files are all on a second hard drive, which is the 2TB RAID. In this way, I’ve completely separated my “stuff” from the system. The storage drive is blissfully unaware of the Pi’s existence. I still format this drive using NTFS, so I can just plug it into my regular computer and get to my stuff.

By the way, I don’t really use Win32DiskImager anymore, either. These days I use HDDRawCopy, which has the added benefit of writing out compressed image files, so instead of creating a 60GB file and then Zipping it up to get my hard drive space back, I end up with a file that’s already compressed in the first place.

Every now and then, after doing system upgrades, I’ll shut the whole thing down, hook the primary drive up to my regular computer, and create a new image. This image contains not only the OS, but the current state of the Data partition as well. If I’ve added music or movies since the last back up, then MiniDLNA will have to play catch-up when the system starts up, but eventually, it all sorts itself out.

But what if you only have a single, very large drive hooked up to the Pi? There are many programs available that will let you back up individual partitions. I don’t have a personal favorite here, but I would welcome recommendations in the comments.

I’ve heard good things about Paragon Backup & Recovery, and Macrium Reflect Free, but I don’t know if backing up and restoring individual partitions is included in their free versions or not. Also, I think the free version of Paragon is limited to backing up and restoring drives that are 2TB or less. I’m not sure about Macrium. Perhaps I’ll find the time to do some testing on these free solutions and update this post a bit later on.

Posted in Computers and Internet | 3 Comments

CrashPi Zero?

So I just went to my local MicroCenter, and picked up a Raspberry Pi Zero for $5. It’s pretty much everything the model “A” had, but with 512MB of memory. You could also say that it’s like a model “B” without the network jack. Networking is really the only thing this model is missing, and if you are planning to use a USB hub, or just a wireless network adapter, then you should be all set.

The way I have the CrashPi set up right now with a powered USB hub running the whole thing, I realize that I could replace the current B+ with a Zero, and everything would continue to work just fine. The only new piece of hardware needed is a Micro-USB to regular USB adapter, sometimes called an “OTG” (USB On-The-Go) adapter, so I picked one of those up as well. Due to the new design, I also had to use a Mini-HDMI adapter which I originally bought for our DSLR camera. I have used the adapter precisely zero times for that purpose, so it’s nice to see it finally getting some use.

I just burned a new Raspbian Jessie image to the card and plugged it in. According to my “Charger Doctor”, it’s only drawing 130 milliamps with the desktop running, so the power consumption is considerably less than previous models. The possibility of battery-powering this new version is very real. The composite video output is still there in the form of some unpopulated solder pads on the board, so you’ll have to provide your own jack. At this point, I’m thinking it should be very possible to buy one of those “TV Games” joysticks, and entirely replace the guts with a Pi Zero, making it the most portable DIY emulation system ever.

If it weren’t for the lack of networking, I’d be ready to replace my single Raspberry Pi Home Server with a cluster of Pi Zeros, each running just one or two of the normal server functions. You could have one that just runs VPN, another that’s just for the file server, and another that’s just doing CrashPlan. The functions would be more isolated, and you’d STILL be cheaper than a normal Pi. Adding in USB hubs and wireless adapters would raise the cost of course, but it’s amazing what you can find on Amazon.

Oh yes. There will be updates coming.

Posted in Computers and Internet, Home Server, Raspberry Pi | 3 Comments

CrashPi – An off-Site backup for the whole family

Note: Just as with the main CrashPlan article, the CrashPi is not currently operational, but I’m leaving the article here in hopes that maybe the next update to CrashPlan won’t break things quite so completely.

In Part 15 of the Raspberry Pi Home Server series, I mentioned the possibility of building a “CrashPi”, a simplified version of the full server running only CrashPlan, and some basic supporting functions such as X11VNC for maintenance. I hadn’t actually built one, though. It was just an idea… until now.

Today, I’m introducing a dedicated CrashPi into my home network. The original idea of the CrashPi was for it to be placed at a friend or relative’s house to act as my off-site backup, keeping the home videos, photos, and documents safe in case of a disaster like a house fire. I hadn’t quite gotten around to asking to mooch from the in-laws broadband, though.

Then, just last week, my wife suggested that I could just put it in the garage, which is not attached to our house. The odds of the house and the garage being lost in anything short of a meteor strike are pretty low, so I’ve decided to build a real CrashPi, and to use CrashPlan’s “friend codes” to act as a true off-site backup for my college-age twins, who are now off on their own. No matter where they go now, the CrashPi in my garage is their secure backup.

Gathering the parts

I have a few older Raspberry Pis sitting around since the 2s came out, so I’m going to use my old B+, which has more RAM than my original B. This extra memory will be very helpful for CrashPlan, which can be rather resource hungry. Offloading CrashPlan to a separate server means that my main home server will have less to do now, which will also help with its stability.

The complete list of parts is as follows (with Amazon links):

  1. Raspberry Pi Model B+ (
  2. Power Supply (
  3. 8GB Micro SD card (
  4. TP-Link TL-WN722N WiFi adapter (
  5. CyberPower SX550G UPS (
  6. 5TB Seagate “Expansion” drive (
  7. BUD Industries NBF-32018 ABS NEMA Enclosure (
  8. C14 Power Inlet (
  9. Panel-mount USB cable (
  10. Powered USB Hub ( or similar)
  11. Adhesive anchors (

Note: Not all the items actually came from Amazon. Most of the parts (hubs, power supplies, cables, WiFi dongle, etc.) came from my local MicroCenter, but not everyone has a toy store like that close to their house, so I’m providing Amazon links so you can at least see the parts I’m talking about. My hub is actually made by Inland, but Amazon doesn’t carry it, so I picked something similar.

The Pi, power supply, and SD card I already had on hand. The other items I bought new for this project. I have a smaller WiFi adapter (Tenda W311M) that I’ve used inside the house, but wanted a little more range to reach the garage, so I sprung for the dual band. I know how Pis hate having their power yanked, so I picked up another $45 UPS to keep things maintenance-free. The hard drive was the biggest expense on this project. All together, it came to a little over $200, but I think it will be worth it to keep the whole family’s stuff safe, and especially the kids. One has already had a laptop stolen and lost all of her work for the semester up to that point, so the cost seemed worth it to me.

I won’t repeat all the individual steps here, but I’ll refer back to the original posts, and explain any differences.

Install the OS

installed the OS as usual using the current Raspbian image (not NOOBS). I left the overclocking off this time, favoring stability over performance for the CrashPi. I didn’t add any additional users, either.

Going Headless

Next, I set everything up for headless operation, installing Webmin and X11VNC exactly the same way as I did for the main server.

Attaching a Hard Drive

I attached the hard drive, mounted it at “/mnt/backups”, and created a “public” share through Samba. I did not, however, choose to boot from the hard drive in this case. I did set up a 1GB swap file on the external drive, and configured the Pi to use that for swap space rather than the file on the SD card. This will prolong the life of the SD card. I opted for NTFS as the file system again so that I can easily attach the drive to my regular computer if needed. “ext4” is still your best choice for performance and reduced overhead, though.


Of course, the whole point of this project is to run CrashPlan, so that went on next, with the backups going to “/mnt/backups/crashplan”. I have signed into CrashPlan using the same credentials as my regular computer and Raspberry Pi Home Server. I signed each of the kids up with their own accounts, though, and used the friend code from the CrashPi instance to use as a destination.

It’s important to note that the friend codes are installation-specific, so the code from the CrashPi is different than the code from my regular computer or the existing server. Using the friend code from the CrashPi means that my kids have the ability to backup to the CrashPi, and only the CrashPi, so I don’t need to worry about them using up all of my primary server’s space.

Also, since each kid has their own account, they get their own notification emails about how up-to-date their backups are, rather than all of the emails going to me. Using their own accounts also means that their stuff is safe from prying eyes, even mine. They own the encryption of their individual backups, not me. The downside is that if they forget the password to their CrashPlan account, I can’t help them and they’ll have to start all over again.


Finally, I installed NUT, and configured the CrashPi to shut itself down in the event of a power failure. I didn’t set up email notifications about power events or anything like that because my main home server is already telling me about those.

Building the enclosure

Here’s where the project starts to become its own thing. I ordered the BUD box from Amazon based on it’s interior dimensions. It’s a bit deeper than I had anticipated, but that worked out well as it allows me to simply lay the hard drive down on the bottom of the enclosure rather than mounting it to the back of the box as I originally had in mind.

A metal box would have let me mount a bare hard drive directly to it, and would have acted as a heat sink, but I went with a plastic box so as not to interfere with the wireless signal. A metal box would have required an external WiFi antenna. I tried to build a system with as little custom fabrication as possible so that all the pieces can be easily swapped out if needed.

I could have run cords out of a simple hole in the box, but since this computer will be mounted in my dusty garage, I wanted to leave no holes where dust or spiders could get in and mess things up. For that reason, I wanted to keep the number of holes to a minimum (zero). I got the power inlet and panel-mount USB port so that once they were in place, I could seal around the openings with some RTV sealant I already had around. This should keep everything clean, and keep any insects out.


I cut most of the cord off of a small, three-outlet power strip (from Big Lots), soldered the leads directly to the power inlet, and enclosed the joints with some heat-shrink tubing. Then I mounted all the components to their respective walls using tie-wraps and adhesive anchors. The end result looks like this:


On the right is the USB hub and power strip (behind the hub). On the back of the box is the Pi itself, and just resting on the bottom of the box is the drive. There’s still room in this box for me to add another drive or two if needed, so I should be set for quite a while.

As you can see, the Pi is powered by its own hub. The hub is plugged into one of the Pi’s regular USB ports, but the Pi’s own power cord plugs right back into the hub again. You might not expect it, but this works just fine because the micro-USB jack on the Pi doesn’t even use the data lines, it only uses the power lines. You don’t have to worry about the Pi “talking to itself” or anything.

The drive I chose has its own power supply, but luckily it’s been implemented properly and doesn’t “back-power” the hub (and thereby the Pi), so when I turn the hub off, the whole system goes down. Naturally, I log in remotely and “sudo shutdown -h now” first.

Finally, here’s a picture of the whole thing mounted to the wall in my garage:


The single cord coming from the right side of the UPS (The battery-backed side) is running everything in the server box. The USB cable coming from the bottom of the UPS runs to the panel-mount USB port, which is then plugged directly into the Pi internally. The two plugs on the left have nothing to do with the server. They are for a couple tool chargers, and the UPS just provided a convenient, surge-protected place to plug them in.

It’s not the world’s most attractive “server rack” for sure, but it’s weather-proof and kind of off-site. It’s now the destination for all of my backups, including backing up the data from my regular Raspberry Pi Home Server. I’ve set up CrashPlan on my server to back up it’s drive full of stuff (Media, mostly) to the CrashPi, so now I have a redundant backup of all of the family photos, videos, and music. These were already stored on a two-drive RAID, but now they’re even better protected in the event of a disaster.

Posted in Computers and Internet, Home Server, Raspberry Pi | 5 Comments

Raspbian Jessie released

Raspbian “Jessie” just went official, and that means that those of you following along with my instructions are going to notice some serious changes. The first and most obvious is that Jessie boots straight to the desktop by default, and raspi-config has been superseded augmented with a desktop GUI tool.

I have built up a new server using the Jessie image, and will add updates to the beginning of each individual post. I’ll be updating the posts in-place in the near future, but I’ve simply run out of weekend for now.

Posted in Computers and Internet, Home Server, Raspberry Pi | Leave a comment

The Raspberry Pi Home Server series is now on Pluralsight

I’ve been working on this for the last couple of months, and I’m excited to announce that I’ve turned this series into a course for Pluralsight. The course is available at:

For those that don’t know already, Pluralsight is a subscription-based online training site. Don’t worry, I’m not going to take the blog posts away. I would never do that to you. Sometimes you just want to SEE something being done instead of just reading about it, though. You can follow along with the bouncing ball, and build your own server along with me.

The course is divided up in much the same way as these blog posts, with each module adding on one more piece of the puzzle, although the order is a little different, and some items (like Transmission) weren’t included.

If you have a Pluralsight subscription, please consider watching the course. If it does well, I might be able to do more of them.

Posted in Computers and Internet | 8 Comments

Raspberry Pi Home Server: Part 15b – Adding more Pis to the UPS

Note: This article is part of a series. See the Index for more information.

Self-promotion: I’ve recorded this series as a screencast for Pluralsight:
If you have a Pluralsight subscription, please consider watching it. Thanks!

Updates: I haven’t had any reports of issues with this post under the Jessie release of Raspbian, so I assume it all still works. I don’t have a spare UPS to test with, though, so unless someone reports an issue under Jessie, I think everything still works.

Adding more Pis to the same UPS (optional)

With Raspberry Pis being so cheap, you may very well have more than one. Perhaps you’ve split CrashPlan or MiniDLNA off onto a Pi all by itself. Maybe you went a little crazy and built a Pi-powered super-computer cluster. If, for any of these reasons, you have multiple Pis, and you’d like them to share the same UPS, how will they all know when the power’s gone out? After all, you can only plug the USB cable into one of them, and buying a separate UPS for each Pi would be overkill, right?

The great thing about NUT being split up into layers is that you can run multiple client instances against one server. Normally, this is the sort of thing you’d only see in a large server rack, where you’ve assigned one computer to watch the battery and tell all the others when the power goes out. It’s not the sort of thing regular home users usually care about, but Raspberry Pi owners are not regular home users.

If you do happen to have multiple Pis, getting them all to share a single UPS and shut down gracefully is actually really simple.


For this article, I’m assuming you’ve already completed the standalone version in the previous article. If you came straight here from a link or a search, go look at that article first, and get everything working before continuing.

Reconfigure NUT on the server

In the previous article, NUT was configured in “standalone” mode, which means that the server and client were on the same machine. It also means that the server isn’t expecting any other clients to be talking to it, so it simply isn’t listening for them.

Log in to the Raspberry Pi that is connected to the UPS. With a little bit of reconfiguration, it will become a NUT server. Edit the NUT configuration file.

sudo nano /etc/nut/nut.conf

Scroll down to the bottom, and change the mode from “standalone” to “netserver” (not “nutsever”, mind you).


Close and save the file (ctrl-x, y, enter)

Next, you’ll need to configure credentials for the remote machines to use when connecting to the server.

sudo nano /etc/nut/upsd.users

Add a new user at the bottom. You can call it anything you like, but I’ve chosen “upsmon-remote”. Give it a password, and specify that it is a upsmon slave.


Next, you need to tell the NUT server to listen for client connections. Edit the UPS daemon configuration file.

sudo nano /etc/nut/upsd.conf

Find the “listen” section, and add a listen directive using the IP address of your server. If you don’t configure anything, the NUT server will listen only to the computer that it’s on, which is localhost, or IP address Since you now want NUT to listen for clients on other systems as well, you’ll need to specify a real IP address.

Adding the server’s own IP address might seem a little redundant, but remember that NUT is made to work on all kinds of equipment, and it’s very common for larger-scale servers to have multiple network interface cards, and you’d only want it to listen for NUT traffic on the “inward” facing one.

Because you will still want to run a ups monitoring client locally on the server itself, and you’ve now overridden the defaults by specifying one IP address, you’ll need to explicitly add an entry for localhost ( back in as well, otherwise the local ups monitor will stop working. The result should look something like this:


Note: You’ll need to substitute your own Pi’s address in place of That’s just the address where my own Pi server lives. The default port that NUT listens to is 3493. If you wanted to change that, for some reason, you would do that here. I’m going to leave it at the default port, though.

Reboot the server to get things reconfigured and restarted.

sudo reboot

Double check that you can still communicate with the NUT locally:

sudo upsc rphs

You should get the same kind of listing of UPS settings and status as you did in the previous article:


If you get some kind of error instead, make sure that you added an entry for localhost ( in addition to the Pi’s regular IP address.

You can actually run NUT configured this way, but without any clients connected, and it will behave in pretty much the same way as it did in standalone mode, but it will still be listening for additional clients over the network.

Configure the client machines

Install NUT on each additional Pi that you intend to run from the UPS.

sudo apt-get install nut

For these additional client-only installations, you can skip configuring a UPS driver and proceed directly to configuring the client.

sudo nano /etc/nut/nut.conf

Go to the bottom of the file, and set MODE to “netclient”.


Next, edit the upsmon configuration file.

sudo nano /etc/nut/upsmon.conf

This time, configure the client to talk to the remote server for information, and configure it as a slave. This time, the “system name” will not be “RPHS@localhost”, but “RPHS@” (again, substitute your server’s IP address).

If you remember from last time, the first part of this “system name” is the name you gave your UPS, and the second part is the address of the server it’s attached to. The name and password should match the “upsmon-remote” name and password from above, and the final parameter will be “slave” instead of “master”. The result should look like this:


The difference between “master” and “slave” has to do with when each one will shut down. When the UPS says the power has dipped below the safe threshold (20% for my UPS), the server (the master), will tell all of the clients (the slaves) to shut down first before shutting down itself.

Like on the server, you’ll need to set up the permissions so that the NUT configuration files are readable by the nut user. Unlike the server, though, you don’t need to touch the upsd.users file because users are defined on the server, not the client.

sudo chown nut:nut /etc/nut/*

sudo chmod 640 /etc/nut/upsmon.conf

Check connectivity

From the slave system, you can issue the same kinds of commands you could run from the master system. Use this to verify that everything is communicating properly.

sudo upsc RPHS@

I’ve used the IP address because name resolution didn’t work for me. It’s one of those things I’ll probably learn to set up someday, just not today.


Test the system

Once again, unplug the UPS, and you should see warning messages appear on both the server and client(s) right away. You may want to mute the beeper if your hardware supports it, and plug something in to help the battery drain faster.

Here is what it looks like from the server’s perspective:


And this is from the client’s perspective:


Apart from the name of the server (RPHS vs. RPHS2), and the fact that the client shut down first, you wouldn’t be able to tell the difference between the two, even though only the server is actually attached to the UPS.

Lather, Rinse, Repeat

Repeat as necessary for each additional Raspberry Pi you are plugging in to the same UPS. That’s all there is to it. When the power goes out, all your Pis can now shut themselves down safely.

Posted in Computers and Internet, Home Server, Raspberry Pi | 9 Comments

Raspberry Pi Home Server: Part 15–Power Failures

Article Obsolete

A new version of this series has been published. Please refer to the new index for updated articles and ordering. This article is kept for historical reference, but should be considered out of date.

Note: This article is part of a series. See the Index for more information.

Self-promotion: I’ve recorded this series as a screencast for Pluralsight:
If you have a Pluralsight subscription, please consider watching it. Thanks!

Updates: I haven’t had any reports of issues with this post under the Jessie release of Raspbian, so I assume it all still works. I don’t have a spare UPS to test with, though, so unless someone reports an issue under Jessie, I think everything still works.

My previous home “server” before embarking on this series was just an old laptop of mine. It wasn’t particularly strong, but it could run CrashPlan, and serve files. One advantage it had was that, being a laptop, it had a built-in battery and knew how to shut itself down if the power went out. Of course, I had to go downstairs and start it back up once the power was restored, but at least nothing got corrupted.

If you have a desktop computer at home or at work, you may also have an Uninterruptable Power Supply (UPS) under your desk. This is basically a battery big enough to power your computer and monitor long enough for you to save what you are doing and shut down gracefully. Most modern UPS units also have a USB port on them and come with software so that when the power goes out, the UPS can tell the computer to suspend, hibernate, or shut itself down depending on how you’ve configured it.

I’ve had a one of these small UPS units at home for years now, although it hasn’t been running my computer, which is always a laptop anyway. Instead, the UPS is there to keep my overly-sensitive cable modem and network router from getting freaked out by the occasional power glitch. I used to have to reset my router once every couple of weeks, but since I put it on a battery I’ve hardly touched it.

It shouldn’t surprise you that there are UPS options available for the Raspberry Pi as well. Take the CW2 “Pi UPS” (, for example. This product will work fine for most simple Raspberry Pi projects running off of an SD card, but my particular installation has a 2TB RAID enclosure hooked up to it. I don’t think AA batteries are going to cut it. What I need is something that will keep the hard drives spinning long enough for the Pi to shut down safely.

I’ve had my Raspberry Pi Home Server plugged into this same UPS for months now, because it makes for a conveniently-placed power strip and evens out the power supply. My UPS is a little older, though, and doesn’t have a USB connection for communicating with the computer attached to it. It does have a serial port, but a few experiments with serial to USB adapters got me nowhere. The level of sophistication on older UPSes (like mine) can be pretty low, and they often use the serial port in a way that doesn’t exactly count as proper serial communication.

With that in mind, I’ve replaced my old UPS with a newer one, specifically a CyberPower SX550G. I chose this model because:

  1. It has a USB connection to the computer.
  2. It was on sale for $40.
  3. I’m cheap.

It’s a 550VA battery backup, which probably wouldn’t get you very far with a full-sized desktop computer, but it should be more than adequate for a Router, a Raspberry Pi, and a couple of drives. It could probably run those devices for a good couple of hours if needed, actually. I haven’t done the math, but if not for the external drives, it could probably run the Pi for days.

So how can we get the Pi to use it intelligently? It certainly didn’t come with a ready-made software package for the Pi, although Linux software is available for it.

Network UPS Tools (NUT)

The Network UPS Tools package, aka “NUT” (, is a collection of programs meant to make UPS hardware from different manufacturers work in roughly the same way. It’s available for a wide variety of platforms, one of which happens to be Debian Linux, of which Raspbian is a variant.

NUT consists of three major components

  1. A software driver to communicate with your particular UPS using whatever protocol it supports, and translate that into a common API.
  2. A daemon (service) that connects to the driver and acts as a communication hub.
  3. A client program that can perform various tasks such as shutting down the computer when the power state reported by the server changes.

There are a few other components, such as command-line utilities that can tell you about the current state of the UPS, or allow you to make changes to the UPS configuration. For the most part though, we’re concerned with these three components.

Note: NUT works with a wide range of UPSes, but without owning one from each different manufacturer and/or vintage, I can’t create instructions specific to each model. Questions about how to get NUT working with your particular UPS are best addressed on the project’s own site, or its GitHub site. For the most part, though, they should all work the same way. If your UPS is older, and doesn’t have a USB port, but has a 9-pin serial port, you are totally on your own. Maybe you could hack something together using the GPIO pins. If so, you’re a better man than me.

Installing Network UPS Tools (NUT)

Simplicity itself. Like most things we’ve installed in this series, NUT is available through apt-get

sudo apt-get install nut

Select your driver

Find the driver for your particular UPS by looking at the compatibility list on the NUT site ( If you can purchase a UPS that’s on the list, then that’s great. If you don’t find your UPS on the list, that doesn’t mean it won’t work, though. For instance, my new UPS isn’t on the list, but a ton of other devices from the same company are, and they all seem to use the same driver (usbhid-ups). I gave it a shot, and it works just fine. YMMV

Configure the UPS

Once you’ve identified the driver for your UPS, you’ll need to edit the ups configuration file.

sudo nano /etc/nut/ups.conf

This file, like all of the NUT configuration files, is very well documented inline, and explains all of its different options. At the bottom of the file, you’ll add an entry for your UPS. You’ll need to give it a name, specify a driver, and give it a description. There is also an option to specify a port. For units that connect via a USB cable, this is meaningless, but it’s still required, so use the value “auto”.

[RPHS] driver = usbhid-ups port = auto

desc = “CyberPower SX550G”

The name in square brackets is so you can tell multiple UPS devices apart in case you have one NUT server monitoring multiple devices. Unless you’re building something really esoteric, you probably only have one UPS like me, so for lack of anything better to call it, I’ve named mine “RPHS” after the computer it serves. You can put anything you want in the description, so I just put the make and model of the device for reference. The end result should look something like this:


That’s it for configuring the UPS itself. Close and save the file (ctrl-x, y, enter).

Configure the daemon

A daemon is the Unix/Linux term for any invisible background process. Windows folks call these “services”. For NUT, there is a daemon that is in charge of listening to the UPS via the driver, and telling the client applications what to do. Edit its configuration file like this:

sudo nano /etc/nut/nut.conf

For this simple application, where both the client and the server programs will be on the same computer (the Pi), go to the bottom of the file and set the MODE to “standalone”.


Close and save the file.

Verify hardware configuration

To check whether the driver and daemon are configured correctly, you can simply start up the service.

sudo upsdrvctl start

You should see a message confirming your configuration. It should look something like this:


The first time I tried to connect to the UPS I got the error “could not detach kernel driver from interface 0: Operation not permitted”. I rebooted and tried again, and everything was fine.


Notice that this time I got a message about “Duplicate driver instance detected”. This is because now that I have things configured correctly, the driver started up automatically when I rebooted. Not only that, but the daemon should be running now as well. Check it like this:

sudo service nut-server status

You should get a message that the NUT server is running.


You can now ask the NUT server questions about the status of the UPS using “upsc”, one of several command line utilities that apt-get installed. Substitute the name you gave your UPS above as needed.

upsc rphs

You’ll get quite a long list of information about the configuration and status of your UPS.


Depending on the make and model, you’ll get more or less detailed information.

Configure the monitor

That’s two out of the three layers. Last but certainly not least is the “upsmon” client. This is the part that will actually shut down the computer when the NUT server says so.

Define credentials that the monitor client program will use to connect to the server.

sudo nano /etc/nut/upsd.users

Go to the bottom and define two users, one called “admin” and one called “upsmon”. You can actually name them anything you want, but naming the “monitor” user after the program that will use it (upsmon), seems to be the convention. You give the “admin” user rights to issue commands and change configurations with the “actions” and “instcmds” settings. The “upsmon” user has no such rights, it’s just there to listen and shut the computer down when the power goes out.


password = mypasswd

actions = SET

instcmds = ALL


password = mypasswd

upsmon master


Since this is the computer that’s actually in charge of monitoring the UPS, set the “upsmon” setting to “master”.

Next, edit the configuration file for the upsmon client program.

sudo nano /etc/nut/upsmon.conf

This configuration file is pretty long, and has a lot of options. The one we’re interested in is about five pages down. Look for the example lines that start with “MONITOR”, and create a new entry on the blank line below that section. There are six parts to this setting.

  1. The keyword “MONITOR”. It does have to be all uppercase, by the way.
  2. The “system” name in the format UpsName@HostName. I called my UPS “RPHS”, and since we’re running in standalone mode, we can just use “localhost” for the host name, so the resulting “system name” is “RPHS@localhost”.
  3. The “power value”. This only applies to big servers with multiple redundant power supplies. Just set it to “1”.
  4. The user name that you established in the upsd.users file (upsmon) .
  5. The password that you established in the upsd.users file (mypasswd).
  6. A value indicating whether this computer is the master or slave. You can read about the distinction in the upsmon.conf file itself, but for a standalone system like this, use “master”.

When you’re done, it should look something like this.


Close and save the file.

Next up, a little permissions wrangling. You need to set up the various configuration files to be readable by the NUT components that use them, but not by other users. This prevents anyone from reading the password, and sending unauthorized commands to the server to shut everything down. It may be overkill for a simple home network, but it’s also really simple to do.

sudo chown nut:nut /etc/nut/*
sudo chmod 640 /etc/nut/upsd.users /etc/nut/upsmon.conf

You should get no complaints


UPS Commands

Depending on the sophistication of your particular UPS, you may be able to send it commands to do things like initiate a self-test, or simulate a power failure. You can get a list of what your particular UPS supports with sudo upscmd –l rphs


The number and type of commands will vary by manufacturer and model, so your output may not match mine. There are a few commands here worth mentioning, though. The “” command will shut down the UPS immediately. Think of it as the “goodbye world” command. You generally don’t want to mess with that one. You could actually use this command to turn a second UPS on and off, allowing your Pi to control the power to something else. I’ll leave that one up to your imagination, but there are certainly cheaper ways to automate things.

The “beeper.mute” command will temporarily silence the warning beep that my UPS makes when the power goes out. This will make testing the system a bit less annoying here in the next section. The “beeper.disable” command would probably have the same effect, but on a more permanent basis.

Testing the system

At this point, you can unplug your UPS from the wall and, after a short delay, you should get a message that the system is now running on battery power.


If you plug it back in, you’ll get another message that power has been restored.


So far, so good. Now for the real test. Unplug the UPS from the wall and leave it unplugged. If your UPS supports it, now is a good time to issue that “beeper.mute” command.


You can sit and stare at the screen, wondering when it will shut down, or you can periodically check on the status to see how fast you’re using up the battery. I plugged my laptop charger and a television into the UPS to speed things along. A good, old-fashioned 100-Watt bulb would help, too.


Eventually, when the battery gets low enough, the system should shut itself down.


Plug the UPS back in, and if you’re lucky, everything will start back up again. For some models, even after the power is restored, you may have to physically press a button on the UPS to start everything back up. Mine starts up on its own, so a few minutes later I was back up and running.

What’s next?

Next up, I’ll show you how to attach additional Pis to the same UPS, and have them all shut down when the power gets low. I was going to make it all part of this post, but this one’s long enough already, don’t you think?

Posted in Computers and Internet | 36 Comments