similar to: rsync remote raw block device with --inplace

> There have been addons to rsync in the past to do that but rsync really > isn't the correct tool for the job. why not correct tool ? if rsync can greatly keep two large files in sync between source and destination (using --inplace), why should it (generally spoken) not also be used to keep two blockdevices in sync ? maybe these links are interesting in that context:

There have been addons to rsync in the past to do that but rsync really isn't the correct tool for the job. Neither is dd. The right tool is something that understands the filesystem within the block device such as ntfsclone (what I use) or partimage (if you have ever used Clonezilla this is what it uses). These will know how to skip all the empty parts of the filesystem and will still be

It was broucht up before indeed: https://lists.samba.org/archive/rsync/2012-June/027680.html On 12/30/18 9:50 PM, devzero--- via rsync wrote: >> There have been addons to rsync in the past to do that but rsync really >> isn't the correct tool for the job. > why not correct tool ? > > if rsync can greatly keep two large files in sync between source and destination >

More notes about diskrsync <https://github.com/dop251/diskrsync> : (0) It seems to work well and efficiently. The README.md now explains how to install it and it's a lot easier than the script I included in my last note would seem to indicate. (I didn't and still don't know Go.) (1) Effectively, inherently, and non-optionally, diskrsync has rsync's --inplace feature. IOW,

>- --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 only thing they can do is add the >possibility of incomplete or corrupt copies on

Hi I'm having issues sendig a lot of tar.gz backup files to a ZFS remote filesystem server. This files are compressed with the --rsyncable option. Sending without --inplace option rsync works well and send only the differences, but to create a temporary file and rewrite the file destination, zfs snapshots contain the full size of the backup, not only differences block. I've tried

Hi all, >From the manpage of rsync, I can see the following descriptions: --inplace The option implies --partial (since an interrupted transfer does not delete the file) So I do the following testings on the `--inplace' and `--partial' for resuming a file with the following steps: 1- rsync ftp.cn.debian.org::debian/dists/wheezy/main/binary-amd64/

Hi. This is bug report and simultaneously urgent asking for help. I am trying to write my rsync wrapper script, which will create minutely snapshots of my data using --link-dest. I want this script to be robust, it should work even if I do suspend/hibernate/reboot without notifying the script about this actions, it should work if I make hard-reset of the computer and if I disconnect network. Also

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

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 have any hardlinks to old files == Askar Safin http://vk.com/safinaskar Kazan, Russia

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-000000. 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 this dir to 2014-12-01-000000. So, there never will be partial files in finished

This is OK for me. I care about file contents, not metadata. == Askar Safin http://vk.com/safinaskar Kazan, Russia

>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 and without --link-dest, --inplace, --append-verify? What is benefits? Even metadata

Hello list! How dangerous is acctually the --inplace option if you want to run rsync to update files that are only read and not written to? What is the worst that can happen? The file is not readable, the reader gets half the file of an old version and the rest is from the new version? There is not a simple way to make it update the file in the standard way and then change the ownership

There is the problem which I discribed here https://bugs.centos.org/view.php?id=12820. rsync does not break hard-link into destination if hard-link has be broken in source with option inplace. The problem remains in the latest version of rsync? -- View this message in context: http://samba.2283325.n4.nabble.com/There-is-problem-of-rsync-with-options-hard-links-inplace-tp4714872.html Sent from

https://bugzilla.samba.org/show_bug.cgi?id=5201 Summary: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode Product: rsync Version: 3.0.0 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

Hi, i have to tranfer large files each 5-100 GB (mo-fri) over dsl line. unfortunately dsl lines are often not very stable and i got a broken pipe error. (dsl lines are getting a new ip if they are broken or at least after a reconnect every 24 hours) i had a script which detect the rsync error and restart the transmission. this means that if a file has transfered e.g. 80 % i start again from

https://bugzilla.samba.org/show_bug.cgi?id=11651 Bug ID: 11651 Summary: Can we allow --inplace and --sparse to coexist when --whole-file is in play? Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: core

These responses have been very useful. Thanks especially to *Roland* devzero at web.de <rsync%40lists.samba.org?Subject=Re%3A%20Aw%3A%20Re%3A%20rsync%20remote%20raw%20block%20device%20with%20--inplace&In-Reply-To=%3Ctrinity-177d08a5-29f5-475c-916b-85273fc31962-1546203055586%403c-app-webde-bs15%3E>because...I'm installing diskrsync <https://github.com/dop251/diskrsync> . So

Hi! As I commonly spell --inplace as --in-place, I'd like to suggest this simple patch: commit 5689f99b702788044a45e13582559832cf986328 Author: Jan-Benedict Glaw <jbglaw at lug-owl.de> Date: Wed Jun 26 22:49:31 2019 +0200 Allow "--in-place" as an alternative option name for "--inplace". diff --git a/options.c b/options.c index e5b0cb68..7ff0c51d 100644 ---