setid forces a destination to be tied to a backup. This is normally not necessary unless the DESTID file was manually removed from a remote destination, or a backup directory was deleted manually without clearing the remote backup area. Be careful with this command, because it allows overwriting a remote storage area that may be in use by another backup.
If on the other hand, you have cache-size-limit set to -1 (the default), then you have a local copy of all backup files in your backup directory. If you have one destination configured, the clear command will delete files from this destination, because you still have your local copy. You could then setup a new destination later, and the backup command would transfer all files from the local backup directory to the new destination.
clear - requires a list of destinations to be cleared. This command is typically used when a destination is about to be deleted from dest.conf, so you want all the files removed first. The clear command requires confirmation before files are deleted. It will not delete files that are only located on one destination.
$ hb dest -c hbbackup load
$ hb dest -c hbbackup show
$ hb dest -c hbbackup clear mys3
The dest command needs a required subcommand, and each subcommand may need arguments. Here are some examples:
Manipulates the dest.conf file and files stored on remote destinations.$ hb dest [-c backupdir] subcommand args
For example, if you have cache-size-limit set to 0, all of your files are stored on remote destinations, and none are local. If you only have one destination setup, the clear command will not do anything, because this remote copy is your only copy. But if you have 2 destinations setup, clear will be able to clear one of them.
load - loads dest.conf from the file specified into the (encrypted) database to hide remote access credentials. If no file is specified, loads dest.conf from the backup directory. After dest.conf has been loaded into the database, the dest.conf text file is not used by HB; it can be stored with your backup key to a safe place and deleted from disk. For security purposes, it should be deleted after loading into the database. Keep in mind that since the key.conf file is stored alongside the database on the local system, it is theoretically possible to obtain the remote credentials from the database. There is nothing to be done about this, because the credentials are needed to access the remote systems. For the best security, keep an admin-passphrase set on the database (see the config command) and use a key passphrase. Unfortunately, using a key passphrase makes automated backups difficult, so there is a trade-off.
ls display a listing of all files stored at each destination
show display the dest.conf loaded into the database
sync synchronize destinations if necessary. This happens automatically at the start of every backup.
unload write the dest.conf stored in the database to the file specified, or to dest.conf in the backup directory if no file is specified, and erase it from the database.
verify does a quick check of all remote backup files, without downloading any data. This check might be a file existence test, a file size check, or a checksum verification, depending on the capabilities of the remote destination. S3, Google Storage, and B2 implement all 3 checks, most destinations implement the exist and size checks, and some only implement the exist check. If a file does not verify on a destination and there is a copy available on another destination, the verify command will transfer it to correct the file. Verify is designed to be quick, does not read any file data, and will not detect subtle changes in files. For an exhaustive check of all backup data, use selftest -v4.