Back Up Encrypted ZFS Data Without Decrypting It, Even If TrueNAS Doesn’t Approve

[Michael Lynch] recently replaced his Synology NAS with a self-built solution built on ZFS, a filesystem with a neat feature: the ability to back up encrypted data without having to decrypt it first. The only glitch is that [Michael] is using TrueNAS, and TrueNAS only wants to back up unencrypted ZFS data to another TrueNAS system. Fortunately, there’s a way around this that isn’t particularly complicated, but definitely requires leveraging the right tools. It also provides an educational walkthrough for how ZFS handles these things.

The solution is a small handful of shell scripts to manage full and incremental backups and restores of encrypted datasets, without having to decrypt the data first. As mentioned, this is something TrueNAS will handle by default, but only if the destination is also a TrueNAS system. Now, [Michael] can send that backup to off-site cloud storage with only a little extra work.

There’s one additional trick [Michael] uses to monitor his backups. He leverages a paid (but with a free tier) service called Cronitor. It’s not very obvious from the site’s features, but there is a way to implement cron job monitoring that doesn’t require adding any software whatsoever. Here’s how that part works: Cronitor provides a custom, unique URL. If that URL isn’t visited regularly (for example, because the cron job fails), then the user is notified. By integrating this into an existing cron job, one can be notified. Such an integration would look like this:

0 0 3 * * monthly-job && curl --silent<API-KEY>/monthly-job?state=complete

In short, if the cron job runs successfully, curl checks in by visiting the custom URL. If that doesn’t happen, the user gets a notification. No added software, just a simple leveraging of a free service for some added peace of mind.

Backups are easy to neglect, so maybe it’s time to take a few moments to consider what you do for data storage, including how you’d recover from disaster.


PCI I-RAM Working Without A PCI Slot

[Gnif] had a recent hard drive failure in his home server. When rebuilding his RAID array, he decided to update to the ZFS file system. While researching ZFS, [Gnif] learned that the file system allows for a small USB cache disk to greatly improve his disk performance. Since USB is rather slow, [Gnif] had an idea to try to use an old i-RAM PCI card instead.

The problem was that he didn’t have any free PCI slots left in his home server. It didn’t take long for [Gnif] to realize that the PCI card was only using the PCI slot for power. All of the data transfer is actually done via a SATA cable. [Gnif] decided that he could likely get by without an actual PCI slot with just a bit of hacking.

[Gnif] desoldered a PCI socket from an old faulty motherboard, losing half of the pins in the process. Luckily, the pins he needed still remained. [Gnif] knew that DDR memory can be very power-hungry. This meant that he couldn’t only solder one wire for each of the 3v, 5v, 12v, and ground pins. He had to connect all of them in order to share the current load. All in all, this ended up being about 20 pins. He later tested the current draw and found it reached as high as 1.2 amps, confirming his earlier decision. Finally, the reset pin needed to be pulled to 3.3V in order to make the disk accessible.

All of the wires from his adapter were run to Molex connectors. This allows [Gnif] to power the device from a computer power supply. All of the connections were covered in hot glue to prevent them from wriggling lose.