Re: [Gnumed-devel] Approaches to maintain clinical data uptime

[James Busser]

On May 3, 2006, at 5:59 AM, Karsten Hilbert wrote:

> On Wed, May 03, 2006 at 01:04:08AM -0700, Jim Busser wrote:

> > - can Syan or Karsten, if the work involved is limited, attempt a
> > load test of writing the dump file, so we might know how long this
> > would require and what its size might be...
> This is entirely dependant on the database content. The dump
> file may grow huge, indeed (several GB, eventually)

this would mean it cannot be copied onto single CDs, hopefully they  
would fit a DVD else each dump would have to be split over several  
pieces of media, which would be an incredible workflow pain (and  
pertinent to office procedures).

Also pertinent to workflow is the amount of time required for the  
backup dump to be written to disk so that the media could be taken  
away. Sure, it can be written instead at 0200h. It wouldn't matter  
provided the dumps had been encrypted AND the purpose of that media  
was purely notary, but if it may have to be the source of restoration  
(because there was no slave, or because the master and slave got  
corrupted) then that media would have needed to be taken away "live".  
So where office activity might end at 5:30 pm daily, the amount of  
time required for the dump to be generated, notarized, encrypted and  
written to media (hopefully automated) becomes of great interest to  
the last employee who may need to be scheduled to wait 10 vs 20 vs 40  
minutes to be able to leave, if the office policy is built around  
being able to take away the media. But if the dump does not depend on  
a "clean" work stoppage it could be scheduled to begin earlier, if  
any server performance penalty would be tolerable.