Bug 4793 - Option to use (and tweak) --link-dest files with differing attributes
Option to use (and tweak) --link-dest files with differing attributes
Status: RESOLVED WONTFIX
Product: rsync
Classification: Unclassified
Component: core
2.6.9
PPC Linux
: P3 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-16 15:38 UTC by Louis Gosselin
Modified: 2011-04-01 20:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Louis Gosselin 2007-07-16 15:38:08 UTC
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?
Comment 1 Matt McCutchen 2007-07-16 15:58:14 UTC
(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.
Comment 2 Louis Gosselin 2007-07-20 00:22:19 UTC
> 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.
Comment 3 Louis Gosselin 2007-07-20 00:25:04 UTC
> 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.
Comment 4 Matt McCutchen 2007-07-20 10:36:22 UTC
(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.
Comment 5 Matt McCutchen 2008-05-07 22:20:50 UTC
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.