When mount-point is empty Deja Dup still tries to back it up!
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Déjà Dup |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
My Fedora PC 32 uses Deja Dup (version 40.6) and it backs up my home directory. I also have a USB stick which I ask Deja Dup to back up. The back-up is set as a regular event - weekly. I don't always put the USB stick into the PC but nevertheless each week Deja Dup tries to back it up even if the USB is not present. This leads to problems on restore as the USB is not restored!
This actually happened to me but it's also a use-case too. Below is an email which I sent to the duplicity-talk list for help and advice. You should be able to work out what has happened, and you can also contact the man who helped fix the problem - Edgar, if this would help.
As he says:
'
well. how about not backing up empty mount points? not sure if deja-dup supports conditions, but running duplicity using a condition via cron would look roughly like
grep -q '/mount/srcpath' && duplicity '/mount/srcpath' scheme:
most important thing is that it'd be a separate backup set that'll only be backed up if the source is mounted!
'
-------- Forwarded Message --------
Subject: Re: [Duplicity-talk] Fwd: Re: Restoring from/to a USB stick
Date: Wed, 13 May 2020 19:05:53 +0200
From: edgar.soldin--- via Duplicity-talk <email address hidden>
Reply-To: Discussion about duplicity backup <email address hidden>
To: <email address hidden>
CC: <email address hidden>
On 13.05.2020 15:30, Andrew Wood via Duplicity-talk wrote:
> Dear Edgar (Nate/ everyone)
>
> SOLVED! The command which you suggested below worked. Thank-you so much - I was really at my wits end.
good to hear
> Now I'm wondering if there is anyway to reduce the likelihood of this happening again, or to suggest improvements/
well. how about not backing up empty mount points? not sure if deja-dup supports conditions, but running duplicity using a condition via cron would look roughly like
grep -q '/mount/srcpath' && duplicity '/mount/srcpath' scheme:
most important thing is that it'd be a separate backup set that'll only be backed up if the source is mounted!
> On the plus side: I've learned something and this email would be searchable to others which is helpful to others. I guess there is - if nothing else - a use-case here for the developers.
>
> It's slightly confusing that duplicity takes the parameter --file-to-restore when it actually restores a directory or indeed a whole volume.
yeah well that's legacy. maybe some kind soul at some point implements '--in/exclude' support for restores.
> Once again - thank-you so much for all your assistance,
de nada.. ede/duply.net
> Andrew, Oxford, UK
>
> On 13/05/2020 10:31, edgar.soldin--- via Duplicity-talk wrote:
>> On 13.05.2020 09:59, Andrew Wood via Duplicity-talk wrote:
>>> Hello Edgar/ Nate/ everyone
>>>
>>> Thanks for you help and assistance. Here's the output of the two commands as requested:
>>>
>>> 1)
>>>
>>> [awood@localhost ~]$ duplicity collection-status file://
>>> Last full backup date: Thu Mar 26 09:21:33 2020
>>> Collection Status
>>> -----------------
>>> Connecting with backend: BackendWrapper
>>> Archive directory: /home/awood/
>>>
>>> Found 4 secondary backup chains.
>>> Secondary chain 1 of 4:
>>> -------
>>> Chain start time: Tue Mar 19 08:49:48 2019
>>> Chain end time: Thu Jun 13 08:29:32 2019
>>> Number of contained backup sets: 13
>>> Total number of contained volumes: 857
>>> Type of backup set: Time: Number of volumes:
>>> Full Tue Mar 19 08:49:48 2019 692
>>> Incremental Thu Mar 21 08:45:13 2019 2
>> SNIP
>>
>> looks healthy so far
>>
>>> Found primary backup chain with matching signature chain:
>>> -------
>>> Chain start time: Thu Mar 26 09:21:33 2020
>>> Chain end time: Thu Apr 30 09:36:18 2020
>>> Number of contained backup sets: 7
>>> Total number of contained volumes: 1187
>>> Type of backup set: Time: Number of volumes:
>>> Full Thu Mar 26 09:21:33 2020 884
>>> Incremental Thu Apr 2 09:23:45 2020 1
>>> Incremental Thu Apr 9 09:49:48 2020 1
>>> Incremental Thu Apr 16 11:53:39 2020 1
>>> Incremental Mon Apr 20 13:37:06 2020 292
>> the above looks like suddenly there was a lot more to backup. maybe the stick was reattached? it actually seems to be the date we are listing files from. note 2020/04/21 is between the backup's date and the next one's.
>>
>>> Incremental Thu Apr 23 09:20:53 2020 1
>>> Incremental Thu Apr 30 09:36:18 2020 7
>>> -------
>>> No orphaned or incomplete backup sets found.
>>>
>>> 2)
>>>
>>> duplicity list-current-files --time 2020/04/21 file://
>>>
>>> The output of this is huge 64,725 lines (using wc -l)!... shall I attach the output file? But I note that it includes references to both run/media/
>> nope, not needed. it's important if it lists the files you are missing! if so try
>>
>> duplicity --time 2020/04/21 --file-to-restore run/media/
>>
>> ..ede/duply.net
>> _______
>> Duplicity-talk mailing list
>> <email address hidden>
>> https:/
>
>
>
> _______
> Duplicity-talk mailing list
> <email address hidden>
> https:/
_______
Duplicity-talk mailing list
<email address hidden>
https:/
| Andrew Wood (andrew-w-oxford) wrote | #1 |
| edso (ed.so) wrote | #2 |
| Changed in deja-dup: | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
just to make it clear. i am not sure that this qualifies as a bug. backing up a filesystem with mount points in that might or might not be populated is inherently error prone.
the proper strategy here would be to back up those mount point separately! can Deja-Dup check if some file system is mounted before doing a backup should be the question asked here.
..ede/duply.net
ps. hi Mike:)