alexalmazan.com

Rsync can be used effectively to transition services amongst server host(s) who share common distribution roots in regards to Linux distrubution in use. ie. ‘Fedora FCx Vs. Fedora Latest’

Please note that if certain exclusions are not granted, you can easily destroy libraries and or other precious data serving your customer base. Please ensure you are full aware of the command syntax, especially when running rsync as root!

If you are after a single directory, on the server you are migrating from, you can transport it with the following syntax

/usr/bin/rsync -ave ssh user@ip.address:/home/user /home/user

If the servers you are moving data amongst are similar or greater in disk geometry/capacity and identical operating system, you can clone or replicate the server you are migrating from to your new platform with the following:

/usr/bin/rsync -az -e ssh / root@ip.address:/

The method just described has it s consequences. First and foremost, all IP address information and or user information configured has now been modified to be that of the server you are migrating from. If this occurs within a datacenter environment, both servers involved will stay online and active, however manual console intervention may be required to address the IP address issue upon the next reboot of the server receiving the rsync feed.

It also requires that SSH be permitted to the server you are migrating to. SSH root access is only recommended if you are in full control of the IP sources available to interact with your server via SSH. IF you are unable to filter or have no filters in place .ie firewall then SSH access for root should not be permitted for extended periods if at all. Root access is required to preserve data permissions when migrating data in such scenarios.

Here is another examples which shows how it can be used to mirror MySQL database information amongst similar server hosts.(mysql server version and OS should be identical )

# rsync -avru -e ssh root@ip.address:/var/lib/mysql/DB1 /var/lib/mysql 
 

The above example demonostrates the movement of one database, here is a method for the entire datadir. (examples recommended with both database servers off)

# rsync -avru -e ssh root@ip.address:/var/lib/mysql/ /var/lib/mysql

Placement of ’/’ makes a huge difference with the outcome when using rsync. WIth it, you are copying the contents of a filesystem or directory, without it, you are copying entire file structures or directories.

To overcome limitations such as overwriting libraries and or devices files, or everything in ’/etc’ when using rysnc, I recommend the following syntax when migrating from similar server OS platforms.

# rsync --rsh="ssh " -avz --exclude="/etc" --exclude="/proc" --exclude="/dev" --exclude="/lost+found" --exclude="/var/log" / root@ip.address:/
 

Usage of ‘—exclude’ will vary from migration to migration.

Migrating data can be a quick and easy process. The following example will provide a method for archiving and transferring data directories simultaneously. The biggest difference is the compression used in these examples.

tar zcvf - /home | ssh user@ip.address "cat > homearchive.tgz" 

Here is another:

tar cjvf - /home | ssh user@ip.address "cat > homearchive.tar.bz2" 

These examples demonstrate that you can begin a tar archive and pipe it into an SSH session for transport. It works great if the users in question for which the data you are moving exist. If this is not the case, then file permission preservation is probably going to be an issue with the above examples.

Rsync is certainly better suited for this quick hack.

Process information prior to server crash can provide insight into server instability. The following cron can help obtain details necessary to re-instill server stability. This should be used sparingly and in the most dire of circumstances.

*/1 * * * * uptime >> /root/status.txt ; ps -auwwwwx >> /root/status.txt ; free -m >> /root/status.txt
*/5 * * * * uptime >> /root/status5.txt ; ps -auwwwwx >> /root/status5.txt ; free -m >> /root/status5.txt
*/10 * * * * uptime >> /root/status10.txt ; ps -auwwwwx >> /root/status10.txt ; free -m >> /root/status10.txt 

This CRON example covers a daily delivery of server logs, in this case mail specific.

5 0 * * *  /bin/mail -s "Daily requested mail log" user@domain.ltd < maillog > /dev/null 2>&1