rsync vs cp: Which Is Faster for Copying Files?

Short answer: for a one-off local copy, use cp — in my test it copied 352 MB in 1,003 files about 80 times faster than rsync -a. But rsync earns its place the second time you copy: on an identical re-run it transferred nothing and finished in 0.06 seconds, while cp blindly rewrote all 352 MB. So cp wins fresh copies, rsync wins backups, syncing, and anything over a network.

The test: 1,003 files, two tools, one check

To compare fairly, both tools started from the same data, generated on this machine on November 1, 2026: 1,000 small files (1 KB to 100 KB each) plus three 100 MB large files — 352 MB and 1,003 files in total, a realistic mix of a project folder rather than one giant file. The machine is a 4-core Linux virtual machine running rsync 3.2.7 and cp from GNU coreutils 9.4.

I ran each fresh copy three times, deleting the destination each time, and took the median. After every copy I verified the result with diff -r, which compares every file's contents — both tools produced destinations identical to the source, all 1,003 files.

One honest caveat before the numbers: these absolute times are fast because the files were freshly written and still in the page cache, on a fast virtual disk. Your times on a cold hard drive will be much larger. What transfers to your machine is the pattern, not the milliseconds — and the pattern here was consistent across every run.

The results: cp crushes the fresh copy

That is not a close race. cp finished the whole fresh copy in four hundredths of a second, while rsync -a took 3.29 seconds — roughly 80 times slower. The gap showed up on both halves of the dataset, so it is not about file size or file count alone: rsync simply does more work per file, setting up its transfer machinery even when the destination is empty.

The commands were the straightforward ones most people actually type:

cp -r src/. dest/
rsync -a src/ dest/

One flag closes most of the gap

rsync has a flag that skips its delta-transfer machinery and copies each file whole: --whole-file. Adding it changed the small-files result dramatically:

So much of the default gap comes from rsync's delta-transfer setup, not from the actual copying. Even with --whole-file, though, rsync was still about three times slower than cp on a fresh copy here. If all you want is to duplicate a folder once, cp is the faster tool — full stop.

The second run: where rsync fights back

The story flips when the destination already exists. I re-ran both tools against a destination that was already an exact copy of the source:

On wall-clock time this is a tie on my fast cached disk — but look at the work done. rsync compared the two trees and transferred zero bytes. cp rewrote every byte. On a slow disk, a USB stick, or a network share, that difference is the whole ballgame: rsync's repeat run stays near-instant while cp's cost grows with the size of the data.

I also tested the realistic middle case: I changed one small file and appended 1 MB to a large file, then updated both destinations. rsync finished in 0.40 seconds, transferring only the changed parts; cp re-copied everything in 0.06 seconds of wall time — again faster locally only because the page cache made rewriting cheap. Over a network, rsync would have sent roughly 1 MB plus a small file, while cp would have sent all 353 MB. That is why rsync is the standard tool for backups and server syncing despite losing the fresh-copy race.

So which should you use?

Use cp when: you are copying a folder once, locally, and just want it done fast. cp -r is the simplest answer, and cp -a preserves permissions, timestamps, and ownership like rsync -a does.

Use rsync when: you will copy the same tree again, you are copying over a network or to a slow drive, you want to see progress (--progress), resume an interrupted transfer (--partial), delete files that no longer exist at the source (--delete), or verify with checksums (--checksum). None of that is cp's job, and no speed advantage on a fresh copy changes it.

The rsync manual documents these options, and the cp manual covers cp -a for archive-style copies.

FAQ

Is rsync faster than cp? For a fresh local copy, no — in my test cp was about 80 times faster. rsync is faster on repeat copies, because it skips files that have not changed.

Does rsync skip existing files? Yes, by default it skips files whose size and modification time match the source. Add --checksum if you want it to verify content too, at the cost of reading every file.

Does cp overwrite existing files? Yes, cp -r overwrites files at the destination without asking (unless you add -i). It never deletes destination files that are no longer in the source — rsync --delete does.

Which preserves permissions? cp -a and rsync -a both preserve permissions, timestamps, ownership, and symlinks. Plain cp -r does not preserve everything, so use -a for backups.

Conclusion

cp won every fresh-copy test I ran, by a wide margin — if you are duplicating a folder once on your own machine, it is the right tool and there is no contest. rsync won the only test that matters for repeated work: it skipped 352 MB of unchanged data in 0.06 seconds. Pick based on how many times you will run the copy, not on which tool sounds more powerful.

How this article was made

I generated a 352 MB test tree (1,000 small files plus three 100 MB files) on a Linux VM on November 1, 2026, and timed cp -r, rsync -a, and rsync -a --whole-file with the destination deleted between fresh runs (median of three runs each), plus repeat and changed-file runs. Every destination was verified byte-for-byte with diff -r. All timings above are my own measurements; the man-page links are the only external sources. This article was written with AI assistance (Tiny, TechVerge's AI assistant) and the test results were checked before publishing.