From Wikipedia, the free encyclopedia
Jump to: navigation, search
Original author(s) Andrew Tridgell, Paul Mackerras
Developer(s) Wayne Davison
Initial release June 19, 1996 (1996-06-19)[1]
Stable release 3.1.1 (June 22, 2014; 3 months ago (2014-06-22)) [±][2]
Development status active
Written in C
Platform Unix-like, Windows
Type Data transfer, Differential backup
License GNU GPLv3

rsync is a file synchronization and file transfer program for Unix-like systems that minimizes network data transfer by using a form of delta encoding called the rsync algorithm. rsync can compress the data transferred further using zlib compression,[3] and SSH or stunnel can be used to encrypt the transfer.

rsync is typically used to synchronize files and directories between two different systems, one local and one remote. For example, if the command rsync local-file user@remote-host:remote-file is run, rsync will use SSH to connect as user to remote-host.[4] Once connected, it will invoke another copy of rsync on the remote host, and then the two programs will talk to each other over the connection, working together to determine what parts of the file are already on the remote host and don't need to be transferred over the connection.

rsync can also operate in daemon mode, where it listens by default on TCP port 873, serving files in the native rsync protocol (using the "rsync://" syntax).

It is released under the GNU General Public License version 3 and is widely used.[5][6][7][8]


Andrew Tridgell and Paul Mackerras wrote the original rsync. Tridgell discusses the design, implementation and performance of rsync in chapters 3 through 5 of his Ph.D. thesis in 1999.[9]

rsync was first announced on 19 June 1996[1] and the first release of major version 3 was issued on 1 March 2008.[10]


rsync originated as a replacement for rcp and scp. As such, it has a similar syntax to its parent programs.[11] Like its predecessors, it requires the specification of a source and of a destination; either of them may be remote, but not both. Because of the flexibility, speed and scriptability of rsync, it has become a standard Linux utility, included in all popular Linux distributions. It has been ported to Windows (via Cygwin, Grsync or SFU[12]) and Mac OS.

Generic syntax:


...where SRC is the file or directory (or a list of multiple files and directories) to copy from, and DEST represents the file or directory to copy to. (Square brackets indicate optional parameters.)

rsync can synchronize Unix clients to a central Unix server using rsync/ssh and standard Unix accounts.[citation needed] It can be used in desktop environments, for example to efficiently synchronize files with a backup copy on an external hard drive. A scheduling utility such as cron can carry out tasks such as automated encrypted rsync-based mirroring between multiple hosts and a central server.


A command line to mirror FreeBSD might look like:

 % rsync -avz --delete /pub/FreeBSD/[13]

The Apache HTTP Server supports only rsync for updating mirrors.

rsync -avz --delete --safe-links /path/to/mirror[14]

The preferred (and simplest) way to mirror the PuTTY website to the current directory is to use rsync.

rsync -auH rsync:// .[15]

A way to mimic the capabilities of Time Machine (Mac OS) - see also tym.[16]

#date=`date "+%Y-%m-%dT%H:%M:%S"`
date=`date "+%FT%T"`
rsync -aP --link-dest=$HOME/Backups/current /path/to/important_files $HOME/Backups/back-$date
ln -nfs $HOME/Backups/back-$date $HOME/Backups/current


Determining which files to send[edit]

By default rsync determines which files differ between the sending and receiving systems by checking the modification time and size of each file. This method incurs hardly any I/O and CPU usage, but will miss files whose content, unusually, has changed without modification to size or timestamp.

rsync can perform a more comprehensive check via the --checksum flag, forcing a full checksum comparison on every file present on both systems. Barring rare checksum collisions this avoids the risk of missing changed files, but incurs reading of every file present on both systems and is thus much slower.

Determining which parts of a file have changed[edit]

The rsync utility uses an algorithm invented by Australian computer programmer Andrew Tridgell for efficiently transmitting a structure (such as a file) across a communications link when the receiving computer already has a similar, but not identical, version of the same structure.

The recipient splits its copy of the file into fixed-size non-overlapping chunks and computes two checksums for each chunk: the MD5 hash, and a weaker 'rolling checksum'. (Prior to version 30 of the protocol, released with rsync version 3.0.0, it used MD4 hashes rather than MD5.[17]) It sends these checksums to the sender.

