Then, true to form, I disappeared for five years.

In my defense, I did eventually come back around to it. But the first thing I had to admit was that the 2021 plan was over-engineered. I was about to go write a whole application — functions, an API, a database, the works — to serve what is, when you get right down to it, a stack of HTML files that changes a couple of times a decade. There are no comments here. There are no logins. There’s nothing dynamic to speak of. Building custom software for that is like installing a freight elevator to move a single box of books.

The honest answer was a static site generator. My posts are just text and a few photos, so I write them in Markdown and a tool called Hugo renders them into plain HTML. Those files go into an S3 bucket, and CloudFront sits in front to handle HTTPS and caching. That is serverless — there’s no server to patch, no database to back up, it scales to zero, and it costs me well under a dollar a month (most of which is the DNS zone I was already paying for). As a bonus, the thing that always nagged me about running WordPress — the steady drip of security updates and plugin vulnerabilities — simply goes away. There’s nothing to exploit in a static file.

The whole thing is wired up so that publishing is now just git push. My content lives in a GitHub repo; pushing to it kicks off a pipeline that runs Hugo and copies the result to S3. All my old WordPress URLs redirect to the new ones, so nothing should break if you followed a link here from somewhere.

Here’s the part that made it genuinely a “keep my skills current” project, just not in the way I expected back in 2021. I didn’t really build this by hand. I used Claude Code, an AI coding agent, and mostly just described what I wanted: static files on S3, CloudFront in front, content as Markdown in GitHub, and a pipeline to build and publish it. It poked around my old WordPress site, asked me a handful of genuinely good questions — which generator, how to manage the infrastructure, whether to migrate my old posts or start fresh — and then went and did the work. It pulled every old post out of WordPress and converted it to Markdown, wrote all of the infrastructure as code, stood it up in AWS, and handled the migration. It even caught a busted code snippet in my old kinetic watch charger post, where an #include <Servo.h> had quietly lost the <Servo.h> part years ago because it looked like an HTML tag. My job was mostly to review, approve, and click a single button to connect it to GitHub.

Full disclosure: it drafted this post too. I’m editing and second-guessing it before it goes live, which feels like the right division of labor.

It’s a little surreal. The version of me writing that 2021 post wanted a project to keep up with where technology was heading. It turns out where it was heading was “describe the thing you want and review what an agent builds.” The blogging software I was fretting about writing already existed, and most of what was left was plumbing that a machine was happy to handle.

If you’re reading this, it means the new setup works. I won’t promise the next post will come any sooner than this one did — but at least now there’s no idle server sitting around waiting for it. 🙂

At the time of this writing (January 2021), I’m hosting this blog using WordPress on an Amazon EC2 instance. WordPress is pretty popular software that requires some kind of persistent service running. I haven’t looked at statistics, but I doubt this blog gets any kind of traffic other than bots, given that I rarely post anything. That’s a lot of idle CPU time. While the smallest EC2 instances aren’t very expensive, I can probably do better.

I work with Amazon Web Services a lot at my day job. EC2 (virtual servers) is just one of hundreds of services they offer. Many of these services offer on-demand compute, storage, and data services. Used together, this is known as “serverless” architecture. For example, Lambda is a Functions as a Service (FaaS) offering that allows you to run a small piece of code. As soon as it’s done running, you’re not charged for it until the next time it runs. The service provider manages provisioning resources, starating it up, and releaseing the resources when done. This really brings down the cost of running a low traffic site like this one.

WordPress isn’t designed to work in that way though. I’ve seen a couple of blogs describing ways to coax WordPress to run this way, but it seems pretty brittle and unmaintainable to me. So, if not WordPress, what? I searched around for a while looking for something that was built like this, but came up with nothing. So sounds like it could be a fun project.

I’ll plan to post more once I get a little further along.

But, this post isn’t about trying to rescue data from a failed drive. This post is about making sure that’s not necessary because you had a good backup plan. I will be discussing the steps I have taken to implement backups from the various Windows and Linux machines on my network to my home Linux server as well as off-site backups in case your particular disaster isn’t limited to just your hard drive. You wouldn’t want to lose all those family photos, would you? Lucky for me, my wife keeps most of those on her computer.

Let’s start with the home server. I’m backing up every machine on my network here, so the server needs a lot of space. I ended up getting 2x 4TB drives and installing them in a RAID-1 setup (the drives are mirror copies of each other). This gives me a total capacity of 4TB and ensures that a single drive failure would not be disastrous. I can just keep running on one drive until I can install a replacement. Don’t wait too long on that replacement though. I’m not going to go over this process here as there are many guides for doing so already. The server is set up as a Samba file server for Windows to use and ssh for Linux to use.

