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 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. > 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. > 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. > 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. There's a full backup from second-half-of-march of all drives sitting on the firewire drive attached to brutus. I hope to give that stuff a permanent home when we get the 1TB drive storage hooked up to helios. Combined with the databases, I think that's "enough". >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 cheers! LSD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
