Everything I self-host runs on a single Raspberry Pi, and that’s a problem most people like me often forget to consider. You take your data off someone else’s servers and then keep all of it in one place that you own.
There’s the usual pushback about a house fire or some other unforeseen incident destroying your only copy. I’m hoping my house doesn’t burn down in a fire, but I see the wisdom in such objections.
To fix this, self-hosters typically go back to a cloud subscription for a second copy, often from a smaller vendor other than Google or Microsoft. But I wasn’t thrilled about paying a third party to hold the data I moved off third-party servers.
So I went looking for a second machine I already owned, as a second point of failure. Now I have two servers to burn down in a house fire (just kidding).
I found an old Google Pixel that had barely been touched for a couple of years, and it worked better than I expected. Though I wouldn’t call it a Raspberry Pi replacement.
The problem with putting everything on one Pi
One box means one copy
My Pi runs the services I depend on, and the storage attached to it holds the only copy of most of what’s on it. A failed drive or a botched update could wipe away all of that at once.
Most conversations about this end in cutting out a monthly storage bill. Redundancy is treated as something you rent, and that’s why so many people quit cloud storage by building a Raspberry Pi backup system and then stopping there.
Having a second backup machine covers dead hardware, corrupted storage, and my own mistakes.
It doesn’t cover a fire or a burglary, because both boxes are in the same building. I’d do my best to protect both, but anyone who needs that level of security should look at off-site storage, paid or otherwise.
What I wanted was the first category solved without a subscription, using hardware already in the house.
Why an old phone makes a decent second server
It arrives with its own battery
A phone is a small computer with storage, a network stack, and a screen for checking on it without plugging anything in. It also has something my Pi doesn’t.
The battery works as a built-in UPS. The power went out in my building during the second week, and the phone continued to run on its own charge while everything else died.
It also draws less power than the Pi. A Raspberry Pi 4 idles around 2.85W, and the phone comes in under that when you stop keeping its screen awake, which is a mistake I’ll come back to.
The Pixel also costs nothing, and that’s what I’m driving at. It wouldn’t have made sense to buy a second Pi to back up the first one.
Setting up the server in Termux
No second Linux required
The entire stack for this project is Termux. It’s a terminal emulator with its own Debian-style package manager, and it runs native ARM binaries.
I knew about it during my foray into cybersecurity. I expected to install a full distro before I could get it running. However, you only need proot-distro for glibc software missing from Termux’s repository, and OpenSSH isn’t missing.
Termux is no longer maintained on the Play Store, so install it from F-Droid or their GitHub repository. Then install any add-ons from the same F-Droid.
From there, run pkg update && pkg upgrade, then pkg install openssh. Set a password with passwd, and get your username with whoami.
Next, run termux-setup-storage and grant permission, or the server won’t see files outside its own sandbox. Starting sshd puts it on port 8022, because port 22 won’t bind on Android.
I set a DHCP reservation on my router, so the address remains static. Most of this looked familiar from enabling SSH on a Raspberry Pi, so that wasn’t too difficult.
If you need the server to start automatically, use a separate app called Termux:Boot. You launch it once, so Android registers it, then you create the ~/.termux/boot/ directory and drop in a script that runs termux-wake-lock followed by sshd.
The Android problems you run into
Phantom processes and power management
Android 12 added a cap on phantom processes, and it’s the thing most likely to break a setup like this. The system kills background processes when the total across all apps passes 32, or when CPU usage gets heavy.
The fix depends on your version. Android 14 and later expose a Developer Options toggle, while 12, 12L, and 13 need an ADB command from a computer.
However, you have the usual battery optimization issue. I exempted Termux and Termux:Boot in the app settings so that they’re not throttled overnight.
At first, I left the display on, using the developer option that keeps the screen awake while charging. But that wastes power, since the wake lock does the same job with the screen off.
To prevent overheating, I removed the case, ensured proper ventilation for the phone, and used a smart plug to handle charging so that the phone isn’t locked at 100% 24/7.
What ends up on it
The Pi pushes, the phone receives
The Pi is the source of truth, and the phone is the copy. A cron job on the Pi runs rsync over SSH into the phone’s storage on a schedule, so the phone doesn’t have to do anything.
If the phone dies, I’ve lost a backup rather than data. All I need to do is run the same 20-minute setup on another spare and continue as usual. Or go back to cloud storage.
It also works as a plain file server, which is where the project started. Pulling documents off of it over SFTP is now the least interesting thing it does, and there’s a whole smart home version of an always-on old phone if you need sensors and cameras more than storage.
It’s an experiment I’m keeping
Two months in, nothing has fallen over, but I won’t pretend an old Pixel belongs in the same category as the Pi. It does this one job well because the job is simple, scheduled, and doesn’t require fast storage.
I expect it to struggle if I use it for anything close to what the Pi runs all day.
However, it settled the question I started with: Does resilience need a monthly bill for the failures I’m most likely to face? The answer is no.
