Leo Simons wrote: > Adam wrote: > >>Stefano wrote: >> >>>DON'T KILL THE LOGS!!!!! > > > Hehehe. I already had mysql backed up locally. > > >>Would that they'd be logs. We never had space (or haven't optimized >>sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a >>lot, but exist, if wanted. > > > I really doubt we'll be able to salvage much from those. And they take > up a few 100 megs.
I will dump those out myself. I just bought a 250Gb firewire drive :-) (and my group is buying a new box that has 1Tb of stuff in it, disk space is not our problem any more ;-) >>I hope we give good consideration to 'Net >>history (and access for external services, e.g. google) with Gump3. > > > Aye. > > >>>Adam, can you give us (or leo) pointers to where is all the data that >>>gump saves so that we can restore it on the new installation? >> >>Basically there is the MySQL database, and a DBM file (at >>/usr/local/gump/public/gump/work/stats.db). These contain what history we >>have. [Same DBM exists for Kaffe, JDK1.5, etc.] > > > Got all of those. 1000kb, gzipped. that's it? >>BTW: Are we saving the crontab and any scripts in ~gump, Leo? Could be >>valuable. Where ought we put these to be moved, into Gump SVN? > > > yes. Also see http://wiki.apache.org/gump/VmgumpConfig > > >>BTW: I hope '/usr/local/gump/packages' is being moved across. > > > yep, those are on vmgump as well. cool. > > >>That'd remove >>a huge chunk of the pain of a fresh install. > > > Really, it'd be good to go through that pain. There is *so* *much* cruft > in the packages dir. We've only added there (for many years), never > pruned. No-one can really mirror our install and get a similar tree > without that cruft. very true, but it's going to be painful to replicate. you volunteering? ;-) > > >>Also, if we kept >>'/usr/local/gump/staging' (along w/ timestamps) then Gump might continue to >>accurately records how long since a code update (on more stale projects.) > > > Uh. Gump's been running on vmgump for a while. It'd mean throwing /that/ > info away. > > ... > > We shouldn't be /too/ fussed about being librarians. Or, alternatively, > scratch your itch. I will. Did I mention I work for the libraries :-) > There's a full backup from second-half-of-march of all drives sitting on > the firewire drive attached to brutus. ah > I hope to give that stuff a > permanent home when we get the 1TB drive storage hooked up to helios. kewl. > Combined with the databases, I think that's "enough". I'll do another round of saving myself, but yes, that reassures me. > From a sysadmin POV, gump consumes too much disk space to be snapshotted > in full, and its hard (see above) to figure out what bits do need to be > saved, and near-impossible to do something with those bits. That needs > to be neatly split out. If you (no-one in particular) wish perfect > conservation of output, fix things so its easy to administer them that > way. I.e. > > /usr/local/gump/save-this-every-day > /usr/local/gump/save-this-once-a-month > /usr/local/gump/this-is-in-svn > /usr/local/gump/this-is-just-cache-lose-it-if-needed Yes, this is called for. Gump will be of incredible historical value in the future, but things get saved only when they are well behaving and now gump was not designed with digital preservation of its findings in mind... but given the cost of storage, I think we should rethink that. -- Stefano. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