For Windows backups, I went with SyncBack Free. It’s fairly easy to use. I followed the steps in this guide to set it up to backup the Windows profile directory and the ProgramData directory. You need to create two separate backup profiles to do both. Point the backup target to the backup directory on the file server.

There were a number of files and directories that couldn’t be backed up. I went through the error log and excluded those files (they’re mostly automatically generated files that don’t really need to be backed up) so that the backup would show as successful. Finally, create a schedule for both profiles to run automatically each night. Make sure your computer will be turned on at the time it’s scheduled to run.

Next, I turned to the Linux backups. For this, I opted to use duplicity. It supports encryption, full, and incremental backups. I have it encrypting the backups on the way to the file server over sftp. I set up a schedule in cron to do an incremental backup 6 days a week. On the 7th day, it does a full backup and removes the backups from 3 weeks ago. Here’s what the crontab looks like:

0 23 * * 1,2,3,4,5,6 duplicity incremental --exclude-filelist exclude.list --encrypt-key <PGP Key ID> --ssh-options="-oIdentityFile=<path to ssh key>" /home/<my user id> sftp://<my user id>@<fileserver>//mnt/backups/<name of system being backed up> 2>&1
0 23 * * 7 duplicity full --exclude-filelist exclude.list --encrypt-key <PGP Key ID> --ssh-options="-oIdentityFile=<path to ssh key>" /home/<my user id> sftp://<my user id>@<fileserver>//mnt/backups/<name of system being backed up> 2>&1 && duplicity remove-all-but-n-full 3 --force --ssh-options="-oIdentityFile=<path to ssh key>" sftp://<my user id>@<fileserver>//mnt/backups/<name of system being backed up> 2>&1

The first line runs at 11pm Monday – Saturday and runs the incremental backup. The second line runs at 11pm on Sundays to do the full backup and remove backups older than 3 weeks. One thing to note when running this in cron: the SSH key and the PGP key should either have no passphrase or you will have to set some environment variables that contain the passphrase. Keep the PGP private key backed up separately as you will need this in order to decrypt the backup in the event you need to do a restore.

Finally, I’m storing my backups off-site. After some research, I settled on CrashPlan. For $5/month (with 1 year purchase, $6/month on a month-to-month plan), you get unlimited storage. For $12.50/month, you can avoid all of the mess above and get unlimited storage for up to 10 computers all through CrashPlan’s interface. There’s a 30 day free trial. You need to use the Java interface to configure CrashPlan. If your file server is headless, use the instructions here. You can throttle the upload so you don’t saturate your upstream and make it difficult to use the Internet until your backup is complete.

Hope this helps anyone looking to do something similar. If not, at least I have some documentation on this process for myself 🙂

First, rig control. Linux has the hamlib libraries that can control many different radios. I had built a simple CI-V serial interface for my ICOM IC-706 a while back. It’s not perfect, but can be made to work at 300 baud. The rigctl command line program is pretty simple to use. The manual page for it has all of the commands listed. Many don’t apply for my particular radio, but I can switch frequency, mode, memory channel, and a few other key operating parameters. I can read all of those parameters as well to make sure I’m where I think I am.

Second, the sound card interface. I got a Signalink USB a few months ago with the appropriate cable to hook to the back of the IC-706. Experimented around a bit with the levels and VOX control settings to come up with something that seemed to work well for me. This also keys up the transmitter so it’s nearly plug and play.

Third, I need a way to get my voice to the radio and get the audio back to my remote location. I see many people using Skype for this, which seems to be overkill to me. I thought there must be some easy point-to-point VoIP program I could use on my home network and potentially route outside the network if I wanted. I found a program called Linphone in the Debian repositories and it was really easy to set up. No need to set up an account or anything like that and it has a smart phone client as well. Installed it on my radio computer and on my laptop, set up the radio computer to automatically answer and use the Signalink USB for audio, then call it from the laptop. That’s all the setup that was needed. Some quick testing and I was able to get two way communication going.

Final test was checking into a net. My local simplex net tonight was run by an operator that I usually have trouble hearing and I had my squelch set too high, so he was cutting in and out pretty bad. That’s one of the settings that aren’t available through the CI-V interface on the IC-706, so I quickly ran into the shack and turned that down a little. I was able to hear him better after that, but I had already missed my turn by then. I switched over to the repeater net a few minutes later and confirmed my check in over there, no problems at all.

Not bad for a couple of hours of tinkering. Most articles I read include installing Ham Radio Deluxe, two Skype accounts, and remote desktop control software. Compare with rigctl, Linphone with no accounts needed, and simple SSH. I think it’s easier anyway.