[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Approaches to maintain clinical data uptime
Date: Wed, 3 May 2006 18:00:58 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Wed, May 03, 2006 at 08:29:10AM -0700, Jim Busser wrote:

> 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.
No stoppage is required. Schedule starting the dump so that
it finishes when the offices closes. If that slows down the
server noticeably there are several approaches:

- take the backup from a replicated slave
- beef up the server
- schedule downtime for the RAID to be split, the dump taken
  from there and the RAID re-joined -- this is quite
  complicated in practice

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]