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
lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