The sender computes the rolling checksum for every chunk of size S in its own version of the file, even overlapping chunks. This can be calculated efficiently because of a special property of the rolling checksum: if the rolling checksum of bytes n through n+S-1 is R, the rolling checksum of bytes n+1 through n+S can be computed from R, byte n, and byte n+S without having to examine the intervening bytes. Thus, if one had already calculated the rolling checksum of bytes 1...25, one could calculate the rolling checksum of bytes 2...26 solely from the previous checksum (R), byte 1 (n), and byte 26 (n+S).

The rolling checksum used in rsync is based on Mark Adler's adler-32 checksum, which is used in zlib, and is itself based on Fletcher's checksum.

The sender then compares its rolling checksums with the set sent by the recipient to determine if any matches exist. If they do, it verifies the match by computing the hash for the matching block and by comparing it with the hash for that block sent by the recipient.

The sender then sends the recipient those parts of its file that did not match the recipient's blocks, along with information on where to merge these blocks into the recipient's version. This makes the copies identical. However, there is a small probability that differences between chunks in the sender and recipient are not detected, and thus remains uncorrected. This requires a simultaneous hash collision in MD5 and the rolling checksum. It is possible to generate MD5 collisions, and the rolling checksum is not cryptographically strong, but the chance for this to occur by accident is nevertheless extremely remote. With 128 bits from MD5 plus 32 bits from the rolling checksum, and assuming maximum entropy in these bits, the probability of a hash collision with this combined checksum is 2−(128+32) = 2−160. The actual probability is a few times higher, since good checksums approach maximum output entropy but very rarely achieve it.

If the sender's and recipient's versions of the file have many sections in common, the utility needs to transfer relatively little data to synchronize the files. Note that if usual data compression algorithms are used, files that are similar when uncompressed may be very different when compressed, and thus the entire file will need to be transferred – local changes in uncompressed files yield global changes in compressed files. This is particularly an issue with mirroring of archive files, such as disk images and compressed tarballs, where often individual files change. Some compression programs, such as gzip, provide a special "rsyncable" mode which allows these files to be efficiently rsynced, by ensuring that local changes in the uncompressed file yield only local changes in the compressed file.

While the rsync algorithm forms the heart of the rsync application that essentially optimizes transfers between two computers over TCP/IP, the rsync application supports other key features that aid significantly in data transfers or backup. They include compression and decompression of data block by block using zlib at sending and receiving ends, and support for protocols such as ssh that enables encrypted transmission of compressed and efficient differential data using rsync algorithm. Instead of ssh, stunnel can also be used to create an encrypted tunnel to secure the data transmitted.


A utility called rdiff uses the rsync algorithm to generate delta files with the difference from file A to file B (like the utility diff, but in a different delta format). The delta file can then be applied to file A, turning it into file B (similar to the patch utility).

Unlike diff, the process of creating a delta file has two steps: first a signature file is created from file A, and then this (relatively small) signature and file B are used to create the delta file. Also unlike diff, rdiff works well with binary files.

Using the library underlying rdiff, librsync, a utility called rdiff-backup has been created, capable of maintaining a backup mirror of a file or directory either locally or remotely over the network, on another server. rdiff-backup stores incremental rdiff deltas with the backup, with which it is possible to recreate any backup point.[18]

The librsync library used by rdiff is an independent implementation of the rsync algorithm. It does not use the rsync network protocol and does not share any code with the rsync application.[19] The librsync library is used by Dropbox, rdiff-backup, duplicity, and other utilities.[19]

Duplicity is a variation on rdiff-backup that allows for backups without cooperation from the storage server, as with simple storage services like Amazon S3. It works by generating the hashes for each block in advance, encrypting them, and storing them on the server, then retrieving them when doing an incremental backup. The rest of the data is also stored encrypted for security purposes.

rsyncrypto is a utility to encrypt files in an rsync-friendly fashion. The rsyncrypto algorithm ensures that two almost identical files, when encrypted with rsyncrypto and the same key, will produce almost identical encrypted files. This allows for the low-overhead data transfer achieved by rsync while providing encryption for secure transfer and storage of sensitive data in a remote location.[20]

An alternative to manually scripting rsync is the GPL licensed GUI program BackupPC, which performs automatic scheduled backups to rsync servers.

As of Mac OS X 10.5 and later, there is a special -E or—extended-attributes switch which allows retaining much of the HFS file metadata when syncing between two machines supporting this feature. This is achieved by transmitting the Resource Fork along with the Data Fork.[21]

