When do the .cache/deja-dup get invalid/cleaned?

Asked by David Ayers

I'm using deja-dup on 12.04 on with daily backup and I have just noticed that I have 3 folders in the cache:

ayers@schiefer:~$ du -sh .cache/deja-dup/* && ls -l .cache/deja-dup/
441M .cache/deja-dup/4821f7b1f2c2c856dd306719d654d1f8
169M .cache/deja-dup/59f039f970b8e0889dd476d5c8cb876a
46M .cache/deja-dup/d53f1700dabc00573d7410fd2ef925cd
insgesamt 20
drwxrwxr-x 2 ayers ayers 4096 Jul 25 07:05 4821f7b1f2c2c856dd306719d654d1f8
drwxrwxr-x 2 ayers ayers 12288 Dez 3 08:22 59f039f970b8e0889dd476d5c8cb876a
drwxrwxr-x 2 ayers ayers 4096 Okt 2 08:50 d53f1700dabc00573d7410fd2ef925cd

Now I'd like to know whether the 441M of the backup from July are still useful. i.e. will deleteing them increase the duration of the current daily backups? I can only restore my backups back to 2013-11-23 but maybe the files in that cache is still useful? Or should a have an anacron job delete .cache/deja-dup/<hash> directories older than a month?

Question information

English Edit question
Déjà Dup Edit question
No assignee Edit question
Solved by:
David Ayers
Last query:
Last reply:
Revision history for this message
Michael Terry (mterry) said :

That is an interesting question. Duplicity manages those directories for Deja Dup. I do know that it's *safe* to blow them away. Duplicity might just take a bit longer next backup as it downloads the ones it needs again.

Revision history for this message
David Ayers (ayers) said :

Indeed... that's why I asked.
note that I also have a:

ayers@schiefer:~$ ls -l .cache/duplicity/
insgesamt 4
drwxrwxr-x 2 ayers ayers 4096 Mai 16 2013 86af7581fa7f2d0f6b51a534ebd8de6f
ayers@schiefer:~$ du -sh .cache/duplicity/
8,0K .cache/duplicity/

so it's not clear whether it's duplicity's responsibility to clean up

I would expect that Déjà Dup would be responsible for .cache/deja-dup/

Of course I could simply create a backup, time the following backup, delete old files and time another backup and I'd get an empirical indication. But I was kind of hoping for a definitive answer.

Revision history for this message
Michael Terry (mterry) said :

Well, the answer is that future backups *will* take longer as duplicity downloads the cache files again. But it won't need all of them. So you will save some space by periodically blowing away the cache.

Duplicity keeps some cache files around that you don't *need* because they are useful for some of its operations, like listing the files in backups.

Revision history for this message
David Ayers (ayers) said :

Well actually "it depends"... I did the testing now.

And from empirical observation it seems that currently only the cache for 59f039f970b8e0889dd476d5c8cb876a was updated/recreated. Then I changed the location of the backup and a new cache directory was created. I changed the location back and the original cache was reused. So it seems the cache directory name is a hash value of the configured storage location. The caches are therefor only useful for specific storage locations and only the user can decide whether the cache can and should be deleted. Only that she is missing a discoverable UI to clean that up.

So unless the user does the gritty investigation I did (or preemptively delete all caches from time to time) she might be carrying a lot of dead weight eating up precious space.

I think it would be great if deja-dup showed the list of of caches possible with the corresponding storage locations in some applicable UI element and allows the user to delete that cache.