Background

A short summary of my backup strategy is: I run daily backups to my
NAS. In order to recover from risks like my
apartment burning down or my belongings being stolen, I like to keep one copy of
my data off-site, updated less frequently.

I used to store off-site backups with the “unlimited storage” offerings of
various cloud providers.

These offers follow a similar pattern: they are announced, people sign up and
use a large amount of storage, the provider realizes they cannot make enough
money off of this pricing model, and finally the offer is cancelled.

Manually ran update-grub, so that GRUB refers to the boot disk by UUID instead of root=/dev/sda1. Especially once the external hard disk is connected, device nodes are unstable.

On the serial console, pressed F10 (boot menu), then 4 (setup), then c to move the mSATA SSD to number 1 in boot order

Connected the external hard disk

Setup: persistent reverse SSH tunnel

I’m connecting the apu2c4 to a guest network port in our office, to keep it
completely separate from our corporate infrastructure. Since we don’t have
permanently assigned publically reachable IP addresses on that guest network, I
needed to set up a reverse tunnel.

After enabling and starting the unit using systemctl enable --now autossh-nas,
the apu2c4 connected to the NAS and set up a reverse port-forwarding.

On the NAS, I configure SSH like so in my /root/.ssh/config:

Host apu2c4
Hostname localhost
Port 2200
User root
IdentitiesOnly yes

Finally, I authorized the public key of my NAS to connect to the apu2c4.

Note that this concludes the setup of the apu2c4: the device’s only purpose is
to make the external hard disk drive available remotely to my NAS, clean and
simple.

Setup: full-disk encryption

I decided to not store the encryption key for the external hard disk on the
apu2c4, to have piece of mind in case the hard disk gets misplaced or even
stolen. Of course I trust my co-workers, but this is a matter of principle.

Hence, I amended my NAS’s cloud-config setup like so (of course with a stronger
key):

Improvement: bandwidth throttling

Improvement: RTC-based wake-up

I couldn’t figure out whether the apu2c4 supports waking up based on a real-time
clock (RTC), and if yes, whether that works across power outages.

If so, one could keep it shut down (or suspended) during the week, and only
power it up for the actual backup update. The downside of course is that
any access (such as for restoring remotely) require physical presence.

If you know the answer, please send me an email.

Conclusion

The presented solution is easier to integrate than most cloud storage
solutions.

Of course my setup is less failure-tolerant than decent cloud storage providers,
but given the low probability of a catastrophic event (e.g. apartment burning
down), it’s fine to just order a new hard disk or apu2c4 when either of the two
fails — for this specific class of backups, that’s an okay trade-off to make.

The upside of my setup is that the running costs are very low: the apu2c4’s few
watts of electricity usage are lost in the noise, and syncing a few hundred MB
every week is cheap enough these days.