Les writes:
> But will you still be able to restore the file state as of each separate
> run? Sometimes the reason you are restoring is that the current version
> is a mess. The issue could probably be avoided with a complete tree
> link copy before starting followed by in in-place update, but that is
> probably even less efficient.
Yes, the exact state of each older backup can be re-created.
As each backup occurs, two trees are operated on:
- the in-place update of the newest complete backup
- a new tree is created with the deltas to get to the
original, now older, backup. Eg: if a new file replaces
an old one, the old file is moved to this tree.
This new tree becomes the second-most-recent backup, stored
as a set of deltas (changes) relative to the newest complete
backup.
Each older backup in turn would be represented on disk as a set of
deltas from the more recent one. The only "filled" backup is the
newest one. To view or restore a particular backup, you start with
the most recent (complete) backup, and successively apply the deltas
to get to the older backup.
It's just the time-reverse of what BackupPC does already: to view
or restore an incremental, it starts with the next older full and
applies the deltas (forward in time) for each incremental level.
The new, proposed, layout would completely decouple the storage
from the backup type (ie: whether it was an incremental or full
the storage method would be the same).
As I mentioned earlier, you most often view and restore the
most recent backup. So the penalty doing the delta merges
for old backups is minor.
You can delete the oldest backup at any time, since nothing
depends on it. No longer will there be the issue of keeping
a full around because incrementals depend on it. There would
be no difference between expiry of incrementals and fulls - they
would be treated the same since they are stored the same way.
As discussed earlier, the only tricky part is deleting a backup
that isn't the oldest (as needed for exponential expiry). That
requires you to merge two deltas into one.
Craig
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
