rsync and symbolic links

I want to backup my home directory to an external drive nightly using a cron job to execute rsync. I am unsure of the exact behavior of rsync's symbolic link flags.

1. rsync's -a flag includes the -l flag (i.e. "copy symlinks as symlinks"). Does this just mean it will copy the link or that it will follow the link and copy everything in the link-to directory? I want to avoid that because I have links to directories full of media files that would involve copying hundreds of gigabytes I don't need to back up.
2. Fearing (but not certain) that rsync -a would copy all those media files I instead added the --no-links flag. This does not seem to be behavior I want. It just ignores copying any link which is problematic because I do have links I want copied (e.g. links to common header files from different project directories).
3. Assuming #1 above (without the --no-links flag) is what I really want and it just copies the link without copying the linked-to files, will the links break when they are backed up? For example I may rsync source directory /home/me/projects/misc to /media/extdrive/backup/home/me/projects/misc. In this case I assume rsync is not smart enough nor does it try to correct the contents of symlinks for the relative directory changes. Is this correct? This is okay, it doesn't matter if the links are broken in the backup directories so long as they would be fixed and working if such time comes when they need to be restored.

Solution 1:

1. "Copy symlinks as symlinks" means exactly what it says: If rsync sees a symlink in the source directory, it will create an identical symlink in the destination. Nothing more.

   (A few lines down in the manual page, a different option, --copy-links, describes the opposite behavior (always copying the data) which you described as undesirable.)

   See also the section "Symbolic links":

   If --links is specified, then symlinks are recreated with the same target on the destination.

2. It's not the behavior you want because you're misinterpreting what --links does and therefore asking for the wrong behavior (see answer #1).

3. By default, it copies the destination exactly.

   That is, if the link pointed to an absolute path (e.g. /home/me/projects), it'll continue pointing to the same path; it won't break, it'll just continue pointing to a file in your home directory rather than the one in your backup.

   Meanwhile, if the link pointed to a relative path (e.g. ../../projects), it'll also continue pointing to the same path, but since it's relative to the symlink's location, the symlink in your backup will also be pointing to a file in your backup.

   Unfortunately there doesn't seem to be any option to translate absolute symlinks for their new base (only an option to break them entirely). To avoid problems, you should change existing symlinks to relative ones (which is a good idea generally, for links inside $HOME).

Solution 2:

@grawity has a great answer, but here's a screenshot of some relevant info from the documentation. Here's the exact wording of the -l (lowercase letter L, not a one) and -L options, for instance, which seem to be the most relevant ones in question:

Source: https://linux.die.net/man/1/rsync, or man rsync manual pages on Linux.

Note also that the -a (--archive) option also includes the -l option within it, which is awesome, since I really like using the -l option to preserve my symlinks from the source as symlinks on the destination. From the man pages:

-a, --archive               archive mode; equals -rlptgoD (no -H,-A,-X)

Note, for my favorite rsync commands and instructions, including copying, mirroring, showing total progress...

...doing dry runs, logging stderr and stdout to (separate) files, showing stats, using an include path file and an exclude file, etc, see my full answer here under the 2nd section, titled "2. rsync Command-line tool (Linux, Windows with Cygwin)": https://superuser.com/a/1464264/425838