I use rsync as follows:

rsync -a --backup --suffix="."$(date +"%Y%m%d%H%M") source backups

to dump the whole of folder source into the folder backups, with the additional feature that if I modify some file foo in source, the old version of foo in backups will be renamed with a date suffix before the new foo is copied into backups.

This simple procedure does the job for me, only that I would like a deleted file to be renamed with the date suffix instead of being removed from backups. That is, if foo is deleted from source, then rename foo in backups with the date suffix.

I have tried to achieve this but so far no success. Any ideas?

3 Answers 3


Adding the --backup-dir option should do what you're looking for:

--backup-dir=DIR In combination with the --backup option, this tells rsync to store all backups in the specified directory on the receiving side. This can be used for incremental backups. You can additionally specify a backup suffix using the --suffix option (otherwise the files backed up in the specified directory will keep their original filenames).


rsync -ab --backup-dir=versions --suffix="."$(date +"%Y%m%d%H%M") --delete /source/folder/ /destination/folder

This would create backups of your files at /destination/versions

Source: https://linux.die.net/man/1/rsync


Add the --delete option to your rsync command. --delete tells rsync that when it sees a file that is in the destination but not the source, it should delete it from the destination - except since you are also using --backup, instead of deleting the file it will rename and/or move it, depending on whether you've specified a --suffix and/or --backup-dir.

In your case since you have specified a suffix that changes from run to run, you'll need to add a protect filter rule so that files previously backed up with a suffix don't get get renamed again:

--filter='P *.[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'

That filter pattern looks for filenames ending in a dot and then 12 digits, which is the format of your date suffix. That suffix is a bit ambiguous, so I'd suggest using some other format with some special character(s) or a unique string in the suffix, so that ordinary files won't be mistaken for backup files.


For incremental rsync backup used rsnapshot tool.

Sample rsnapshot.conf

snapshot_root   /backup

cmd_cp          /bin/cp

cmd_rm          /bin/rm

cmd_rsync       /usr/bin/rsync

cmd_ssh /usr/bin/ssh

cmd_logger      /usr/bin/logger

cmd_du          /usr/bin/du

cmd_rsnapshot_diff      /usr/bin/rsnapshot-diff

retain          daily   7
retain          weekly  4

verbose         2

loglevel        3

logfile /var/log/rsnapshot.log

lockfile        /var/run/rsnapshot.pid

backup  root@localhost:/etc/                   localhost/
backup  root@localhost:/home                   localhost/
backup  root@localhost:/var/www/               localhost/

Set Cronjobs For auto backup:

# m     h   dom mon dow command
#Run Rsnapshot At 02:00 Everyday
00      02      *       *       *       /usr/bin/rsnapshot daily
#Run Rsnapshot At 06:00 Every Sunday 
00      06      *       *       0       /usr/bin/rsnapshot weekly
  • At this stage I am looking for a simple, preferably one-line, rsync solution. If it does not exist, then I will perhaps (some time in the future) resort to more involved methods.
    – DustByte
    Aug 12, 2013 at 11:34
  • You can try following command once you delete source its rename files as per your requirements :) rsync -a --delete --backup --suffix="."$(date +"%Y%m%d%H%M") source/ dest/ Aug 12, 2013 at 11:39
  • Unfortunately the --delete option does not work. If you keep modifying a file, say foo, time stamps will repeatedly be added to previous time stamps, e.g. foo.201308121241.201308121242.201308121243 will eventually appear in backups.
    – DustByte
    Aug 12, 2013 at 11:45
  • @DustByte balazer's answer shows how to use the --filter option to avoid this renaming, thereby achieving exactly what you want. I personally do something like this, with a suffix of the form _220507~0957~ (date +"_%y%m%d~%H%M~") May 7, 2022 at 8:58

You must log in to answer this question.

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