Technical Exhaustion

I unwittingly stumbled across a reasonably well hidden Bacula design foible today.

I’ve noticed for some time that when doing test restores, or browsing the ‘most recent backup’ for a client Bacula has included files that should not be there based on the timeline of the restore.

If, after performing a full backup, some files are deleted and then a differential (or incremental!) backup is taken these previously deleted files would still be restored if I did the ‘latest backup’ for a client.

The expected behavior (in my opinion) would be for these files not to be included in a restore of the most recent backup as, at the point in time the latest backup was taken, the files were not on disk.

This is a known feature of Bacula and is documented as a sub-project to fix

This has been underway since 2005, hopefully good progress is being made.

Unfortunately this means that any restores made expecting a ‘point in time’ snapshot of the system to be written back to disk will not behave as expected.

This may leave the system in an inconsistent or, at best, unknown state. This will also skew disk usage for a restore, using more space than expected and may either cause problems depending on the target disk size or necessitate a spring clean post restore to tidy things up again. This would be particularly painful for administrators with busy systems and lots of changes between incremental and differential backup windows.

This only occurs between each full backup so one workaround would be to perform a full backup each day but this is not often a practical solution.

It’s some comfort that at least the data is backed up safely and that data can be retrieved in some form, however this makes the restore process a little more complicated than it perhaps should be.