I'd been kind of concerned about running down my thumbdrive capacity life with overwriting the whole volume each backup, but judging by the 11-minute backup time for about 1.5GB of data to a 60GB drive, apparently TrueCrypt doesn't work that way. So, that's good. I also ironed out automation for backup to a file volume on another external drive. That ran even faster, like, in the time it took to brush my teeth and shave.
What I didn't do was backup my Thunderbird profile stuff, so there's something else I need to revisit. It's been a back-burner project to work up a semi-auto MySQL and apache/htdocs backup procedure as well.
Backup up htdocs is simply a matter of telling Cobian to pull that part of the filesystem into its archives. That's really just waiting for review and cleanup of a few weighty try-out things like OpenDocMan, TaskFreak and CodeIgniter.
MySQL provides the mysqldump command-line tool. In a Windows environment you can wrap it in a batch file so as not to have to locate the mysql/bin directory and type out command-line parms every time. In a *nix environment I assume you'd do something comparable with a shell script. Note how we leave the password parm empty, so mysqldump prompts at runtime to enter a password, and it provides input masking at the command line. So, from a security standpoint there's no call for exposing your password, neither hard-coded in the batch script code nor as a command line parm for the batch file.
C:\xampp\mysql\bin\mysqldump -uroot -p --all-databases > mysqlbackup.sql
Probably the most flexible and available Windows-based command-line tool to compress and encrypt in one pass is 7-Zip's command-line version, 7za. The big question at this stage is, how secure is 7-Zip's encryption? According to this article, the crypto strength is highly dependent on password length. In a dev environment working only with sample data, a password of 6 or 7 characters is plenty sufficient. We don't really care if the NSA or Scotland Yard can crack our sample data open in a second.
For live customer data we'll step up to a longer password, because while Scotland Yard still wouldn't be interested, a medium-size criminal organization looking for login credentials might. And while they (probably) wouldn't have a dedicated billion-dollar cracking lab, they may likely have 10 to 100 times the resources of one small-time cracker. 20 characters is not unreasonable for an enterprise data set, although at that point you should be thinking about certificate-based crypto instead. At the least, you might run a short memorable (6-8 character) password through a hash function, to produce a well-scrambled long passphrase. MD5, for example, produces a 32-character password, which according to the aforementioned article would take decades to centuries for even the hypothetical billion-dollar NID lab to crack, assuming no access to alien quantum computing technology.