Giving up after 5 attempts. Error opening file No space left on device

Asked by Luis Eduardo Ferro Diez on 2021-01-06

Hi team,

After several attempts, Déja Dup keeps failing to back up my files and is always giving me a message like this:

Giving up after 5 attempts. Error: Error opening file “/mount/path/to/external/drive/duplicity-full.20210106T015407Z.vol2.difftar.gpg”: No space left on device

I have plenty of space on my external device so I have no idea why I'm receiving this message. Also, I have several previous backups in this drive, so this is failing right now.

I have an automatic daily backup schedule, with automatic deletion every 3 months and backing up my home folders with some exclusions configured. I've had this configuration for months and I have been backing up without problems. This error just happened now out of the blue.

I'm running on Pop OS 20.04 LTS, Backups version 42.6

Any ideas and suggestions will be appreciated

Thank you.

Question information

Language:
English Edit question
Status:
Answered
For:
Déjà Dup Edit question
Assignee:
No assignee Edit question
Last query:
2021-01-06
Last reply:
2021-01-06
Manfred Hampl (m-hampl) said : #1

What is the output of the command

df -h | grep -v loop

(you are free to redact the output as long as it is clear which the target device is for the backup)

Hi Manfred, thanks for the reply, here is the output of the command:

➜ df -h | grep -v loop
Filesystem Size Used Avail Use% Mounted on
udev 16G 0 16G 0% /dev
/dev/mapper/data-root 450G 288G 139G 68% /
/dev/sdc2 932G 672G 260G 73% /media/pop-os/LINUX ----> This is the backup device

btw, I tried once more by changing the backup location using the same drive and now it worked.

So I guess something happened with the original backup folder. I'm not sure if would work for recovery purposes though. I'll keep the old folder for some time just in case.

Manfred Hampl (m-hampl) said : #3

Apparently you have already found a solution for your problem.
The only thin that I can recommend is unmounting the /dev/sd2 device and running a file system check on it.

Michael Terry (mterry) said : #4

Luis, that's very interesting that just changing the backup location worked. I wouldn't have expected that. I am not sure what caused the original issue.

I've seen reports of that error before, but usually for a reason. There didn't seem to be a reason here.

But I'm glad that you were able to find a workaround. I'm not sure how to debug this further though, without being able to reproduce it on my end.

Can you help with this problem?

Provide an answer of your own, or ask Luis Eduardo Ferro Diez for more information if necessary.

To post a message you must log in.