Dump(8) does not do incremental

Bigby James bigby.james at dimthoughts.com
Fri Apr 3 17:22:27 UTC 2015

On 04/03, Olivier Nicole wrote:

> I understand one may want to not implement the incremental dumps, but the
> default should enable them.

There are several reasons full upgrades are the safer and saner default.
Incremental backups are convenient because they consume less time in the
present, but the fact is that backing up data and restoring it do not deserve
equally consideration since restoring data is always a matter of immediate need.
Incremental backups require less time to create but are more time-consuming to
restore, and without a proper naming scheme incremental backups can
significantly raise the possibility of human error during the restoration

Finally, while the ideal scenario is a backup system that can be automated, one
cannot reliably automate a restoration process, so keeping things simpler and
more flexible for restoration should be the focus when setting defaults for a
backup system.

And of course strictly incremental backups just don't make sense in some cases,
such as when the base system and/or '/var' are stored on their own partitions.
In such a case, making a full backup takes a few minutes at the most on a
single-user machine, while if a lot of frequently changed time-sensitive data
like mail or specialized logs are stored in '/var' for a cluster or network then
incremental backups increase the risk of inconsistencies on restore (unless a
filesystem is unmounted when a dump is made, which isn't always an option).

Finally, you also need to consider that the manner in which people increment and
rotate their backups is a matter of personal preference, so coming to a
consensus on a default implementation of incremental backups would probably be a
real pain for the developers.

Defaulting to "back up everything in one place" is just the smarter option. It
lessens the learning curve and chances for error for new users and potentially
sacrifices a little convenience now for a big payoff in convenience and
assurance when they matter most later on. Although I have to agree that yes, the
nature of the /etc/dumpdates file could be more clearly documented. It's
mentioned several times in the man page, but perhaps a brief explanation should
be given in the 'Description' section near the top.

"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams

More information about the freebsd-questions mailing list