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.
Why can't I access TKLBAM storage buckets with other Amazon S3 tools?
TKLBAM doesn't store its data in generic S3 buckets, but in an isolated TKLBAM-specific area on S3. This means generic S3 tools such as the AWS management console, or S3Fox will not be able to access the storage buckets in which TKLBAM backup volumes reside.