Jim Leonard wrote at about 00:17:04 -0500 on Tuesday, September 1, 2009:
 > Jeffrey J. Kosowsky wrote:
 > >  > BackupPC isn't "dependent" on volume management more than any other 
 > >  > program.  Volume management is simply one way to get around the 
 > >  > limitations of storing more data than a single device will allow.  Do 
 > >  > you think that expanding an SQL database would be different?
 > > 
 > > It would be *very* different since you can easily copy a SQL database to
 > > another disk while due to the large number of hard-links, copying pool
 > > data is not practical except at the block filesystem level. In fact,
 > > rsync works very well with SQL databases.
 > 
 > If you're using rsync to copy database files while they're still open, 
 > you've completely invalidated your argument.

Who ever said anything about copying database files while they are
open. This is now the 3rd time in a row that you have created and
attacked your own straw man argument. This is getting to be frustrating.

 > 
 > >  > Then I would suggest you haven't seen enough software.  Backup systems 
 > >  > are not trivial systems, and it should be implied that you would never 
 > >  > set them up without consulting their operation and requirements.
 > > 
 > > OK since you are such a software expert, name 5 common pieces of
 > > non-enterprise, user-space software that can't be backed up at the file
 > > level and instead needs to be backed up at the block level (which
 > > in turn pretty much implies the need for a dedicated filesystem for
 > > that data only)?
 > 
 > Now it is you who is using the straw-man argument, because backuppc 
 > *can* easily be backed up at the file level.  You just don't like how 
 > long it takes and/or that it doesn't work quickly with your favorite 
 > utility. 

Really - then why do people post on a more than weekly basis about not
being able to copy such a large number of hard links without rsync
crashing. Also, at some point if length of time gets unreasonably long
then it is effectively no longer a solution.

 > I have already mentioned that your filesystem's "dump" utility 
 > works perfectly well for copying your filesystem, hardlinks and all, 
 > ACLs and all, to another filesystem/file/tape/whatever.  I think you 
 > should actually sit down and use it before making claims that backuppc's 
 > pool isn't copyable using normal methods.

But how does that scale with number of hardlinks? Will it crash and
run out of memory? Will it thrash around in swap? Will it reliably
copy and recreate everything? If it doesn't scale well then it is not
a practical solution.

 > 
 > Here's a handy tip that doesn't even require temp space:
 > 
 > dump 0f - /pool | (cd /newpool; restore f - )
 > 
 > Oh, wait, you want to restore to a completely different machine?  Over 
 > the public internet?  Using compression and encryption?  Here you go:
 > 
 > dump 0f - /pool | ssh -C user@remotemachine "cd /newpool; restore f -"
 > 
 > And if you don't want to do a full dump ("0") then just use an 
 > incremental value (1, 2, etc.).
 > 
 > Now we can get off of the silly hardlinks suck/can't-be-backed-up 
 > argument and return to whether or not attrib should be turned into a 
 > database.
 > -- 

Works for me because I have always been more interested in the attrib
part (though I still think hard links in practice is an issue ;)

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