Hello I’m from Brazil! I’m using the fedora 35 distribution and I’m trying to restore my last file backup made to my “EXTERNAL HD”. Before moving to fedora 35 I was using the POP-OS distro and using this program “Deja-Dup” to do the backup. After starting to use fedora 35, the program asked when restoring the files for the password of the last backup it had made. But I didn’t use any password to encrypt my files. I went to test in another distro and ended up coming across this message: “Failed due to an unknown error”.
Searching forum and community. I saw that this “DEJA_DUP_DEBUG=1 deja-dup” gives us more details about the error message. After using it in the terminal, it shows this here at the end:
DUPLICATE: INFO 1 DUPLICATE: . Using temporary directory /home/rafaelkoppe/.cache/deja-dup/tmp/duplicity-ikavd78h-tempdir
DUPLICITY: ERROR 30 AssertionError DUPLICATE: . Traceback (innermost last): DUPLICATE: . File “/usr/bin/duplicity”, line 87, in DUPLICATE: . with_tempdir(main) DUPLICATE: . File “/usr/bin/duplicity”, line 70, in with_tempdir DUPLICATE: . fn() DUPLICATE: . File “/usr/lib64/python3.10/site-packages/duplicity/dup_main.py”, line 1577, in main DUPLICATE: . do_backup(action) DUPLICATE: . File “/usr/lib64/python3.10/site-packages/duplicity/dup_main.py”, line 1599, in do_backup DUPLICATE: . action).set_values() DUPLICATE: . File “/usr/lib64/python3.10/site-packages/duplicity/dup_collections.py”, line 750, in set_values DUPLICATE: . self.get_backup_chains(partials + backend_filename_list) DUPLICATE: . File “/usr/lib64/python3.10/site-packages/duplicity/dup_collections.py”, line 877, in get_backup_chains DUPLICATE: . add_to_sets(f) DUPLICATE: . File “/usr/lib64/python3.10/site-packages/duplicity/dup_collections.py”, line 865, in add_to_sets DUPLICATE: . if set.add_filename(filename, pr): DUPLICATE: . File “/usr/lib64/python3.10/site-packages/duplicity/dup_collections.py”, line 117, in add_filename
*DUPLICATE: . assert pr.volume_number not in self.volume_name_dict, * DUPLICATE: . AssertionError: Volume 4 is already in the volume list as “duplicity-full.20220201T144945Z.vol4.difftar”. DUPLICATE: . “duplicity-full.20220201T144945Z.vol4.difftar.gz” has the same volume number. DUPLICATE: . Please check your command line and retry. DUPLICATE: .
Note: if you can help me, I’d appreciate it, because the files that are in backup format on my external hard drive are very important to me.
I was able to solve my problem using the fedora 35 installation, keeping the hostname and username the same when using the POP-OS distribution. Sometimes when we encrypt some data it is only decrypted if the hostname, user name and user password remain the same.
When I restored the files, the same machine name, username and password managed to capture the files that I backed up in the Deja-dup program with the oldest distribution! I’m pretty sure the vast majority of people have this problem when going from system to system. In this case, the program should know that even though it has changed systems with the same or different name, it should know that the files it has saved can identify the files with different machine names, usernames and passwords when using a different Linux distribution. I agree with you that this report should be forwarded! Then do a very simple test, make a backup of a file and when you restore it try to do what I did with a different machine!
A) It sounds like you got your files restored? Yay!
B) The original problem with the error about a “duplicity-full.20220201T144945Z.vol4.difftar” file has to do with duplicity seeing two copies of the volume file - one compressed and one not compressed. I seem to recall some old reports of similar issues, I think fixed by clearing a cache or deleting a duplicate file. I don’t remember the root cause.
C) What are the comments about host names? Duplicity does record the host name in the backup files, but only as an advisory thing - to caution about backing up on top of a set of backup files from another machine. You’ll see a little pop up asking if you want to continue when using Deja Dup if that happens. The host name is not used as part of the encryption, and I don’t believe it’s used at all during restore. Are you saying that you’ve seen restores fail because of the host name?
C) I’ve seen it this way even causing file recovery failure due to hostname (machine name). Remembering if you want to restore the old backups by deja-dup, the hostname, username and user password must be the same as the previous backup you made on the previous system. If by chance it doesn’t work, it means that some of these 3 items don’t identify the previous backup.
Well, when I restored without changing the hostname, it asked for the encrypted password, the problem is that when doing the restoration it asks for a password to decrypt the files from the old backup, this I have not done with a password, it must probably keep a random password . I can be sure it’s not just the hostname, but it also includes the username and the user’s password to identify this encrypted password.
You absolutely should not need to match the username or host name when restoring. If you experienced that, it is a huge bug and not intended behavior. I’d love to dig into what happened there, as that would be a critical bug in core functionality.
But the issue you hit sounds like an unexpected password being required? (ie the backup being encrypted when you did not expect it to be) - also a big issue, but there are some old bugs that might have led you down that road.
Though it sounds like everything is working now for you. But next time you experience that, I’d love a new ticket to dive into what’s happening for you.
Okay, next time I’ll report back if something similar to this happens to you to try to delve into the problem I’m having.
Yes, I experienced this bug, as it asked for the necessary password without me having backed up the old ones. I had to resort to the machine’s username or host because it was the only alternative I had to restore my old files.