--exclude on rsync command line is a problem for me! ;~}

My exclude syntax does not work at all, it is ignored. What is the error of my ways?

sudo rsync -a --progress --delete --log-file=/home/kgw/Desktop/$(date +%Y%m%d)_rsync.log --exclude 'Videos' --exclude '.cache' /home/kgw /run/media/kgw/M31/note_kgw/kgw

the syntax according to
man rsync
is: --exclude=PATTERN

you seem to be missing the “=”

I have found it more convenient to use the:
and have all the exclusions (patterns and paths) in that file

1 Like

You can collapse the excludes into one.


The filter option should also work.

-f "- Videos" -f "- .cache"

If you want to delete the files at the destination should they exist.

-f"-R Videos" -f"-R .cache"
1 Like
  • man rsync


    This option is a simplified form of the --filter option that specifies an exclude rule and does not allow the full rule-parsing syntax of normal filter rules.
    This is equivalent to specifying -f'- PATTERN'.

    See the FILTER RULES section for detailed information on this option.

To check your rules you can use:

--dry-run --debug=FILTER
  • see more info using --debug=help

Im using these options to synchronize my original and backups in my personal script:

  • /etc/named/bin/backup
    #!/usr/bin/env bash
    # Sync to backups
    function main {
    # 		--dry-run	--debug=FILTER
    		--acls	--xattrs
    		--exclude-from=/etc/named/bin/.rsync-exclude	--delete-excluded
    	for bkdir in "${bkdirs[@]}"; do
    		test ! -d "$bkdir" && continue
    		case "$bkdir" in
    				# Sync named dir recursively
    				echo -e "\nSyncing named to: $bkdir"
    				sudo rsync "${opts_rysync[@]}" /etc/named "${bkdir%/named}"
    #shellcheck disable=SC2312
    if test "$(id -u)" -ne 0; then
    	exec pkexec "$0" "$@" || exit
    	main "$@"
    (I know it could be coded a lot simpler, but i use the same logic for multiple stuff, so it’s just a copy and replace certain parts kind-of-thing for me)


1 Like

Thanks for all the tips…Putting the excludes in alphabetical order makes it work apparently: .cache first, Videos last, in this case.

I still can’t get it to work via crontab at boot, using a script installed in /root:

@reboot /root/rsync-shell.sh

Permissions are

-rwxr--r-- root root 190

I see that it should be:

@reboot root /root/rsync-shell.sh

Now going to try it :crossed_fingers:

Why…really WHY are people still using cron jobs on a system with systemd-timers? :thinking:

(Especially when you want a job to be run once at startup, it would be much more efficient to use a systemd-service)

Dear Systemd-Lover :wink: :stuck_out_tongue:

People use this because it is common, and it is only one text file, and you don’t have to deal with systemd syntax. Same for fstab btw…

So common, in fact, that that it has become synonymous with timed jobs. And it was good. The operative word being was.

One should move to newer things, especially on rolling-release distros, according to me. And that’s what I mean by was.

@kgw I recommend you switch to Systemd-timers. It’s awesome and in my opinion easier.

More information:




You can count me under that group as well.

1 Like

Good… call me lazy, but making the same task more complex is not a benefit. Create a GUI for this, and I am on board, but systemd timers can not beat crontab in simplicity.

Hi lazy! Hope you’re well!

I don’t really like the GUI for that type of thing, so text-based is more than perfect for me.

What’s more, Systemd-timer units’ time definitions are, according to me at least, also much easier to understand. Never could wrap my head around that. I felt kind of stupid because of it, but it didn’t discourage me from Linux, luckily.

Since when did you had a GUI for cron-jobs? :rofl:

PS: The cron syntax is from the time when computers had scares resources, from the same era where cryptic and spaghetti programming were needed to save bytes.
This has since then been completely de-favored in favor of human readability and understandability…

Lets not derail the topic more :slight_smile:

1 Like

It never need one, because it was simple. Just one line and that’s it.

Okay, that is a valid point. As a newbe you better understand dates. So the time definitions are human-readable. But for me that is not enough.

Assembler code in hex was simple for me also back in that time, now go ask others if that is true for 99.99% of computer users/coders…

1 Like

I don’t think I’m that much of a newbie after at least 15 years working with Linux, and 2+ years using it exclusively…

So, what you’re sayin’ is, you’re not human? At least not entirely?


Keep in mind that there are people here, like me, who started with computers long before you were born, so in that context yea you’re a new one :slight_smile:

Fe. ±15-20 yrs you vs ± 45 yrs me in computer branch :wink:

1 Like

Yeah, I know. I realize I can’t compete with dinosaurs. :dash: That’s why I said that much. Because I see a lot of newcomers here on the forum.

Ok ladies…

Then please say how a systemd timer would look like equally to:

0 * * * * /path/to/script.sh


First you create service, right?

File: /etc/systemd/system/myscript.service

Description=My great description



and then a timer:

File: /etc/systemd/system/myscript.timer

Description=My great description



Correct? And all of this can be done by one line in crontab.

Not one line, that’s for sure.


But I found the timer easier to understand.

The purpose this millennium is not to have a 1-byte command do something you need, this millennium is all about human-understandable code aside from the one coding it and to prevent bugs.

Here are some links to the sub-topic we derailed into:

PS: There is systemd-crontab-generator in a “systemd-cron” package that dynamically translates cron stuff:

You just need these contents:

  • File: /etc/systemd/system/myscript.service

  • File: /etc/systemd/system/myscript.timer


Compare the above to your cronjob line…

Yes as you showed yourself, the systemd-way can even add a lot more for the human which the cronjob line is not able to…

  • Links to documentation, accessible through systemctl help servicename…
  • Separate log queries for that job, accessible through systemctl status servicename or journalctl -u servicename…
  • and many many more.