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 Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
