I’m spending more and more time on my Raspberry Pi, which lives in my outdoor office in the garden shed. The Raspberry Pi is more than just a minimal writing machine — I write my texts using the NEO keyboard layout in Markdown, sync the website via Git to Bitbucket, and push the Hugo-built site to my Uberspace server with rsync. Sounds complicated, but once it’s running it’s a wonderfully simple and fast workflow.
The beauty of the Raspberry Pi is that the little computer is dirt cheap and runs off nothing more than an SD card or a USB stick. Perfectly minimal and exactly right for my writing work. Everything else I can handle on my iMac (still in Germany at the time), my Windows machine, or my iPad. If the Raspberry ever dies, I can replace it — or just the USB stick — and be back up and running immediately. The thing is portable and I often SSH into it from another computer anyway.
I don’t want to sound too paranoid, but my goal is to be as flexible and independent from technical disasters as possible. That’s why I’ve spent the last few months working through different backup strategies. I’ve documented some of them already. The principle: be as redundant as possible. Two local backups on different media, plus one online. The important thing is that I can keep working immediately if something goes wrong — even without internet access.
Here are my three backup paths:
Monthly: System clone to a USB stick
I’m a big fan of cloning. The entire drive or USB stick gets copied one-to-one. If the USB stick dies, I swap in the clone and everything’s fine. The only requirement is that the clone is reasonably up to date.
That’s also the downside. Cloning takes a while — it’s not something you do every day. I create an .img file on my Windows PC with Win32 Disk Imager and write the .img file (which is the same size as the 64 GB USB stick) to another USB stick using Balena Etcher. The whole process takes one to two hours. I clone at the start of each month because my system is now stable and I barely change the setup anymore (apart from updates). So I’ve always got a USB stick in my desk drawer, ready to go. I just pull my latest files and texts via Git and I’m off.
Monthly: .img file to an external hard drive
I also copy the .img file to an external hard drive that I keep in another room — in my “there’s-a-bushfire-coming-and-I-need-to-grab-everything-important bag”. If you live in Australia, you know this isn’t paranoia. It’s Tuesday. I should probably put the .img file in the cloud too, but I can’t get the file properly compressed on the Windows machine, and with my slow internet connection it would simply take too long.
Daily: Restic + Rclone backup to OneDrive
But what about my actual data? I mostly work with Git repositories, so the daily backup is really about preserving my optimised system. The clone approach above takes too long for daily use, so after a day’s work I run a quick incremental backup with Restic to the cloud. Restic is open source and a backup kicks off with a single terminal command. The data is encrypted in transit and the whole thing usually takes just a few minutes.
With Restic you can send your data via SFTP to your own server, or to something like Google Drive. Unfortunately Restic doesn’t support OneDrive natively, so things get a bit more involved: you first need to install rclone and configure OneDrive within rclone. After that, you can use a Restic command to run incremental backups via rclone.
Here’s how I set it up:
Install rclone: I followed this guide — worked well.
Connect to OneDrive via rclone: This is a bit more involved, but ultimately you just need to answer a few questions correctly. I found a good walkthrough here. The author seems to have used an older version of rclone, so don’t follow the recipe mechanically — in my case OneDrive was number 17 and I named my connection “onedrive”. You start the process with:
rclone config
Test the OneDrive connection with rclone: I could now use rclone to copy my Raspberry Pi to OneDrive. But since it would transfer the entire system every time, that’s not practical — it takes too long. In this example I’m copying my Raspberry Pi home directory into a folder called “raspberry” inside a “backup” directory on OneDrive. Give it a try if you like:
rclone copy /home onedrive:backup/raspberry-pi4
Install Restic and connect it with rclone: Now Restic enters the picture. With Restic we only back up what’s actually changed. First, install Restic:
apt install restic
Next, create a “repository”. This is where Restic stores its backups:
restic -r rclone:onedrive:/backup/raspberry-pi4 init
Then you can start the backup. The first run takes a bit longer. After that, Restic checks the last snapshot and only saves the changes:
restic -r rclone:onedrive:/backup/raspberry-pi4 backup –verbose /home
Every now and then you should verify the backup is intact:
restic -r rclone:onedrive:/backup/raspberry-pi4 check
If something goes wrong, you can restore your backup like this. In this example I’m restoring the entire home directory to a temporary folder:
restic -r rclone:onedrive:/backup/raspberry-pi4 restore latest –target /tmp/restore
Once you’ve got the hang of Restic, you can do all sorts of things. I back up key Nextcloud directories to OneDrive (
restic -r rclone:onedrive:/backup/nextcloud backup --verbose Nextcloud/) and I’m considering going the other way too — cloning important OneDrive directories locally. Belt and braces. Since the command is a bit unwieldy, I’ve put it in a bash script that I run daily with./backup.sh. I could set up a cron job for it, but I actually like the ritual of manually checking out at the end of the day.nano backup.sh
Then add the simple bash script:
#!/bin/bash
restic -r rclone:onedrive:/backup/raspberry-pi4 backup –verbose /home
Before you can run it with
./backup.sh, make it executable:chmod u+x backup.sh
This might all read a bit cryptic, and I did spend a fair bit of time getting it right. But now it’s straightforward. I do a system clone to a USB stick once a month and run daily backups. I’ve thought about adding restic backups to an external hard drive as described here, but that might be overdoing it. This way I’ve got the confidence — and the evidence — that I can keep working immediately when something inevitably goes sideways. And from here: never change a running system!
First published in German at reinergaertner.de, where I’ve been at it since 1997. AI did the heavy lifting on the translation. I did the heavy squinting at the result.