I have searched for this topic on the mailing list and on Google without finding anything. Is this already a well known issue? The problem is that rsync does not preserve ext2-4 attributes (even when using the -a, -A, and -X flags). Note that these are different from extended attributes: Extended attributes are manipulated using programs such as getfattr and setfattr (on Unix-like systems), whereas ext2-4 attributes are manipulated by programs such as lsattr and chattr. These attributes include features like "don't update atime" or "immutable". Here's an example (run as the superuser, so permissions aren't an issue). A file x has no special attributes, then the "i" attribute is added and verified to be present. rsync then copies x to y, but the "i" attribute is not set for y: # lsattr x --------------e---- x # chattr +i x # lsattr x ----i---------e---- x # rsync -a -A -X x y # lsattr y --------------e---- y What is the reason for this behavior? Is there any way for rsync to preserve these attributes? If not, how can rsync be used to make a reliable complete system backup? Thanks, Alan Stern
On Fri, Dec 13, 2019 at 7:44 PM Alan Stern via rsync <rsync at lists.samba.org> wrote:> What is the reason for this behavior? Is there any way for rsync to > preserve these attributes? If not, how can rsync be used to make a > reliable complete system backup?[I'll touch only the "reliable complete system backup" topic.] For backups I regularly use `rdiff-backup` and `rsync` depending on the occasion. (`rdiff-backup` mainly for "regular usage" file-systems, meanwhile `rsync` for archival purposes, or "snapshots".) However, besides relying on them I always create an MD5 sums file before doing the backup, and copy that file as part of the backup. Also if I care a lot about the file-system meta data (i.e. anything besides the file name and file content), I employ a different tool depending on the occasion: * usually a simple `find` with proper `-printf` usage (including `%U %G %T@ %n %i %l`, etc.) which can help afterward easily recover meta-data or hard-links, etc.; * alternatively `rdup` can be used for this purpose; * any other tool that outputs the meta-data in machine-readable format; I do this because the file-system meta-data is so "brittle" that it can easily be "mangled" by even the simplest commands. Also, I don't know of any usage of such attributes. (Are you encountering an actual real-world use-case?) In fact I'm glad that `rsync` doesn't touch the immutable attribute, as such if I know that a certain folder was not touched, (and given that after a backup I always mark the backup files as immutable), it can serve as a fail-safe. Ciprian.
On Tue, 17 Dec 2019, Ciprian Dorin Craciun wrote:> On Fri, Dec 13, 2019 at 7:44 PM Alan Stern via rsync > <rsync at lists.samba.org> wrote: > > What is the reason for this behavior? Is there any way for rsync to > > preserve these attributes? If not, how can rsync be used to make a > > reliable complete system backup?> Also, I don't know of any usage of such attributes. (Are you > encountering an actual real-world use-case?)No, this was a theoretical question (thank goodness). I can easily understand that dealing with filesystem-specific attributes might be very difficult. They are going to be different for different kinds of filesystems, and some of them could make rsync's job a lot harder (for instance, if rsync needs to update an immutable file). Still, it was surprising to see that rsync apparently ignores the subject altogether. Alan Stern> In fact I'm glad that `rsync` doesn't touch the immutable attribute, > as such if I know that a certain folder was not touched, (and given > that after a backup I always mark the backup files as immutable), it > can serve as a fail-safe. > > Ciprian.