[prev in list] [next in list] [prev in thread] [next in thread]
List: rsync
Subject: Re: excluding changed or deleted files from --backup
From: Wayne Davison <wayned () samba ! org>
Date: 2014-01-30 17:23:27
Message-ID: CAHSx_Su6pvsqyo3KzRe9uiWkBkr3x173bXZWRAqHLJn3mqT4-g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jan 30, 2014 at 6:06 AM, Helmut Schweinzer <hel@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..
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 30, 2014 \
at 6:06 AM, Helmut Schweinzer <span dir="ltr"><<a href="mailto:hel@softpoint.de" \
target="_blank">hel@softpoint.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Is \
there a way to exclude files only from the --backup option (e.g. --backup-exclude or \
--backup-exclude-from)?<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But \
this is difficult on a remote rsync server.<br>
</blockquote><div><br></div><div>Starting with 3.1.0 you can delete a specific file \
on a remote rsync daemon with this idiom:</div><div><br></div><div>rsync \
--delete-missing-args non-existant-filename host::module/backup/path/file</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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?<br>
</blockquote><div><br></div><div>You have to configure it into your rsync module in \
the daemon's config file. For safety reasons that can't be specified \
remotely.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Anyway it unnecessarily would consume resources to first make the backup to \
backup-dir and the delete the files.<br></blockquote><div><br></div><div>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.</div>
<br clear="all"><div>..wayne.. </div></div></div></div>
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic