On Mon, Nov 19, 2018 at 09:50:12AM -0800, Rick Thomas wrote: > > > > On Nov 18, 2018, at 7:31 PM, Reco <recovery...@enotuniq.net> wrote: > > > > On Sun, Nov 18, 2018 at 11:56:27AM -0800, Rick Thomas wrote: > >> > >>>> On 11/14/18, Reco <recovery...@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 <recovery...@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
