borgbackup
lost borg key - lost access?
Have you checked borgbackup docs, FAQ, and open GitHub issues?
Yes
Is this a BUG / ISSUE report or a QUESTION?
Question
System information. For client/server mode post info for both machines.
Your borg version (borg -V).
1.2.6 ( not completely sure if I was using this exact version when creating the backups )
Operating system (distribution) and version.
Ubuntu 22.04
Hardware / network configuration, and filesystems used.
None
How much data is handled by borg?
The repo itself is 3.792 TiB
Full borg commandline that lead to the problem (leave away excludes and passwords)
None
Describe the problem you're observing.
Good morning, I'm coming to you in hopes of some guidance.
I've maybe been too quick to decide to do a reinstall ( and by doing so wipe my disk ), without making sure I secured the data of <USER>/.config/borg/
I'm trying to regain access to my backup repo, I still have the SSH Key and Password, along with the following information:
export BORG_RSH='ssh -i /root/.ssh/id_rsa'
and
export BORG_PASSPHRASE='qBQR9...MASKED...fG-G'
But it seems, as so I've also read now, that I would also need ~/.config/borg/keys
I'm unable to access and get the following error:
No key file for repository ssh://[email protected]:23/./backups/server found in <USER>/.config/borg/keys
The message is right, as I've re-installed and didn't think about making a backup / export of this. Am I able to recover my data with only the passphrase and ssh key? If so, I've been unable to do so, and might need some guidance.
I've came across https://github.com/borgbackup/borg/issues/4236 and this is the config file's content, there's no key related information there unfortunately about a key.
uNNNNNN /home/backups/server > cat config
max_segment_size = 524288000
segments_per_dir = 1000
version = 1
[repository]
id = a6e7fafb6a9558572108a77c2ef83095b80410c467e2e41fbb63c87b61b68338
additional_free_space = 0
storage_quota = 0
append_only = 0
total 627987
uNNNNNN /home/backups/server > ls -lha
drwxr-xr-x 4 uNNNNNN uNNNNNN 4B Oct 3 19:27 ..
drwx------ 3 uNNNNNN uNNNNNN 8B Dec 2 07:53 .
drwx------ 165 uNNNNNN uNNNNNN 165B Nov 20 16:36 data
-rw------- 1 uNNNNNN uNNNNNN 209B Dec 1 22:29 config
-rw------- 1 uNNNNNN uNNNNNN 73B Dec 1 22:29 README
-rw------- 1 uNNNNNN uNNNNNN 190B Dec 1 21:12 integrity.162769
-rw------- 1 uNNNNNN uNNNNNN 164M Dec 1 21:12 index.162769
-rw------- 1 uNNNNNN uNNNNNN 193M Dec 1 21:12 hints.162769
-rw------- 1 uNNNNNN uNNNNNN 16B Dec 1 20:35 nonce
So i've tried creating a new remote repository, on another folder along side the 'server' repo called 'laptop', with the same passphrase:
export BACKUP_USER="uNNNNNN"
export REPOSITORY_DIR="laptop"
export REPOSITORY="ssh://${BACKUP_USER}@${BACKUP_USER}.your-backup.de:23/./backups/${REPOSITORY_DIR}"
borg init --encryption repokey ${REPOSITORY}
Enter new passphrase:
Enter same passphrase again:
Do you want your passphrase to be displayed for verification? [yN]: y
Your passphrase (between double-quotes): "qBQR9...MASKED...fG-G"
Make sure the passphrase displayed above is exactly what you wanted.
By default repositories initialized with this version will produce security
errors if written to with an older version (up to and including Borg 1.0.8).
If you want to use these older versions, you can disable the check by running:
borg upgrade --disable-tam ssh://[email protected]:23/./backups/laptop
See https://borgbackup.readthedocs.io/en/stable/changes.html#pre-1-0-9-manifest-spoofing-vulnerability for details about the security implications.
IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo!
If you used a repokey mode, the key is stored in the repo, but you should back it up separately.
Use "borg key export" to export the key, optionally in printable format.
Write down the passphrase. Store both at safe place(s).
And copying over that folder:
cp -a <USER>/.config/borg/security/NEWID <USER>/.config/borg/security/a6e7fafb6a9558572108a77c2ef83095b80410c467e2e41fbb63c87b61b68338
But that still leaves me with a empty 'keys' folder, even after creating the 'laptop' repo, what am I missing?
If there isn't a key (file), neither locally, nor in repo/config of the backup repo, then how to proceed?
uNNNNNN /home/backups > cat server/config
[repository]
version = 1
segments_per_dir = 1000
max_segment_size = 524288000
append_only = 0
storage_quota = 0
additional_free_space = 0
id = a6e7fafb6a9558572108a77c2ef83095b80410c467e2e41fbb63c87b61b68338
uNNNNNN /home/backups > cat laptop/config
[repository]
version = 1
segments_per_dir = 1000
max_segment_size = 524288000
append_only = 0
storage_quota = 0
additional_free_space = 0
id = ae2271e0bab62801da330baf01035f3d700ab2491f1da6a301bb0c0a2e5de1c2
key = ...MASKED...
...MASKED...
...MASKED...
...MASKED...
...MASKED...
...MASKED...
...MASKED...
How can I then access the repo with 'just' the passphrase and ssh key? As there seems to be no 'borg key'.
Any help is much appreciated.
Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.
No, see explanation above.
So after searching a bit more, I came across https://superuser.com/a/1588896 and I'm unsure if I previously used repokey or keyfile, but based on creating another test repo 'laptop2' with 'keyfile' I reckon I've used that, as that creates a file in the 'keys' folder.
Is there any way I can re-create the uNNNNNN_your_backup_de__backups_server contents, or am I screwed?
Since I thinks it's the latter, i've powered down my dedicated server at hetzner, for the sake of hopefully being able to recover data, but by re-installing I already wiped the disk so will need recovery software I guess to make any chance. Any tips on recovery software? Hetzner themselves don't have any services to offer that help me on this.
Bad news:
Considering that you did not see the key in the repo/config file, it looks like you used --encryption keyfile (not: --encryption repokey) when creating the repo. Thus, the key was in your client's home directory.
If that was the only client accessing this repo, that means "game over" because you have lost the key.
If you access the same repo from another client also (which means using the same key), you can get it from there.
Some background:
When initializing a repo, borg creates some fully random key material (includes: AES encryption key, authentication key, ID key, chunker secret) and stores it either into the key file (home dir) or into the repo config.
To protect that (secret) key material, the key material is encrypted using AES and your passphrase (similar like how you can protect a ssh key with a passphrase).
That's why borg create tells you to make a backup of passphrase AND key.
What you can try is to locate the borg key in the blocks of your client's storage device (SSD or HDD).
As you have reformatted your storage, the key is not present any more as a file, but as long as the storage block does not get overwritten (or discarded), the key file's contents might be still visible there.
It is important that you stop working on that storage (stop having it mounted rw), because every write access might overwrite the key (in case that did not already happen when wiping / reinstalling OS).
So you need a tool that searches raw disk sectors for the magic string seen in borg key files. If you find something, check if it is for the correct repo ID.
A borg keyfile has contents like this (just example values from a temp repo in keyfile mode):
BORG_KEY ecd99b09a71f7a459d736f40b4707aa902cf2cd103739cb82a44c51ac0869eb3
hqlhbGdvcml0aG2mc2hhMjU2pGRhdGHaAN6o7BJp+YPYng2EwQnuaMARd4gDHMlmJZEEqw
qY4EuX/Pp76Atr6ldT4AsVI4rCi5AjjtRBZVucg7mAiUVsmNmO6ZmtIB4Plcls0MjedswM
NpctphjXk8gBjHeklcVQ+6pPrajO416oNoIf2p2yns1wX7Jt1WKiQcdtjt0swr0QXNBPwD
SdQ18xcwsez0HSwOQOrRvFANuTKxUIBk0GBGMilUCvVzeEEmBVyu1i4JUWdlbVDgt1ebaO
UPO1KBfhxFBXRJpQjWWHmZKrPw/3BjH2N43T1Q/vkgwYLOxpqHKkaGFzaNoAILhNqWFsnc
Dx3JNmapEs+eQNzcvddIwugrr6Xky8glIfqml0ZXJhdGlvbnPOAAGGoKRzYWx02gAgQkGi
1Xne5ye9DjahHwFOt46tLmq47q+ovqeyfcysOjGndmVyc2lvbgE=
Notable:
- file length was 553 bytes in my case
- file always starts with BORG_KEY
- after BORG_KEY, there is a blank and then the ID of the repo the key belongs to (ecd99...9eb3)
- after that, there is a long random string (hqlhb...bgE=) with the encrypted key material
- there is a 0x0A linefeed char after each line of the key material
Thanks for your detailed replies @ThomasWaldmann greatly appreciated! I'll attempt to recover the file contents. So far, I haven't had success yet but have asked help on Reddit, so I've crossed my fingers.
- https://www.reddit.com/r/datarecovery/comments/189ayd9/recover_important_data_after_reinstallation/
- https://www.reddit.com/r/DataRecoveryHelp/comments/189aygn/recover_important_data_after_reinstallation/
What I said above is only useful if the SSD controller did not get a command to trim / discard the relevant block(s).
I am not really familiar with the SSD commands issued by the usual tools used for partitioning, raid device and filesystem creation. IF they issued such commands, you might be completely beyond recovery.