Backup slice creation date test
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
Menu
▾
▴
#228 Backup slice creation date test
I have a backup script using dar that has been running without issue for years. The version of dar being used is now 2.7.17 from debian trixie.
There was an issue on Saturday. The previous week's full backup done Friday required 40 4G slices. This week's Friday full backup required 39 slices. When the Saturday incremental ran this week, it balked because it tried to read the slice 40 from the previous week and thought the set was corrupted. A -t test also balked for the same reason. Once the old slice 40 dar file was erased, the -t worked as expected and reported no errors in the 39 slice full backup created this week.
Would it be possible to check the file modification/creation dates of the slices as you process them and reject any slice that is written before the first slice. I'm not sure why my file glob didn't remove the old slice - it did remove its par2 files - before writing this Friday's full backup. But that's my issue to deal with. dar shouldn't be trying to process files from previous backups after a new backup set is complete. I suspect if there was a gap in numbers - if the previous set had needed 41 slices and everything in 40 was gone for example, it would have processed fine. Unfortunately, testing this on a live system is a bit tricky as forcing just enough less to be backed up to make an off by one isn't easy. You might have more luck with a small slice size in testing.
I realize that it might be possible to script something to specify what is the last valid slice to prevent this, but it really seems like something dar should just do.
thanks for this feedback. The problem is that many users use scripts bounded to -E option to fetch a slice to disk (for example when stored on tape) the feature you request would break these scenarios. Another point is that the first slice is not always accessible before the "last" slice (for example when using removable media)...
To avoid this problem, I would suggest using the -affs option, which leads dar to fetch archive format information from the information in first slice instead of the last. Then dar fetches the catatog from the last slice, but as the archive has already been openned, it will report an error if the last slice according to filename is not from the same slice set as the first slice.
But probably the best (and very common) solution is to use date-based slice name for your avoid re-using the same base name between different backups. Why not doing that too?
trying to mix under the same name two slices of different backups leads to this error:
backup-A.1.dar is a slice from another backup, please provide the correct slice.I think the error message is clear, no?