Difference between revisions of "Rsync"
(→Using encryption with EncFS: works) |
m |
||
| Line 11: | Line 11: | ||
* Supports [http://dslab.lzu.edu.cn:8080/members/wangbj/wangbaojun/howtos/rsync-mirror-HOWTO/rsync-mirroring02.html anonymous rsync] which is ideal for mirroring | * Supports [http://dslab.lzu.edu.cn:8080/members/wangbj/wangbaojun/howtos/rsync-mirror-HOWTO/rsync-mirroring02.html anonymous rsync] which is ideal for mirroring | ||
| − | == Using rsync over SSH == | + | == Using rsync over SSH with key-based logins == |
Sometimes it's useful to do a one-off backup of a file structure from one host to another, and since all the hosts (in our system) are guaranteed to be able to connect to each other with SSH (after adding appropriate RSA keys), using rsync over SSH is a good way to do this. | Sometimes it's useful to do a one-off backup of a file structure from one host to another, and since all the hosts (in our system) are guaranteed to be able to connect to each other with SSH (after adding appropriate RSA keys), using rsync over SSH is a good way to do this. | ||
| Line 22: | Line 22: | ||
For more security, the command allowed can be restricted to just that specific rsync command. This can be done by manually running the rsync command with the ''-e'ssh -v' ''option which will output the exact command sent that can be used in the remote hosts ''authorized_keys'' file instead of just "rsync". | For more security, the command allowed can be restricted to just that specific rsync command. This can be done by manually running the rsync command with the ''-e'ssh -v' ''option which will output the exact command sent that can be used in the remote hosts ''authorized_keys'' file instead of just "rsync". | ||
| − | == | + | === Using rsync with encryption === |
| − | + | [http://how-to.linuxcareer.com/user-data-encryption-with-fuse-based-encfs EncFS] which can be installed simply via ''apt-get'' is an excellent option for synchronising data with ''rsync'' when the target system is insecure. Using ''EncFS'', an encrypted version of the source data can be maintained locally and then synchronised to a remote systenm with ''rsync''. | |
| − | We've | + | ''EncFS'' is used in its standard form to create two directories, an encrypted one which is permanent and another which is the decrypted view of this encrypted data that only exists while ''EncFS'' is running. This means that we can start ''EncFS'' which will then present the current state of the encrypted data in the temporary decrypted mount point, then we do a local ''rsync'' from the source directory structure to the decrypted mount point, then stop ''EncFS''. We can then ''rsync'' the permanent encrypted directory to the remote server as it has now been brought up to date with the source structure. |
| + | |||
| + | The temporary decrypted view contains a one-to-one correspondence of file-system objects with the permanent encrypted data, which means that ''rsync'' can still work efficiently at updating only the added files and deleting the removed ones as usual. If there were no such on-to-one correspondence then the entire encrypted structure would need to be rebuilt whenever anything changed, and ''rsync'' would have to transfer the whole structure every time. | ||
| + | |||
| + | Another good feature of ''EncFS'' is that the file and directory names are also encrypted using only friendly characters which means that there's no need to use the ''transliterate'' patch with ''rsync'' when using ''EncFS''. | ||
| + | |||
| + | == The Transliterate patch == | ||
| + | Sometimes the source file structure contains characters that are not allowed on the target system, for example ''Maildirs'' use colons in the file naming protocol which are not allowed on many filesystems including our [http://www.adrive.com ADrive backup service]. | ||
| + | |||
| + | We've overcome this problem using the [https://git.samba.org/?p=rsync-patches.git;a=blob;f=transliterate.diff;h=19d6393537903a1fb7d5581b8216b999fa82a450;hb=135a233d6f4d401c187117ae57fac147f2a863a4 transliterate patch] which adds a '''--tr=BAD/GOOD''' option for mapping bad characters to good ones. | ||
To install the patch you need to download and unpack the latest source and the patches, then change into the source directory and do the following: | To install the patch you need to download and unpack the latest source and the patches, then change into the source directory and do the following: | ||
| Line 41: | Line 50: | ||
</bash>}} | </bash>}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
[[Category:Software]][[Category:Linux]] | [[Category:Software]][[Category:Linux]] | ||
Revision as of 17:54, 17 July 2014
rsync is an open source utility that provides fast incremental file transfer. rsync is freely available under the GNU General Public License and is currently being maintained by Wayne Davison.
rsync uses the "rsync algorithm" which provides a very fast method for bringing remote files into sync. It does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand.
Some features of rsync include
- Can update whole directory trees and filesystems
- Optionally preserves symbolic links, hard links, file ownership, permissions, devices and times
- Requires no special privileges to install
- Internal pipelining reduces latency for multiple files
- Can use rsh, ssh or direct sockets as the transport
- Supports anonymous rsync which is ideal for mirroring
Using rsync over SSH with key-based logins
Sometimes it's useful to do a one-off backup of a file structure from one host to another, and since all the hosts (in our system) are guaranteed to be able to connect to each other with SSH (after adding appropriate RSA keys), using rsync over SSH is a good way to do this.
The transfer syntax is then done very similarly to SCP, for example to pull new changes from a remote directory to a local one, use:
After the systems are confirmed as being able to connect over SSH you may want to lock them down so that the connection between them can only be used for rsync. The IP and command can be prepended to the key in the remote hosts ~/.ssh/authorized_keys file.
For more security, the command allowed can be restricted to just that specific rsync command. This can be done by manually running the rsync command with the -e'ssh -v' option which will output the exact command sent that can be used in the remote hosts authorized_keys file instead of just "rsync".
Using rsync with encryption
EncFS which can be installed simply via apt-get is an excellent option for synchronising data with rsync when the target system is insecure. Using EncFS, an encrypted version of the source data can be maintained locally and then synchronised to a remote systenm with rsync.
EncFS is used in its standard form to create two directories, an encrypted one which is permanent and another which is the decrypted view of this encrypted data that only exists while EncFS is running. This means that we can start EncFS which will then present the current state of the encrypted data in the temporary decrypted mount point, then we do a local rsync from the source directory structure to the decrypted mount point, then stop EncFS. We can then rsync the permanent encrypted directory to the remote server as it has now been brought up to date with the source structure.
The temporary decrypted view contains a one-to-one correspondence of file-system objects with the permanent encrypted data, which means that rsync can still work efficiently at updating only the added files and deleting the removed ones as usual. If there were no such on-to-one correspondence then the entire encrypted structure would need to be rebuilt whenever anything changed, and rsync would have to transfer the whole structure every time.
Another good feature of EncFS is that the file and directory names are also encrypted using only friendly characters which means that there's no need to use the transliterate patch with rsync when using EncFS.
The Transliterate patch
Sometimes the source file structure contains characters that are not allowed on the target system, for example Maildirs use colons in the file naming protocol which are not allowed on many filesystems including our ADrive backup service.
We've overcome this problem using the transliterate patch which adds a --tr=BAD/GOOD option for mapping bad characters to good ones.
To install the patch you need to download and unpack the latest source and the patches, then change into the source directory and do the following:
You can't use this option to backup directory to the target server unless the target also has the transliterate patch installed. If it's not installed on the server you'll need to do a two-stage backup. The first to a local directory using the --tr option, and second synchronising this local directory (that has all the colons replaced) with the remote server without the --tr option. Here's an example taken from our daily backup script.
