No! TKLBAM stores backups in the cloud for convenience, but it also supports local / custom backup storage targets.
There are two main alternatives to letting TKLBAM store a backup in the cloud:
Low-level tklbam-backup --dump option: lets you dump the raw TKLBAM backup extract to a directory, which you can then store anyway you like.
For example here's how we'd a system backup into a simple unencrypted tarball:
cd /tmp mkdir mybackup tklbam-backup --dump=mybackup/ tar jcvf mybackup.tar.bz2 mybackup/
And later restore it like this:
cd /tmp tar jxvf mybackup.tar.bz2 tklbam-restore mybackup/
The --dump option bypasses Duplicity, which usually create a series of encrypted archive files that can be incrementally updated. These archive files are stored by default in the Amazon S3 storage cloud but you can override this with the --address option and specify any storage back-end supported by Duplicity (e.g., local directory, rsync over ssh, ftp, sftp, etc).
High-level tklbam-backup --address option: lets you specify a custom backup target URL that is passed on to Duplicity.
It is highly recommended to rehearse a trial restore. Testing your backups is always a good idea, and even more so with a custom --address as this may complicate usage.
The Hub normally helps you manage your backup's metadata when it auto-configures the storage address. If you specify a manual address you need to manage storage locations, encryption keys and authentication credentials by hand.