For the OP, there is no backup-id or similar, and the database is deliberately nit storing the destination information. You can look at the paths being backed up, and try to match them.
For storing the config remotely, we discussed this in our old Slack channel (sadly not public).
It is technically possible to store it, and there is support in the code for reading and writing extra “control files”, which was meant to store this.
But, the most important information to store is: passphrase and serverurl (including credentials).
Before you can retrieve the data, you need that exact information. In other words, storing the config would allow you to retrieve information you have already supplied.
You could also restore more, like filters, source paths, settings and the local dbpath. But these relate primarily to the machine where the backup was created, and may or may not make sense on another machine. Since I think you would want to restore the config on another machine (after a crash or similar) I don’t see the benefits. If you have a use-case where it makes sense, I will reconsider.
We also discussed storing all backup configs in every backup. That way you would only need to know one set of information, and get back your entire setup. This would make sense, but you are also exposing your config data on multiple destinations. If you mess up in one (e g. weak passphrase) you expose everything (i.e. logon credentials to other machines). Also the “new machine, different settings” argument also applies here.
We could not find a great way to implement/communicate this feature, so we skipped it.