[sf-lug] how to whack crackers

Rick Moen rick at linuxmafia.com
Tue Jan 6 11:46:40 PST 2009

Quoting jim (jim at well.com):

> recopying an entire filesystem every night is 
> not a good idea, just as a matter of form, not to 
> mention the hassle-factor of managing disk space 
> (the time factor seems okay if cron is doing the 
> work at night while i sleep). 

Overall, I think Michael Shiloh put it best:  "The half-assed system one
uses is better than the perfect system one doesn't."  I've been guilty
of this just as often as everyone else.  Maybe more so, because I'm
overcommitted on the non-paying stuff, and paying stuff comes first.
(So, at home, the cobbler's kids go unshod.)

One point that I urge for anyone's system:  Do an occasional sample
restore.  Otherwise, you really don't _know_ that you're doing anything
useful.  (This is why my standing joke with WAN/LAN consulting clients
is to call it a "restore system", not a backup system.)

If you have time / energy, there's nothing like a bare-metal restore, to
prove a backup strategy adequate and find problems before they become

>    i've considered making a tarball of a directory 
> and then submitting it to some version control 
> software and letting the version control software 
> do the work of storing the diff. haven't gotten 
> around to trying, opinions? 

Eek.  Checking a tarball into version control would be very suboptimal,
because the diff'ing algorithms really wouldn't work.  You'd basically
be storing snapshots in big binary blogs, with massive use of disk space
and no history.

Submitting the same tree as individual files, on the other hand, would

Joey Hess famously keeps his entire home dir in version control, and
just checks it out, wherever he is.  


(It's highly likely that he now does that in git rather than svn, given
his adoption of git for ikiwiki, etckeeper, and so on.)

By the way, for Debian / *buntu systems, etckeeper is highly
synergistic:  Joey designed it to integrate closely with apt, such that
all changes to /etc contents resulting from package operations get
registered automatically.

More information about the sf-lug mailing list