excluding changed or deleted files from --backup

[Wayne Davison]

On Thu, Jan 30, 2014 at 6:06 AM, Helmut Schweinzer <hel at softpoint.de> wrote:

> Is there a way to exclude files only from the --backup option
> (e.g. --backup-exclude or --backup-exclude-from)?
>

You'd need to exclude the files from the transfer and then do a separate
rsync run that only included those files, this time without the --backup
option.  One possibility is to use --max-size for the backup transfer, and
--min-size for the non-backup transfer.

But this is difficult on a remote rsync server.
>

Starting with 3.1.0 you can delete a specific file on a remote rsync daemon
with this idiom:

rsync --delete-missing-args non-existant-filename
host::module/backup/path/file

Perhaps triggering the post-xfer option for the rsync server might be
> a solution. But can I inject a post-xfer script to the server?
>

You have to configure it into your rsync module in the daemon's config
file.  For safety reasons that can't be specified remotely.

Anyway it unnecessarily would consume resources to first make the backup to
> backup-dir and the delete the files.
>

A backup is done via either a hard-link or a rename, so as long as the
backup dir is on the same filesystem as the destination file then it is not
an expensive operation.  i.e, in a normal (non-inplace) transfer rsync
creates a temp file based on the current file, and at the end, it renames
the new file over the old one.  For a backup transfer, right before that
final rename happens, rsync tries to hard-link the destination file to
the backup file so that it is atomically replaced by the final rename (it
tries a rename if a hard-link doesn't work, and only copies the data if
that also fails).  So, unless your backup filesystem is different from your
destination filesystem, you just waste some destination disk space until
the after-copy deleting happens.

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20140130/16c09d3d/attachment.html>