cp just saps resources when transferring large volumes of data between directories. Especially on old machine memory usage spikes when the process is started and the machine becomes almost unresponsive. That’s on large volumes of data (and old hardware).
Enter rsync stage left. OK, none of this is new (you know all this already) — it’s really just to have in one spot:
No mess no fuss transfer from one server to the other (straight transfer via SSH):
rsync -av -e ssh username@oldhost:/home/old_home/ /home/new_home/
Synchronising your local to a remote directory:
rsync -r -a -v -e "ssh -l username" --delete webhost:/var/www /local/var/www
Synchronizing your remote directory to the (current) local directory:
rsync -r -a -v -e "ssh -l username" --delete /local/var/www webhost:/var/www
-r recurses, -z compresses, -v is verbose and -e is obvious
With large volumes of data (DVD isos etc) your processor is still going to be taxed (twice) — via ssh and rsync – but not quite as intensively as on the cp.
To copy files between two local directories, rsync does the job, too:
rsync -vur --delete --exclude=*.EXT1--exclude=*.EXT2 /folder1 /folder2
Quick, simple, gracious.
But you knew that already… ![]()
Tags: administration, codesnippets, linux, migration, rsync, server
[...] and to backup, rsync is now your friend [...]
A beautiful, simple owner-and-group preserving (og), verbose recursive refreshing local rsync (may as well be remote):
/usr/bin/rsync -vurog /folder/path/one /folder/path/twoor simply
/usr/bin/rsync -vura /folder/path/one /folder/path/twofor maintained permissions, time and all that jazz…Shweet!!
If you’re using a non-standard port for rsync via SSH, you just add
as a term, so that would make it