Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a 500 GB file that I plan on backing up remotely. The file changes often. I'll be rsyncing it from a desktop to a server. Both can run rsync client or server.

What is the proper command for this? The ones I've tried sofar has been taking forever or simply acted strange.

Example and results:

rsync -cv --partial --inplace --no-whole-file /desktop/file1 

Seems to work, but only if I do it twice (?!). Also, slow.

Does the above command do the checksumming on both computers, or only on the sending one? Is it correct otherwise?

share|improve this question
A file that large which changes often? You're going to get very, very disappointing results with rsync... – Ignacio Vazquez-Abrams Jun 16 '10 at 11:55
Any other suggestions? I should be doable with some app, Dropbox's proprietary client does it very well. See – Johan Allgoth Jun 16 '10 at 12:13

It's never going to be fast, because rsync is going to have to read/checksum the entire file, and reading 500GB is going to take a long time, unless you've got it stored on SSDs or something.

Try rsync -vhz --partial --inplace <file/server stuff>.

-c means that it checksums the entire file BEFORE doing any transfers, rather than using the timestamp to see if it's changed, which means reading the whole file twice. If the timestamp isn't getting changed (it should), then you could just touch the file before running rsync.

If this isn't scripted, you can add --progress so you can see how it's doing as it runs.

share|improve this answer
Yeah, I know 'large file == long handling'. But I feel I am missing something here, see the comment above. If Dropbox can do it so can we! =) I didn't say, but i also tried without -c, still slow. – Johan Allgoth Jun 16 '10 at 12:14
also --inplace implies --partial – Jack Douglas May 21 '12 at 9:47

Though it's not rsync, depending on what you're trying to do this may work better. I was doing a similar backup task and it was definitely faster.

Use netcat to make a tar pipe from one machine to the other.

On your source machine:

tar -cpv --atime-preserve=system . | nc -q 10 -l -p 45454

You're creating a tarball preserves permissions and time, then piping it into netcat on port 45454

On your backup machine

nc -w 10 X.X.X.X 45454 | tar -xpv

X.X.X.X = local ip address of your source machine.

For me, this worked well. It ran at 25-30 MB/s over wired LAN as opposed to 2-3 MB/s with rsync. The disadvantage is: it doesn't sync, it just makes a copy of what's on your source. For a backup like you're describing though - one 500GB file - it could work very well.

You may have to do this as root in order to avoid permissions problems, or you may get lucky.

FWIW, I initially learned about this here:

share|improve this answer
tar is better than rsync when you have a lot of small files to transfer. Using nc also improves the transfer rate when on a fast connection, because you don't have the overhead of SSH-encryption (which I don't need on a peer-to-peer connection) – jornane Jan 28 at 10:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .