Les Mikesell wrote at about 18:24:20 -0500 on Monday, August 31, 2009:
> 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
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
4. Many $$$$$$$ in time and resources
This is assuming that your in-house IT policy will even let you add
a new (and presumably unsupported) OS.
>
> > 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.
Again, there are solutions available without BackupPC too. I can just
manually mirror all my disks every night or I could decide not to
backup at all. If you are satisfied with existing solutions then this
thread is not for you.
>
> > > > 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.
Which is why you want to *backup* your backup database which is one of
the whole points of this whole thread.
>
> > > 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. 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. 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...
------------------------------------------------------------------------------
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/
