>
>
> I don't really know the details of bpc4. I think it always fills the
> most recent run and works backwards to clean up the old copies so you
> should have whatever files are still there even if some were somehow
> deleted. Still, if your pool filesystem is totally corrupted all
> bets are off - like it would be with any system
>
That is my understanding as well -- the most recent (and otherwise
configured) backup is always filled, and the previous ones are
reverse-delta'd from that.
I think the problem here is that filled != full, which is a concept that
I'm still wrapping my head around. Your scenario assumes that subsequent
incrementals are always built upon a full backup, which was the behavior of
v3. This would then cause problems when the full is deleted.
But here's how I think v4 is handling backups: Upon a new backup ...
* Copies/renames the previous (#N-1), most recent (which is always filled)
backup as #N
* Finds and transfers new files into #N
* Pushes OLD (aka original) files into #N-1
So, Backup #2 then only holds the files that were changed, with the changed
files + unchanged files in Backup #3. If you remove Backup #2, then you've
only lost the old versions of files that were changed in #3.
Craig notes in a few places that _any_ backup can be deleted -- I'm
assuming that BackupPC_backupDelete accounts for filling Backup #2 if
Backup #3 is deleted. But if the underlying filesystem itself is mucked up
...
At least, that's what I get from staring at the v4 docs for a while.
-Kris
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
