Saving extended attributes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Saving extended attributes

duplicity-talk mailing list
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.

Arjun





_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Saving extended attributes

duplicity-talk mailing list
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.

duplicity itself uses python tarfile, not the system tar binary, which seems not to have xattr support out of the box.

..ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Saving extended attributes

duplicity-talk mailing list
In reply to this post by duplicity-talk mailing list
> 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: [hidden email]
> To: Discussion of the backup program duplicity
>         <[hidden email]>
> Subject: Re: [Duplicity-talk] restore does nothing at all
> Message-ID: <[hidden email]>
> 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>
> ------------------------------
>
> End of Duplicity-talk Digest, Vol 165, Issue 6
> **********************************************

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk