On Sun, 9 Aug 2020 10:07:33 +0100 Jonathan Dowland <[email protected]> wrote:
> On Sat, Aug 08, 2020 at 10:22:51PM -0400, Celejar wrote: > >Fair enough. But less applicable in the case of backups, since restores > >are quite rare, as I've been pointing out. > > I'd agree they're probably rare, and certainly less common than backups. > But in my experience when you do perform a restore it's almost always > the latest version you want. They should not be as rare as they are. We > should all be in the habit of regularly performing a restore to test our > backups are working. Fair enough. But still, let's say you backup daily, and do a test restore once a month. Is the extra cost of daily rebasing the backup worth the once a month cost saving of a simpler, direct restore? I suppose, though, that with modern (or at least non-ancient) hardware the cost is not that great either way. > One advantage of the reverse-delta storage mechanism: With rdiff-backup, > if I want to restore the latest version I can simply copy the backup > repository (ignoring/excluding "rdiff-backup-increments" directory), I > do not need to use rdiff-backup itself. Which could be useful if the > backup tool breaks, or you can't easily install it on a restore target > for whatever reason (It requires Python 2 for example and that becomes > harder to get). Or if a catastrophic bug in the backup software means > the incremental storage scheme is corrupted in some way. Sure - but this wouldn't apply to backup systems that don't simply store even their full backups as ordinary files, but rather according to some internal protocol (I'm not quite sure about dar, the original topic of this sub-thread), and anyway require the native restore software to do a restore. Celejar
