Les Mikesell wrote at about 21:13:38 -0500 on Monday, August 31, 2009:
 > Jeffrey J. Kosowsky wrote:
 > >
 > >  > How's that?  You have to install some unix-like OS distribution. 
 > >  > There's not a huge difference.
 > > 
 > > Here is the difference:
 > > 1. SQL database
 > >   1. Most Linux distributions already include a version of sql in the
 > >     base install
 > >     If not "yum install mysql" or apt etc.
 > >   2. Continue to update and maintain your system as usual
 > >   3. Few if any $ in time and resources
 > > 
 > > 2. OpenSolaris
 > >    1. Get new hardware to run OpenSolaris (assuming your not converting
 > >             your whole shop
 > 
 > Most hardware that runs linux would run OpenSolaris as well or better.

Not all of us have spare servers hanging around or enough horsepower
to run a vm. This would be an added cost.

 > 
 > >    2. Learn how to install & setup Open Solaris
 > >    2a. Ensure security of new system, pass various 3rd party auditing
 > >               compliance standards (you do know that many companies 
 > > require that)
 > >    3. Continue to update and maintain Open Solaris
 > 
 > None of those things are any different for Linux.  And you probably didn't 
 > convert your whole shop to when you installed your first Linux
 > instance either.

I run Linux already. So there is no additional cost.
 > 
 > >    4. Many $$$$$$$ in time and resources
 > 
 > ???? No different than any other OS.

Not if you are already running that OS. Most enterprises that I am
aware of are *very* reluctant to add additional platforms to the point
of often blanket refusing to do so.

 > 
 > >    This is assuming that your in-house IT policy will even let you add
 > >    a new (and presumably unsupported) OS.
 > 
 > Someone had to install the first linux box which was a lot more risky.  And 
 > you 
 > can get pay for support if that is the politically correct thing to do.  
 > It's 
 > not like Solaris is an unknown entity to IT departments - being free is the 
 > only 
 > new thing about it. Well, that and zfs.

Most companies are looking to reduce, not expand the number of platforms.

 > 
 > >  > > 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.
 > > Which is why you want to *backup* your backup database which is one of
 > > the whole points of this whole thread.
 > 
 > Yes, but at that level you use the techniques the device offers.  Won't the 
 > NAS 
 > mirror its drives?

My NAS has 2 drives in RAID1 and as we all know RAID is not backup.
 > 
 > >  > >  > 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.
 > > 
 > > But the attrib file is in general nowhere near the pool
 > > file.
 > 
 > The link in the pool directory is irrelevant when you are traversing the PC 
 > backup directory.
 > 
 > > Especially, on subsequent backups. So moving the disk head to
 > > find the attrib file after loading the data file is not going to take
 > > any more time than moving the disk head to the database after loading
 > > the data file.
 > 
 > When you read the attrib file's directory entry you are either going to read 
 > the 
 >   data file's directory entry into cache or leave the head in approximately 
 > the 
 > right position for it.

But the data will be someplace else in the disk (i.e., in the
pool) so after loading the attrib file you will need to move the head
to read the data. Also, if you are restoring files across multiple attrib
files then the head will need to move to find each attrib file which
in general will be stored less efficiently than table entries within a
single database.

 > 
 >  > Potentially even less since in the database case it is
 > > more straightforward to ensure that the data files and the database
 > > are on separate disks while in the current case it is harder (if not
 > > impossible) to insure that the data and attrib files are on separate
 > > disks unless you use high level RAID...
 > 
 > Yes, if you want to impose a requirement that the database lives on 
 > different 
 > physical drives you could keep the table access from affecting the head 
 > position, but you still won't have already put it in the right place.

I'm not *imposing* the requirement - I'm saying that the database
approach more easily *allows* such an approach.

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