similar to: possible bug with --files-from and --no-relative options

Hi List, I had a need recently to efficiently synchronise between some large LUNs (boot drive disks) at two different datacentres. Solutions like drbd and $proprietary_array_vendors_software were overkill - we only needed (wanted!) to periodically synchronise these LUNs whenever major changes were generated on the source. On the other hand however, re-sending the entire disk contents each time

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

In debian bug #493559 (http://bugs.debian.org/493559) the problem is that when requesting a file from an older version rsync, the remote server gives an error: $ rsync rsync://rsync.blackholes.us/zones/countries/countries.rbl /tmp rsync: on remote machine: -: unknown option rsync error: requested action not supported (code 4) at clientserver.c(517) rsync: connection unexpectedly closed (4 bytes

Hi, I have written a 'smallish' patch to implement the --inplace option as discussed on this mailing list at various points in the past. It makes a small modification to the sender algorithm so that it won't ask the receiver to relocate blocks from earlier in the file when running with the --inplace option. I would appreciate any testing and feedback people can provide! I

I have attached a patch that supports a new "--direct-write" option. The result of using this option is to write directly to the destination files, instead of a temporary file first. The reason this patch is needed is for rsyncing to a device where the device is full or nearly full. Say that I am writing to a device that has 1 Meg free, and a 2 meg file on that device is out of date.

Hi, I use rsync in the following way to update some remote files over a low bandwidth line: rsync -v -r -z -t -p <local dir> <user>@<host>:<dir on host> After updating from rsync 2.5.2 to 2.5.4 I noticed that modified files are always copied completely. The problem seems to be related to the new (in 2.5.3) option -no-whole-file. The global variable whole_file is

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

Hi All, Here's an rsync patch which adds an --offline flag, letting you transfer changed blocks via removable media, while still comparing checksums via the net. I expect this could be very popular for the growing number of people who want to do disk-based offsite backups, which is what I needed it for. It took me longer than I hoped, but still only several hours to work this out -- it

Hi All, I'm new to rsync usage in Mac OS X. I'm having a strange issue with -- files-from option. I'm providing the --files-from to provide a file , which contains the list of files separated by newline character , to perform backup operation. Especially in Mac OS X , particular tiff bundle files are having \r as part of the filename.When rsync reads the filepaths using delimiter

https://bugzilla.samba.org/show_bug.cgi?id=11656 Bug ID: 11656 Summary: Escaping broken with --files-from Product: rsync Version: 3.1.1 Hardware: x64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

Hi! I am doing backups from a number of machines to an rsync server. For some time I was trying to come up with a solution, which would prevent users from peeking at each other's files, which are backed up. Finally, I've hacked rsync, introducing a new option "write only" for rsyncd.conf. When set to true, this option forbids the transfers from server to the client, thus solving

Updated to current cvs without the --exclude-from - patch. This patch allows specifying a --link-dest path similar to --compare-dest except that unchanged files are hard-linked to the --link-dest path instead of producing a sparse tree. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember

I know that there are a million messages from newbies who cannot get --delete to work. This message is special. :) --delete works fine for me EXCEPT when the following two conditions are present: 1) I am using the --relative option, and 2) the deleted file is in a subdirectory of the SRC directory. Here is a demonstration of how to recreate this bug: lenny@mythtv:/tmp$ rsync --version rsync

In an effort to get my long-desired move-files functionality into rsync, I have created a version of my patch that runs as an extra pass at the end of the processing. This results in a simpler set of changes to rsync. I still think it would be nice to have incremental deletions during large transfers (as my first patch provides), but acceptance of this patch would relegate such quibbling to a

I have downloaded the source for rsync 2.5.6 and compiled it without adjusting any options, no problems. Performed a test copy of a file GT 2 GB and it failed. In the file configure I changed the line to "--enable-largefile", removed all the .o files, performed a ./configure, gmake, gmake install. Tried the test copy and again received the following error message: rsync:

I wrote a script that uses rsync a bit and wanted to use it. While testing was fine, the real life was more complicated :) Basically, my rsync command looks like that: rsync -v -azu -b --backup-dir /var/backup/files/ /var/profiles/files/ username@host:/ When I execute it where both machines have rsync 2.6.3, everything runs fine. When I execute it on a machine with rsync 2.6.6, and the remote

Run: # top # vmstat 1 # iostat -x /dev/emcpowerb 1 The latter two you can save to a file. For top, just monitor cpu usage and see if any process is hogging all of it. Colin Laird wrote: > and the fstab settings: > > # This file is edited by fstab-sync - see 'man fstab-sync' for details > /dev/VolGroup00/LogVol01 / ext3 > defaults 1 1 >

There's a rather old bug report in Debian's bug tracking system (see http://bugs.debian.org/27126) about wanting to be able to specify the maximum file size, as well as the minimum file size. Here's the text: Sometimes, it's useful to specify a file size range one is interested in. For example, I'd like to keep an up-to-date mirror of Debian, but I currently

I am trying to debug the RSYNC client and server by single stepping through them. The server seems to ok up to the point where it is waiting for the client connection. On the client side, I am having trouble finding the right options so that it will connect up to the local server with out fork() a copy of itself or trying to exec the rsh command. This is on RSYNC 2.5.5 on OpenVMS Alpha. If

Hi Guys, I''m playing with Blade 6300 to check performance of compressed ZFS with Oracle database. After some really simple tests I noticed that default (well, not really default, some patches applied, but definitely noone bother to tweak disk subsystem or something else) installation of S10U3 is actually faster than S10U4, and a lot faster. Actually it''s even faster on