similar to: how fast should rsync be?

Greetings, We manage a large farm of systems and push changes, patches, new software, etc. out to our clients using kerberized rdist. It's clunky and slow but it's got the magic of specials. Using a special one can tell rdist that if a particular file changes, preform this command. So, if we make a change to httpd.conf, we can tell rsync to bounce httpd. If httpd.conf hasn't change,

I would like to propose some improvements to rsync's filters. (1) Add a notation that makes a pattern match both a file and everything under it if it happens to be a directory. One possibility: ending a path in //. "+ mydir//" would be equivalent to "+ mydir" "+ mydir/**". Just some syntactic sugar. (2) Add a third sender behavior to "hide" and

Hello, We are experiencing flaky behavior from rsync when attempting to rsync directories/files to a server in Penang. Several times the job seems to 'hang' and never completes. Penang then is therefore missing a lot of required cad files. Have any of you experienced the same thing and what did you do to fix the problem? Does anyone know of a better tool to use? We chose

We have an existing "management system" of sorts, based on rdist. I''d like to know the best way to migrate it to using puppet. Currently, we have a local binaries tree, rdisted out nightly. We also make use of rdist''s extra capability to trigger scripts when and if named files are updated. I''m not sure what the best method would be, of converting this to

rsync -avnp remote::gif/ `find /home/www/html/ -maxdepth 1 -name "*.[j,g][pg,if]*"` /tmp/ If I run this on the local machine, the rsync server, it takes this long: ---> root@server (0.34)# time find /home/www/html/ -maxdepth 1 -name "*.[j,g][pg,if]*" -type f /home/www/html/comparestores_2.jpg /home/www/html/home.jpg /home/www/html/comparestores_3.jpg

rsync is great for syncing 2 directory trees, but I want to maintain a master source tree on one machine and copy that to multiple machines. i.e. basically what rdist does The only way I can see of doing this with rsync is to have multiple cron jobs 0 * * * * rsync ... machine1:... 0 * * * * rsync ... machine2:... ...and so on. Is there a more elegant/compact way of doing this? Thanks

This has been a consideration. But it pains me that a tiny change/addition to the rsync option set would save much time and space for other legit use cases. We know rsync very well, we dont know ZFS very well (licensing kept the tech out of our linux-centric operations). We've been using it but we're not experts yet. Thanks for the suggestion. /kc On Mon, Apr 06, 2015 at 12:07:05PM

Dear Folks, Is there a documented case of earliest use of rsync over internet? I presume rsync was used almost as soon as internet was invented as a file transfer and bandwidth efficient backup solution. If anyone has any information, please respond. -- Raghu Kulkarni

Feature request: allow --link-dest dir to be linked to even if file exists in target. This statement from the man page is adhered to too strongly IMHO: "This option works best when copying into an empty destination hierarchy, as rsync treats existing files as definitive (so it never looks in the link-dest dirs when a destination file already exists)". I was suprised by this behaviour

Let's say I have a slow, or high latency (or both) link between two hosts, and transferring data is expensive. Is it possible with rsync (or any other tool like rsync) to maintain a local metadata cache, such that I can rsync without transferring data to and from the hosts about what files are already in place ? That is, I already "know" what is out there and don't need to

Anyone here ever use or see any tools (free or commercial) that are similar to rsync but maybe provide a little more in the way of reporting features? I'm looking into some possible alternatives to a system I have scratched together using rsync. I'm bumping into some issues involved more on the backend of my system (stats on directory structures and contents) which is limiting the amount

Hi, Matthew -- Regarding your message of 05-Jul-2005 concerning rsync memory usage (sorry that I am not directly replying to it; I am not as yet subscribed to the list and my mailer doesn't allow me to hard-code an In-Reply-To or References header): While I applaud anyone who wants to encourage open-source development, it seems to me that, if in fact your problem is that you are running out

Has there ever been a discussion about parallelizing rsync? We do some large file transfers across our wan which get done much faster if we run multiple rsync's at the same time. I wrote a perl script that traverses the directories and figures out how many files to send with each rsync process, but this only works properly for the initial copy. If we could say "rsync --parallel=8

> If your goal is to reduce storage, and scanning inodes doesnt matter, > use --link-dest for targets. However, that'll keep a backup for every > time that you run it, by link-desting yesterday's copy. The goal was not to reduce storage, it was to reduce work. A full rsync takes more than the whole night, and the destination server is almost unusable for anything else when it

Hi list, I've found this post on rsync's expected performance for large files: https://lists.samba.org/archive/rsync/2007-January/017033.html I have a related but different observation to share: with files in the multi-gigabyte-range, I've noticed that rsync's runtime also depends on how much the source/destination diverge, i.e., synchronization is faster if the files are

Hi, I am thinking about a non-standard usage of rsync (at least not mentioned in the man file) I want to synchronized my collegues home directories(trees) each night AND store rsync's internal updating commands (reversed) to be able to restore the state of a directory the day before. This would require - saving the internal updating commands in a separate directory - reversing these commands

The attached patch adds a new 'ConnectTimeout' option (man page updated in patch) to avoid wasting time when the target host is down. I needed that because I was using rsync/rdist over ssh for massive files update and the default connect() took too long for my purpose. The patch was tested on Linux only, but I used a similar one for ssh 1.2.XX on Linux, Solaris and HP-UX without

Hi all, These two patches change how rsync handles temporary files on the receiver side. The first patch adds a static token to rsync's temporary filenames. The second patch ignores files with this token when using --cvs-ignore. http://pastebin.com/DL1jCNfm http://pastebin.com/yy9duP8Z The behaviour I wanted to improve was the case where two rsyncs are simultaneously reading and writing the

I checked the archives and bug lists, and didn't see this. Or rather, I saw someone report it, but it was backrev and a "non-standard" release, so that was considered out of bounds. I'm running on Ubuntu Dapper Drake, and first experienced this problem trying to do rsync backups via backuppc. I wanted to do a "don't cross filesystem boundary" backup from / so I

Is there a good place to get information about the list of all possible output and error messages rsync generates? Or should I just muck around the source code (which I haven't looked at yet) and find them? I am doing something where I would like to parse rsync's output using Perl into a set of data structures. I already have something that works under normal conditions. Eventually