Les Mikesell wrote at about 15:56:16 -0500 on Monday, August 31, 2009:
 > Jeffrey J. Kosowsky wrote:
 > > 
 > > No one said "education". I said warn users of the advisability of
 > > using a dedicated filesystem that can easily be
 > > copied/resized/moved. Because most people don't recognize the problem
 > > of copying/moving/resizing their BackupPC database until they have
 > > been using it for a while at which point it might be too late.
 > > 
 > > And I didn't say LVM is the only solution - though I am not aware of
 > > too many other solutions on Linux that allow easy resizing and
 > > spreading of a single filesystem across multiple solutions. If there
 > > are many others that allow that, please enlighten me...
 > 
 > You make it sound a lot harder than it is.  Just get some new disks the 
 > right size and start over, keeping the old filesystem around for 
 > emergencies until the new one accumulates a suitable history.
 > 
 > > I think you are the one with "shenanigans" based on your unwillingness
 > > to open your mind to other needs and other solutions -- and if you
 > > had been a long-time contributor to this newsgroup, you would realize
 > > that this issue continues to arise without satisfactory solution no
 > > matter how many times people parrot the words "LVM", "ZFS", "block
 > > copy", etc.
 > 
 > There are solutions.  It's your choice if you don't want to use them.
 > 
 > > It is a kludge to use hard-links as the way of tracking and expiring
 > > backups while using an attrib file to store the usual attributes
 > > associated with a file.
 > 
 > That might be philosophically true, but I can't recall an actual problem 
 > caused by the attrib files.
 > 

I have seen problems where the attrib files are not synchronized with
the backups or when the pc tree is broken. In fact, that is the reason
I wrote several of my routines to identify and fix such problems. Now
true, the cause is typically due to crashes or disk/filesystem issues
outside of the direct scope of BackupPC but there are real-world
synchronization and integrity issues that can arise.

Also, the slowness of reconstructing incrementals whether in the
web-based view or in the fuser view is in a large part due to both the
slow nature of attrib files and the fact that you have to crawl
backwards through the backup tree to find which is the latest visible
version of each file. Just think how many attrib files you need to
find, open, read, decompress, parse, etc. just in order to see what
files are visible and think how this scales when you have large
directories and many levels of incrementals. Indeed, there is no
question in my mind that a single well-constructed relational database
would be orders of magnitude faster here.

------------------------------------------------------------------------------
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/