gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Brutus going down
Date Wed, 18 May 2005 20:33:53 GMT
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message