Destructive rotation bugs

[sgpinkus]

There are three closely related bugs to do with destructive rotations:

1. With sync_first=1, link_dest=1 doing a "alpha" backup without a sync results in a "gap" in alpha interval backups, and potential loss of a backup without a replacement. Running alpha many times without sync can eventually leads to loss of all alpha level backups.
2. The same problem occurs at "beta" level with or without sync_first set. The consequences for bug 2 are somewhat less sever because "beta" level backups are older by definition.
3. sync_first=1, link_dest=0 doing a "alpha" backup without a sync results in a duplicate, not a backup. Many times -> many duplicates. An inexperienced user can be easily be misled to believe they have many backups when in fact they have many copies of the same stale backup.

sync_first	link_dest	BUG 1	BUG 2	BUG 3
0	0	N	Y	N
0	1	N	Y	N
1	0	N	Y	Y
1	1	Y	Y	N

---

The fix to bugs 1 and 3 is to always make sure you only do a "alpha" back up after a successful sync back when sync_first is enable. I.e. rsnapshot sync && rsnapshot alpha. A similar work around can be applied to bug 2: rsnapshot beta && rsnapshot alpha although this is slightly more cumbersome to setup as, say, a cronjob. In any case this is less than ideal, and can trip up inexperienced users. Ideally it should be fixed. The issue has been raised many times and there are a few PRs claiming to solve or partially solve the problem:

• do rotation only, if maximum previous level exists [patch]  #18
• Destructive rotations #33
• Rotate only if there will be a new <interval>.0 folder #34
• Rotate only if there will be a new <interval>.0 folder #92
• Destructive rotations, redux. #107
• Prevent unnecessary rotation without adding backup data #211
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901156

If and when this will be addressed is YTBD.