Re: how to backup to an encrypted usb drive? [OT: rsync metadata]
On Mon, Nov 19, 2018 at 09:50:12AM -0800, Rick Thomas wrote:
>
>
> > On Nov 18, 2018, at 7:31 PM, Reco <recoverym4n@enotuniq.net> wrote:
> >
> > On Sun, Nov 18, 2018 at 11:56:27AM -0800, Rick Thomas wrote:
> >>
> >>>> On 11/14/18, Reco <recoverym4n@enotuniq.net> wrote:
> >>>>> If you're content with losing all this metadata in your backup - there
> >>>>> are rsync, cpio or tar. Or all those ‘backup solutions' based on those.
> >>
> >>>> On Wed, Nov 14, 2018 at 12:52:57PM -0500, Lee wrote:
> >>>> Do I need all that metadata? This is for me at home so it's pretty
> >>>> much a single user machine.
> >>
> >>> On Nov 14, 2018, at 10:26 AM, Reco <recoverym4n@enotuniq.net> wrote:
> >>> That's for you to decide. I'd say you definitely need it for the backups
> >>> of / and /var and can *probably* skip it for /home, but YMMV.
> >>
> >> Don’t the options for rsync -aAHX preserve all the metadata? Is there something besides
> >
> > Yep, there is at least one thing rsync looses along the way:
> >
> > # chattr +i /bin/ping
> > # rsync -aHAX /bin/ping /tmp
> > # lsattr /bin/ping
> > ----i--------e--- /bin/ping
> > # lsattr /tmp/ping
> > -------------e--- /tmp/ping
>
> Fascinating…
> 1) Are there any other extended attributes that are not copied by
> rsync? Or is there something special about “immutable”.
Rsync should ignore any extended attribute listed at chattr(1) save for
'e'.
> 2) Is this a bug or a feature?
Rather a lack of implementation. Some may consider it a bug, but rsync
behaved like this for may years - see [1], for example.
> Should there be a bg report filed on this phenomenon?
Probably. The question is - who's going to write a patch that implements
such feature?
> If not, should it be documented in the rsync(1) man page? Does that need a bug report?
Yes, definitely. But then again, chattr(1) is it's filesystem-specific.
In Debian it's customary to document cornercases in README.Debian, not in manpage.
Reco
[1] https://lists.samba.org/archive/rsync/2011-February/026039.html
Reply to: