[ale] Backup frequency question

Tue Apr 13 10:58:26 EDT 2010

Ugh. "modern" windows medical apps use Microsoft access runtime (Jet) as the
db backend. It is total crap. More worthless than Access is.

OK. You're not totally hosed as you have mirrored drives. However, there's
no good way to know about how the system will respond to a "drive out"
failure without testing. That will be scary. PLan a weekend with backups and
extra drives pre-mirrored.

Specifically, if a drive simply fails (think lost power failure), it is a
safe assumption that the remaining drive has good data. However, if a sector
on one drive become corrupted and a sync occurs before the drive can
relocate that sector, which sector trumps? Failed sector will not flag the
drive as failed to the RAID controller but now there are two different data
sectors. Since the system is running a rather fragile filesystem (I can't
bring myself to call the jet process a database with a straight face), that
crappy sector actually has a fairly  high likelihood of crapping out the
process unless the app designers have implemented an extensive automatic
recovery process. Of the medical apps I've seen over the past 10 years,
there seems to be more code devoted to recovery than storage for this very
reason. Multiple backup indexes, duplicate database containers, etc. are
quite common in systems using Microsoft Jet. They use it because it's a no
cost tool to implement and yet it has no upward migration route that is less
than a total scrap and rewrite to migrate to larger backed ends like MSSQL
server.

stupid, simple flat files would be better and more reliable than using Jet.
Oh. Wait! That's basically what Jet is just without any way to access the
data without Jet since the file format is proprietary not from Jet but from
the mediacl app vendor!  AARRGGHH!!!!!

In your case, you _could_ test that a failed drive will not cause instant
system death. Also be sure that the drivers for the mobo RAID stuff are
installed and that it is all set to send a "HELP!" if a drive event occurs.

There are _some_ Open Source medical practice management tools around but
they are either for hospitals (The one sponsored by the VA is GPL v.2 and
paid for with federal $ and very, very good) or they are not quite ready yet
to be the sole tool.

That said, the two I've been watching, and I think they are ready for use
now are medical http://medical.sourceforge.net/ and openEMR
http://www.oemr.org/

Migration and training are nightmares, btw. The medical world loves
technology but loathes changing it. Computers are still rather scary things
compared to a defibrillator or a blood pressure monitor. What I have seen
that actually does work is to have the systems used for the medical app do
NOTHING else but that single tool. Put browsers and email somewhere else so
the app system is seen not as a computer but as a single purpose tool for
accessing and recording medical history and practice data.

On Tue, Apr 13, 2010 at 10:21 AM, William Fragakis <william at fragakis.com>wrote:

> Opinions requested from those wiser/smarter than me (which includes all
> of you, your pets and probably your houseplants):
>
> My wife's medical practice management software writes to a closed source
> database*. Prior to Jan, the version of the database we used allowed for
> "hot" backups - you could copy (we used rsync) the files to another
> server while the database was in use. Thus, we could make hourly copies
> as well as the usual nightly copy which was also sent off site. The
> hourly copies were written to a duplicate machine so if the primary data
> server failed in any catastrophic way, we'd have both the data and a
> machine configured to serve it available quickly. Losing an hour's worth
> of work seemed to be the level of risk we felt we could assume. We don't
> feel comfortable losing a day's worth of work. Of course, the database
> and the duplicate both use RAID 1, the primary server using Windows and
> hardware (motherboard) RAID and the backup, Linux software RAID.
>
> While the risk of losing both disks of a RAID are statistically low, I'm
> freaky about both data preservation and availability.
>
> Since Jan., an update in the database version prevents us from making
> live copies (we either have to kick off all the users or ignore file
> locking, both not what you want for obvious reasons). We can still make
> nightly backups but we are "naked" (at least it feels that way) for the
> next 24 hours.
>
> Ideally, we'd just migrate to an open source solution but, invariably,
> it's not that easy (or at least quick).
>
> In the meantime, am I being overly paranoid or should I be concerned? Of
> course, the vendor is telling me that I'm worrying over something that
> has a low probability and at this point has no plans to add a utility to
> the management program to allow live copies - which they could do but
> won't. I can't do it directly because they won't give us the level of
> access to the database we need to do it ourselves. Thoughts?
>
> TIA,
> William
>
> *Advantage Database ver. 8.1
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>

-- 
-- 
James P. Kinney III
Actively in pursuit of Life, Liberty and Happiness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100413/5030b3c6/attachment.html 