I find some of your comments curious. Particularly,
I'm trying to stay away from methods that are reliant on an application, and do it manually - as I'd feel more in 'control'.
and
I don't need to solution to be incredibly secure, prioritising on convenience for this use case.
do seem somewhat at odds with each other.
First, you really should spend some time to think about your threat model. Are you mainly concerned with theft of the physical device, or are you concerned with attacks through a network while your system is up and running, or are you concerned about attacks by a motivated adversary who is targetting you specifically and have the ability to repeatedly gain physical access to your systems, or what?
For most people, the two biggest threats to be considered tend to be:
- data loss, due to media errors and similar conditions ("hard disk crashes"), and
- loss of control of data, e.g. due to theft of a system that has been shut down
The first point is easily handled by making regular backups and verifying that they are restorable. Encryption can add an additional layer of complexity to this, but don't fundamentally change much of anything; for example, with encryption in the picture, you need to consider how you'd handle the case where you lose the decryption key and/or passphrase.
The second point is basically what full disk encryption is designed to solve.
So you should probably look at full disk encryption (FDE) solutions. I will specifically refrain from recommending specific products, but there are choices available for all major operating systems.
That way, you will (though the terminology tends to vary slightly) "open" a "container" (which requires you to provide the corresponding passphrase or similar), use your data however you like, and then "close" the container which renders the data inaccessible without the passphrase associated with the container.
Every time you store something on a computer, even if you delete it afterwards, unless special measures are taken, some or all of the data actually remains. This is data remanence, and it is a big enabler of digital forensics. If all you do is click "delete" in the user interface and maybe empty the trash, then the data will very likely remain trivially recoverable using off-the-shelf tools that anyone can download and use, or buy for a few tens of dollars.
If you use full disk encryption properly (for example, not copying the data to an unencrypted location), then while the data will still be on disk, it will be so in encrypted form. That way, even if someone is able to analyze what's written to the storage media, unless they happen to know the passphrase they won't be able to figure out the meaning of the data.
The upside of it is that while you are using the data, you won't really have to think about the fact that it's encrypted at all; it just is.
You can still do something like your homegrown GnuPG encrypt/decrypt scheme if you want to, and for some files it can even make sense to do so to protect against an online attack. (An "online" attack, in this context, is for example someone who is able to trick you into executing code of their choosing which copies files off of your system while the encrypted container is opened thus enabling plaintext access.)
tarhas nothing to do with compression... (well, some versions do have options to compress built-in, but they're just equivalent to piping thetaroutput throughgzipor similar :) )