Is this a reasonable way to setup backups for security? Can it be improved?

You should use public key encryption in this scenario, when your offsite backups are stored by a third party.

This way, the machine being backed up has only its own public key, and therefore can only create backups. You store the private key offline, and use it only for restores.

Backup solutions such as Bareos already support public-key encryption, or you could fairly easily integrate it into your existing setup with GPG.

Your setup seems pretty solid - though I'm really a huge proponent of backup software for doing backups.

I'll offer you the following outline based on Bacula (and/or BaReOS):

1. On the machines being backed up
   Install the Bacula agent, and configure a machine-specific encryption certificate.
   (The decryption key need not be stored on these machines as it's only needed for restores.)
   Your backups will be initiated the same way as any "normal" Bacula backup, and will be encrypted using the specified certificate.

2. On the Bacula Director (The machine requesting the backups)
   Configure your backup schedule as appropriate for your organization (Full & Incrementals).

3. On the Bacula Storage Server (The machine the backups are written to)
   You don't have to do anything special, but it's generally good practice to either have the Storage server be off-site, or to sync the backups off-site using rsync or equivalent.

This is effectively equivalent to your outline above, only not requiring SSH access & cron jobs. In addition, you gain a few other benefits:

• It's difficult for an attacker to vandalize the backups.
  Access to one of the machines being backed up doesn't allow you to delete/overwrite backups - that's all controlled by the Director.

• It's difficult for an attacker to vandalize the machines being backed up.
  With the decryption keys stored offline an attacker can't restore data to the machines being backed up (the backup won't decrypt), so even if they have access to the Director they can't command a restore.

• Your backups are pretty secure.
  Since they're encrypted prior to leaving the source machine (and only decrypted on the target machine during restore) someone grabbing a copy of your backups is getting unusable (encrypted) data. This is more of a concern if your data is sensitive, but it also means your backup can't be tampered with (and thus can't be used to restore corrupt/malicious data to your servers if someone gets access to the storage server).

• You're using "real backup software"
  This is useful when you need to "restore that document I was working on on Thursday" - you can get that one file back without having to extract (or copy around) a whole archive.

The downside? The backup agent needs to run as root (or at least as a user who can read all the data you want to back up). The agents are pretty secure, but there's always a chance that an undiscovered flaw exists that could present a possible attack avenue.
Keep on top of your patches and you should be fine though.