rsync - Jul 2007 - DO NOT REPLY [Bug 4793] New: link-dest hardlink does not always work well with -o -g -p

https://bugzilla.samba.org/show_bug.cgi?id=4793

           Summary: link-dest hardlink does not always work well with -o -g
                    -p
           Product: rsync
           Version: 2.6.9
          Platform: PPC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: getarealname@excite.com
         QAContact: rsync-qa@samba.org


I recently rebuilt a file server. I noticed during the most recent backup that
hardlinks were not being used and I couldn't figure out why until I
discovered
rsync will not hardlink if the uids/permissions do not match. Since the server
was reinstalled from scratch, the uid's no longer line up. Also if nothing
other than permissions on a file were changed, a new copy would be created.

I reconfigured rsync to avoid using -ogp and it is working OK.

I know rsync is being designed around an ext3 limitation, however I would
prefer if there was a way to force rsync to always hardlink and then force it
to chown,chmod the files. This would make a restore operation easier and still
allow access to data from the previous backups. One obviously would have to
accept that the permissions for previous backups might be changed since that
backup took place.

Does anyone else think this would this be a useful feature to have?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4793





------- Comment #1 from hashproduct+rsync@gmail.com  2007-07-16 15:58 CST
-------
(In reply to comment #0)
> I know rsync is being designed around an ext3 limitation,
I wouldn't consider it a "limitation" that a file only has one
owner, group,
and mode no matter which hard link is used to access it.  However, allowing
identical data blocks to be shared between files would be a nice enhancement to
ext3 (or any filesystem).
> however I would
> prefer if there was a way to force rsync to always hardlink and then force
it
> to chown,chmod the files.This would make a restore operation easier and
still
> allow access to data from the previous backups. One obviously would have to
> accept that the permissions for previous backups might be changed since
that
> backup took place.
You can accomplish this yourself by filling the destination with hard-links
from the previous backup in advance using "cp -al".  You might also
consider
representing the source attributes in a separate file in the backup so that
there is no need to use -ogp.
> Does anyone else think this would this be a useful feature to have?
Hm.  I think it's odd to want to preserve attributes in the current backup
but
not care about attributes in previous backups being overwritten.  I don't
see a
strong argument for building support for this into rsync.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4793





------- Comment #2 from getarealname@excite.com  2007-07-20 00:22 CST
-------
> You can accomplish this yourself by filling the destination with hard-links
> from the previous backup in advance using "cp -al".  
I'll give this a shot.
> You might also consider representing the source attributes in a separate
file
> in the backup so that there is no need to use -ogp.
Is there a tool to save permissions and then reapply them? 
This would work for me.
> I think it's odd to want to preserve attributes in the current backup
but
> not care about attributes in previous backups being overwritten.
I honestly didn't think it that odd. To explain: When we need to restore an
entire file system due to hardware error, it will without exception be from the
last available backup. In this case it is desirable to restore all permissions. 

The main/only reason to go to older snapshots is if a user needs an older copy
of the data within one of his files where the latest backup is insufficient. In
this case we could restore the backup file over top of his current file if it
exists while keeping the current permissions (this might be preferred even if
backup permissions were available).
> I don't see a strong argument for building support for this into rsync.
Fair enough.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4793





------- Comment #3 from getarealname@excite.com  2007-07-20 00:25 CST
-------
> You can accomplish this yourself by filling the destination with hard-links
> from the previous backup in advance using "cp -al".  
I'll give this a shot.
> You might also consider representing the source attributes in a separate
file
> in the backup so that there is no need to use -ogp.
Is there a tool to save permissions and then reapply them? 
This would work for me.
> I think it's odd to want to preserve attributes in the current backup
but
> not care about attributes in previous backups being overwritten.
I honestly didn't think it that odd. To explain: When we need to restore an
entire file system due to hardware error, it will without exception be from the
last available backup. In this case it is desirable to restore all permissions. 

The main/only reason to go to older snapshots is if a user needs an older copy
of the data within one of his files where the latest backup is insufficient. In
this case we could restore the backup file over top of his current file if it
exists while keeping the current permissions (this might be preferred even if
backup permissions were available).
> I don't see a strong argument for building support for this into rsync.
Fair enough.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4793





------- Comment #4 from hashproduct+rsync@gmail.com  2007-07-20 10:36 CST
-------
(In reply to comment #3)
> Is there a tool to save permissions and then reapply them? 
> This would work for me.
The rsync source package comes with a Perl tool to reapply attributes of your
choice (permissions, user owners, and/or group owners), which you can also find
here: http://rsync.samba.org/ftp/unpacked/rsync/support/file-attr-restore . 
The corresponding attribute-saving tool is just "find . -ls".

Another alternative you might consider is using rdiff-backup (
http://www.nongnu.org/rdiff-backup/ ).  It makes a backup zone containing a
full tree of the most recent backup, a separate listing of all the original
attributes (so they are known if the attributes on the backup tree are never
set or get corrupted), and a chain of backward deltas of files and attributes
for previous backups.  The advantage is that you get data and attributes for
all backups in less space than with rsync --link-dest; the disadvantage is
that, to restore files from a previous backup, you have to go through
rdiff-backup rather than copying the files out directly.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4793


matt@mattmccutchen.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Comment #5 from matt@mattmccutchen.net  2008-05-07 22:20 CST -------
Marking the request for a hard-link-and-tweak option WONTFIX because I don't
see a need for it and Louis has an alternative solution.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.