--link-dest can be broken in some cases

[kapitainsky]

--link-dest can be broken if latest backup is pruned becsaue its value is decided before pruning old backups. It can happen if for example you don't run your backup for few days. It happened to me today and instead of creating nice incremental backup script started new full one.

Either --link-dest target value should be decided after pruning or pruning should leave latest backup untouched. We should never delete latest backup before new one is created.

So the most logical option is to move pruning to the end of the script. When i have moment I will create pull request

[kapitainsky]

it would work safer if fn_expire_backups is called before LINK_DEST_OPTION is set

[kapitainsky]

after a bit more investigation I think I know what happened. I had inprogress backup from many days ago.

backup0 backup1 backup2<-backup.inprogress

rsync-time-backup set LINK_DEST_OPTION to backup1 and started backup loop where one of the first things done is fn_expire_backups. backup1 being old enough for my expiration strategy has been pruned and rsync --link-dest pointed to not existing folder now.

[kapitainsky]

In my opinion the best approach would be for normal situation to run fn_expire_backups after all backup is finished or exceptionally when NO_SPACE_LEFT happens but then exlude from pruning two last backups (as we have one in progress and previous one which is the real full last one)

[kapitainsky]

this can also happen without backup.inprogress situation.

E.g. if my expiration strategy does not keep backups older than 10 days and I have following situation:

backup0 (20 days old) backup1 (18 days old)

I run new backup. rsync-time-backup points --link-dest to backup1 and creates new destination folder - backup2

backup0 (20 days old) backup1 (18 days old) <--link-dest backup2 (new backup)

next step is to run fn_expire_backups. backup0 and backup1 are pruned and instead of runing incremental backup rsync has to transfer all data.