Why rsync over cp and scp
rsync transfers only what changed, by default anything whose size or modification time differs, and within large files only the changed blocks (the rolling-checksum delta algorithm). A nightly sync of a 100 GB tree where 200 MB changed moves roughly 200 MB. It's also restartable, preserves metadata faithfully, and reports exactly what it did. scp is fine for one file; for trees, rsync every time, and since OpenSSH 9's scp actually uses the SFTP protocol, the historical speed argument is gone too.
The trailing slash, tattooed here
rsync -av src dest/ creates dest/src/…; rsync -av src/ dest/ puts src's contents directly in dest/. With --delete in play, the wrong variant doesn't just misplace files; it deletes everything in dest that doesn't match the unexpected layout. This is the origin of most rsync horror stories, and the reason -n (dry run) before any deleting sync is a rule, not a suggestion.
Flags worth knowing exist
--link-dest turns rsync into a snapshot backup engine: each day's directory looks complete, but unchanged files are hardlinks to yesterday's copy, costing zero extra space. --partial keeps interrupted transfers for resumption instead of deleting them. -H preserves hardlinks (off by default, surprising for system backups), -x stays on one filesystem (don't back up /proc), and --info=progress2 gives whole-transfer progress rather than per-file. Add -A -X when ACLs and extended attributes matter, plain -a does not include them.