Permission issue with deja-dup (Backup)

I'm posting this here because I think this issue is not really related to an issue with Backups - deja-dup.

I ran deja-dup using the Backups front end. It appears that it ran for quite awhile before having an error, because many of the files in the backup folder have today's date. Here is the error message:
Permission denied when trying to read ‘/duplicity-inc.20210211T163154Z.to.20210415T001733Z.manifest.gpg’.

The second problem may or may not be related to the first one. Whenever I start up Backups, it says that it has been 178 days or more since the last backup when, in fact, it has been a week. The backups have a weekly schedule. I'm thinking that every backup has actually failed thereby causing the count of days since the last backup to continue advancing.

If I remember correctly, Backups does not ask for the password so it must not be running with admin privileges. I just tried to verify this, but right now Backups' 'Backup right now' button is disabled.

Suggestions for my next step will be appreciated.

Can you open BackUps and click the hamburger icon on the header bar. Select "Help".
A Pop up window will open with a Manual. It has some pretty advanced instructions, including how to restore a back up manually.
Move your gaze to below the second horiz separator and to the lower Right Side: **When Everything Goes Wrong" - clickable link.
Opening that, you can scroll down to Restoring with Duplicity (terminal) and restoring by hand (More terminal).
I wonder if you can run a "Test restore" to see the condition of those backed up files.

I didn't actually find a way to test-restore. However, I did find a command to show collection status. It appears that I have good backups, but the significance of the error trying to update the manifest file is very concerning.

jim@jims:~$ duplicity collection-status file:///media/jim/Seagate2tbBU/Backups_Ryzen
Last full backup date: Thu Feb 11 10:31:54 2021
Collection Status

Connecting with backend: BackendWrapper
Archive dir: /home/jim/.cache/duplicity/ee8f18e8f0c4d943e1769ca46396e564

Found 0 secondary backup chains.

Found primary backup chain with matching signature chain:

Chain start time: Thu Feb 11 10:31:54 2021
Chain end time: Wed Apr 14 18:17:33 2021
Number of contained backup sets: 2
Total number of contained volumes: 8272
Type of backup set: Time: Num volumes:
Full Thu Feb 11 10:31:54 2021 8118
Incremental Wed Apr 14 18:17:33 2021 154

No orphaned or incomplete backup sets found.
jim@jims:~$

I found how to verify the backups ... almost, anyway. I used:

sudo duplicity verify --compare-files (plus encrypt key, etc.)

According to the docs, this results in comparing rather than copying. However, after it ran for about 10 minutes, I received a low disk space warning on root. There should have been over 60 gigabytes of space available. I aborted the verify. It had found a lot of changes in files, but it has been several days since the backup was made. Surprisingly, a lot of the changes were in wine, which I do not use. Even so, this was encouraging ... but not conclusive. BTW, the two backup sets together are a little shy of 1/2 terrabyte.

1 Like

I think I will close this issue. I just used Backups to do a full backup to a different USB mounted drive. At the end of the backup, Backups tested the backup to make sure I could restore from it. It passed this test. Also, I shutdown Backups and restarted it. It says the last backup was today ... not 182 days ago. So something weird happened to the first backup, but not to the second one. I will delete the weird one.

I think why it didn't work might be u trying to backup stuff from root, did you?

Sorry to be so slow in responding. No. At that time, I was not trying to backup /root. However, now I am trying to and it fails on the /root part only.