Re: [Duplicity-talk] Saving extended attributes

[Arjun Krishnan]

> On 29.01.2017 00:13, Arjun Krishnan via Duplicity-talk wrote:
>> Hi
>>
>> I know duplicity doesn't explicitly support extended attributes, but are 
>> there any recommended hacks for saving them? One way is to tar each file 
>> before letting duplicity encrypt and act on it. That is, can duplicity be 
>> configured to run
>>
>>   tar --xattrs cvf filename.tar filename
>>
>> on each file that it backs up? I suppose I could do this manually before 
>> running duplicity. I'm saving a bunch of my stuff to a cloud drive, and 
>> wouldn't like to lose extended attributes.
>>
>
> you may use duply w/ pre scripts to do that for you.
The pre script is an option. It seems like if I want to backup
/mnt/root then the prescript would have to make a tarred copy of it
that saves extended attributes, /mnt/root.tar and then runs duplicity
on that. I suppose that would take up twice the disk space, right?

Is there a way to write a duplicity backend that simply tars every
file before duplicity encrypts it, calculates deltas and then pushes
it to the remote?

> duplicity itself uses python tarfile, not the system tar binary, which seems 
> not to have xattr support out of the box.
> ..ede/duply.net
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 29 Jan 2017 02:48:39 +0100
> From: address@hidden
> To: Discussion of the backup program duplicity
>         <address@hidden>
> Subject: Re: [Duplicity-talk] restore does nothing at all
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
>
> hey Yves,
>
> that sounds unlikely. can your retry several times with and without 
> --sign-key to confirm your findings?
>
> what's you gpg version? it's possible that gpg changed something when a sign 
> key mismatch is detected.
>
> ..ede/duply.net
>
> On 28.01.2017 20:51, Yves Goergen wrote:
>> I didn't get to do that monitoring yet, but I did something else: I removed 
>> the --sign-key argument from my script that calls duplicity. This got rid of 
>> the signing key warning and completed the restore as expected within a 
>> minute or two.
>>
>> So something is wrong either with the sign key detection, or with sign key 
>> usage in a past backup. Ignoring sign keys resolves the primary issue. Does 
>> that explain anything?
>>
>> Yves Goergen
>> http://unclassified.software
>>
>> ________________________________________
>> Von: edgar.soldin--- via Duplicity-talk
>> Gesendet: So, 2017-01-22 14:08 +0100
>> On 21.01.2017 17:38, Yves Goergen via Duplicity-talk wrote:
>>> Hello,
>>>
>>> I need to restore a directory from my backup. This did work a couple of 
>>> days ago, but with some warning messages. Today, I get the same warning, 
>>> but nothing happens.
>>>
>>> Here's the output I get from the restore command:
>>>
>>>> Local and Remote metadata are synchronized, no sync needed.
>>>> Last full backup date: Wed Jan 18 09:28:22 2017
>>>> Volume was signed by key D911EC2F, not 7210E89B
>>>
>>> And then nothing happens anymore. I can Ctrl+C to kill the program. No 
>>> files are restored, even after hours waiting. What can I do?
>>>
>>> My duplicity version is 0.7.06 on Ubuntu 16.04.
>>>
>>
>> 1.
>> start the restore again and monitor system usage using top or similar. is 
>> duplicity stalling or using up your system memory, leading to paging by any 
>> chance?
>>
>> 2.
>> easiest workaround would be accessing your backup from another machine and 
>> see if you can restore there.
>>
>> ..ede/duply.net
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>
> ------------------------------
>
> End of Duplicity-talk Digest, Vol 165, Issue 6
> **********************************************