Jeffrey J. Kosowsky wrote at about 13:58:41 -0400 on Tuesday, September 1, 2009:
 > It seems like a lot of issues with file-level BackupPC backups (both
 > full and incremental) could be solved if we had the following:
 > 
 > 1. No chain renumbering - either by using the full file md5sum or other
 >    better hash as the name of the pool file to (statistically)
 >    eliminate collisions or by using the existing
 >    scheme with collisions but not renumbering and allowing holes in
 >    the chain to occur. Note that their are pros/cons to each
 >    approach.
 > 
 > 2. Adding the name of the pool file to the header of the pool
 >    file. (note that if you ended up using a full file hash in #1, then
 >    this would have the added benefit of adding a checksum to each pool
 >    file)
 > 

It would be even better if we added the following 3rd change:
   3. Add an attribute to the attrib file that gives the name of the
          pool file to which each file is linked (if we get rid of the
      need for pool renumbering then we don't have to worry about it
          changing).

          Also include in the header of the attrib file the name of it's
          corresponding pool file since attrib files are also pooled.

 > #1 would simplify incrementals since then we wouldn't need to worry
 > that old links would need to be changed (i.e. renumbered)
 > 
 > #2 would simplify creation of pc tree links since the target of the
 > link would be recoverable from the file header.
 > 

Backups would now be trivial:
1. rsync (without the -H) the entire BackupPC tree (pool and pc),
   excluding f-mangled 
   files (but not directories) in the pc portion of the tree
2. Recreate the links by recursing through the attrib files

(Incremental backups would require just a trivial modification to the
above algorithm)

Note step #2 here would be optional for archival backups since the
pc directory tree together with the attrib files are sufficient to
recreate the links whenever necessary.

In fact this approach makes clear that the primary purpose of the hard
links is for ensuring that pool files expire properly and
"atomically". But since hard links are not needed in an archive, you
don't need to recreate them since for archival purposes, they are
fully coded in the attrib file

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/