Difference between revisions of "Rsync"
(→Using encryption with EncFS: point 3 all good) |
(→Using encryption with EncFS: works) |
||
| Line 42: | Line 42: | ||
=== Using encryption with EncFS === | === Using encryption with EncFS === | ||
| − | + | [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 ''Maildir'' structures (as well as other data). Using ''EncFS'' and encrypted version of the source data can be maintained locally and then synchronised to a remote location with ''rsync''. The only issue is that twice the space is required on the local host to maintain both the plain view and the encrypted view, unless the daemon is run at boot time and the mail-server works directly into the temporary decrypted view of the encrypted directories which can be done but makes the mail-server less reliable. | |
| − | |||
| − | ''' | ||
| − | + | ''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 Maildir 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. So only points one and two remain to be tested to see if ''rsync'' can work properly on this format of data. | |
| − | |||
| − | |||
| − | |||
| − | + | The encrypted view contains a one-to-one correspondence of filesystem objects between the decrypted and encrypted structures, which means that ''rsync'' can still work efficiently at updated only the added files (and deleting the removed ones). | |
| − | + | Furthermore, 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 ''EndFS''. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
[[Category:Software]][[Category:Linux]] | [[Category:Software]][[Category:Linux]] | ||
Revision as of 17:07, 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
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".
Backing up Maildirs with Rsync
Backing up Maildirs can be a problem with many target systems (even non-Windows ones) because many filesystems don't allow colons in file names. This problem occurs for us using the ADrive backup service.
We've over come 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.
Using encryption with EncFS
EncFS which can be installed simply via apt-get is an excellent option for synchronising Maildir structures (as well as other data). Using EncFS and encrypted version of the source data can be maintained locally and then synchronised to a remote location with rsync. The only issue is that twice the space is required on the local host to maintain both the plain view and the encrypted view, unless the daemon is run at boot time and the mail-server works directly into the temporary decrypted view of the encrypted directories which can be done but makes the mail-server less reliable.
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 Maildir 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. So only points one and two remain to be tested to see if rsync can work properly on this format of data.
The encrypted view contains a one-to-one correspondence of filesystem objects between the decrypted and encrypted structures, which means that rsync can still work efficiently at updated only the added files (and deleting the removed ones).
Furthermore, 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 EndFS.
