Carl Wilhelm Soderstrom wrote:
>>> My understanding of how BackupPC works in this regard is imperfect. Why
>>> can't the old partial backup be updated, in the way that conventional rsync
>>> updates an old copy?
>> BackupPC doesn't do anything in place on the server. It always
>> creates a new directory tree for each backup. In contrast, with
>> typical usage rsync does things in place.
>
> ah, I see.
> I think I see some of the arguments for doing things this way, but what was
> *your* reasoning when you first designed this architecture? It's rather
> unusual compared to the other rsync-backup programs I've seen (or built).
If you are going to keep snapshot-looking backups around at various
points in time you can't modify in place. That is, if I restore from a
certain day's backup run, I expect it to still have only the files that
existed at that time.
>> In 3.1.0 I've added a check that a new partial won't replace an
>> old partial unless it contains more files, so that should avoid
>> the annoying problem of a new partial potentially being smaller
>> than the last.
>
> Much appreciated. Thanks. :)
> Ideally, the new partial would be merged with the old partial tho. I guess
> we'll have to wait for a newer version for that feature. (alternatively, how
> much would it cost for someone to pay you to add that feature?)
>
>> The issue is that the proposed new style of storage would be most
>> efficient with in-place updating of the last (complete) backup.
>
> ah, so you're planning on abandoning the creation of a 'new' tree with every
> backup, and going to in-place updating, which means we get normal rsync
> behavior. (Thus obviating my comment above).
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.
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
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/