Solutions using rsync[edit]

Name Linux Mac OS Windows Free Software Comments
Acrosync No Yes Yes No Alternative client with built-in file monitor to support automatic upload. Website
Back In Time Yes No No Yes
BackupAssist No No Yes No Direct mirror or with history, VSS. Proprietary
Carbon Copy Cloner No Yes No No Proprietary tool for cloning, backing up and synchronising volumes/folders.
Cwrsync No No Yes No Proprietary. Free Edition available. Based on Cygwin
DeltaCopy No No Yes Yes Open Source, Free, Based on Cygwin - WebSite - Download
Dirvish Yes Partial No Yes Backup software for taking incremental snapshots. Free software (Open Software License v2.0).
Fpart Yes Yes No Yes Split a file tree into sub-trees and launch external command (such as rsync) over generated parts (C, BSD-licensed)
gadmin-rsync Yes No No Yes Part of Gadmintools
Grsync Yes Yes Yes Grsync for Windows Yes Graphical Interface for rsync on Linux Systems
Handy Backup Yes No Yes No Proprietary software. Uses rsync for delta-copying and for differential backup.
LuckyBackup Yes Yes Yes Yes
QtdSync Yes No Yes Yes
rdiff-backup Yes Yes Yes Yes Incremental backups. archfs (nowadays called rdiff-backup-fs which is more accurate) allows the backup to be mounted as a drive, making all versions accessible as snapshots.
RipCord Backup No Yes No
rsnapshot Yes Yes Yes Yes Snapshot-generating backup-tool using Rsync and hard links
RsyncX No Yes No Yes
Syncrify Yes Yes Yes No Free for personal use, uses rsync protocol over HTTP(S), AES encryption, GUI, 2-way synchronization, written in Java
tym Yes No No Yes time machine - Time rsYnc Machine (tym) - bash script - free
Unison Yes Yes Yes Yes Two-way file synchronizer using Rsync algorithm
Space Machine Yes Yes No Yes Simplifies internet sync with job files, desktop/email notification, compressed archive, open source bash script

See also[edit]


  1. ^ a b Tridgell, Andrew (19 June 1996). "<>#1/1 First release of rsync - rcp replacement". comp.os.linux.announce. Web link. Retrieved 2007-07-19.
  2. ^ "NEWS for rsync 3.1.1 (28 Jun 2013)". 2014-06-22. Retrieved 2011-10-01. 
  3. ^ "rsync(1) - Linux man page". Retrieved 2014-08-18. 
  4. ^ "Using Rsync and SSH". Retrieved 2014-08-18. 
  5. ^ "Lossless compression handbook". 2002-12-18. Retrieved 2014-08-18. 
  6. ^ "Web content caching and distribution: proceedings of the 8th International Workshop". Retrieved 2014-08-18. 
  7. ^ In-Place Rsync: File Synchronization for Mobile and Wireless Devices, David Rasch and Randal Burns, Department of Computer Science, Johns Hopkins University
  8. ^ Dempsey, Bert J.; Weiss, Debra (April 30, 1999). "Towards an Efficient, Scalable Replication Mechanism for the I2-DSI Project". Technical Report TR-1999-01. CiteSeerX: 
  9. ^ Andrew Tridgell: Efficient Algorithms for Sorting and Synchronization, February 1999. Retrieved 29 Sept. 2009.
  10. ^ Davison, Wayne (1 March 2008). "Rsync 3.0.0 released". rsync-announce mailing list. //
  11. ^ See the README file
  12. ^
  13. ^ "How to Mirror FreeBSD (With rsync)". Retrieved 2014-08-18. 
  14. ^ "How to become a mirror for the Apache Software Foundation". Retrieved 2014-08-18. 
  15. ^ "PuTTY Web Site Mirrors: Mirroring guidelines". 2007-12-20. Retrieved 2014-08-18. 
  16. ^ "Rsync set up to run like Time Machine". Retrieved 2014-08-18. 
  17. ^ NEWS for rsync 3.0.0 (1 Mar 2008)
  18. ^ rdiff-backup
  19. ^ a b Martin Pool. "librsync".
  20. ^ rsyncrypto
  21. ^ "Mac Developer Library". Retrieved 2014-08-18. 

External links[edit]