-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/26/2014 09:56 PM, Askar Safin wrote:
>> I mean instead of having --link-dest=previous_backup and the
>> target being empty (or starting that way in your case) you cp -al
>> the prevous_backup to the new "incomplete" one. Now you have a
>> tree f
>I mean instead of having --link-dest=previous_backup and the target
>being empty (or starting that way in your case) you cp -al the
>prevous_backup to the new "incomplete" one. Now you have a tree full
>of all hard links. Now you can rsync to the target without any
>- --link-dest reference.
I me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I mean instead of having --link-dest=previous_backup and the target
being empty (or starting that way in your case) you cp -al the
prevous_backup to the new "incomplete" one. Now you have a tree full
of all hard links. Now you can rsync to the target
>BTW, if you want it to always have that behavior (it can save a lot of
>backup space) you can use the old cp -al method instead of --link-dest
>so that the target dir starts out completely populated.
You mean making "cp -al" on the remote and then start rsync to newly created
dir with --partial a
This is OK for me. I care about file contents, not metadata.
==
Askar Safin
http://vk.com/safinaskar
Kazan, Russia
--
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: htt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, I was just making sure that you understood that.
BTW, if you want it to always have that behavior (it can save a lot of
backup space) you can use the old cp -al method instead of --link-dest
so that the target dir starts out completely populated.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am talking about metadata. Permissions, ownerships, etc. If a link
exists in the target and needs a metadata change then rsync will do a
chmod, chown, whatever which updates all the instances of the file.
If there hadn't already been a link there r
No. Now there is no --inplace. So, rsync will never write new file directly
into old one (without unlinking). If there already is old file and it needs
updating, then rsync will write into something like .file-He4gw, and then it
will rename this file to its right name. This new file will not hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Then you still have the problem of already created links being updated.
On 12/26/2014 08:20 PM, Askar Safin wrote:
> I don't specify --partial-dir. As you can see from the script,
> rsync at first copies to "in-progress", and then renames this to
> (f
I don't specify --partial-dir. As you can see from the script, rsync at first
copies to "in-progress", and then renames this to (for example)
2014-12-01-00. So, if rsync interrupts, then at the next run the script
will end "in-progress" (all partial files will be done) and then will rename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Are you specifying --partial-dir? Seems like that would be needed or
else you will end up would end up with an incomplete copy in the
previous target?
On 12/26/2014 06:50 PM, Askar Safin wrote:
> Ok, thanks. I removed --inplace and --append-verify an
Ok, thanks. I removed --inplace and --append-verify and kept --link-dest and
--partial.
And now the script works exactly as I want: hard-links are not updated, the
script is still robust and can
copy large files over unstable links etc, etc.
==
Askar Safin
http://vk.com/safinaskar
Kazan, Russia
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, but there are issues to keep in mind...
Normally --link-dest is used to keep previous copies (to make a backup
system) and the target directory is always empty. In this mode
- --inplace and --append-verify would be irrelevant since rsync will
al
>- --inplace and --append-verify are essentially irrelevant when
>- --link-dest is in play. With --link-dest in play the target system
>must write an entirely new file even for a change in permissions or
>timestamps so any potential benefit by these options are out the
>window from the start. The
https://bugzilla.samba.org/show_bug.cgi?id=7757
--- Comment #4 from Dominic Raferd ---
I can confirm that this bug still exists when using compression (-z) with rsync
3.1.0 (server and dest), and that removing compression is a good workaround.
--
You are receiving this mail because:
You are the
15 matches
Mail list logo
