Jeffrey J. Kosowsky wrote:

>  > 
>  > Is it?  I think rsync or tar would handle them rather easily and toss 
>  > them on about any media without regard to having a matching database 
>  > application running.  
> 
> It would take a lot longer since it would be implicitly doing a "find"
> down a very large pc tree.

Which isn't a big deal unless you also have to track a million other 
inodes that were allocated elsewhere.

>  > Why is it OK require a sql database application 
>  > but not something like zfs?
> 
> Yes I know you run Open Solaris. However, 99.99% of computer users
> don't so we don't have access to zfs. On the other hand free sql
> database applications are available on just about any OS.   Why is so
> hard to understand that Open Solaris is not just an option for the
> average user.

We aren't talking about average users, we are talking about users who 
have a problem with something about backuppc - like scaling up or 
needing offsite copies.   So far I'm not running backuppc on opensolaris 
myself because my raid-mirroring works fine but I don't see anything 
stopping me or anyone else from installing it if zfs solves a problem 
for them.

 > It is also a lot easier to install a vanilla sql
> database app then to set up and maintain a new Open Solaris server
> just to run BackupPC.

How's that?  You have to install some unix-like OS distribution. 
There's not a huge difference.

> This is getting ridiculous. Just because BackupPC meets the needs of
> your particular environment doesn't mean that it meets other peoples'
> needs.

I'm just pointing out that there are solutions available.

>  > > Also, there are
>  > > well-known tools for checking database consistency while you need to
>  > > write custom ones for attrib files. 
>  > 
>  > I've found them to be as reliable as the underlying filesystem.  Perhaps 
>  > that is your real problem.
> 
> Then that is good I suppose since everyone was arguing for how
> reliable filesystem-based tools are.

Yes, except for people using a consumer NAS.

>  > and the usual case of getting both the 
>  > attributes and the data at the same time would probably be the same or 
>  > worse.
> 
> Highly unlikely. Why would a single database query and filesystem lookup be
> slower than having to find/open/read/decompress/parse an attrib file?

Because moving the disk head is always the slow part - and you've got 
the head looking at sql tables instead of doing read-ahead in the 
directory containing the file entry which is what happens when you 
access the attrib file.

-- 
   Les Mikesell
     lesmikesell AT gmail DOT com


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