[sf-lug] how to whack crackers
Asheesh Laroia
asheesh at asheesh.org
Tue Jan 6 10:15:37 PST 2009
I'm going to defend my backup strategy, not as a personal issue, but to
clarify how this and other tools work.
On Tue, 6 Jan 2009, jim wrote:
> recopying an entire filesystem every night is not a good idea
That's why dirvish only copies the files that have changed.
> , 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).
Dirvish uses rsync to create hard links to past versions of files that
have not changed. So it does not waste space on storing files that have
not changed more than once, but each backup looks like a full snapshot
because files copied in the past are hard-linked into place.
cron does the work at night while I sleep; typically, one of the first
emails I read in the morning is the backup report, which almost always
says everything worked okay. (-:
> one olde-tyme way is move oldest to last, older to oldest, old to older,
> and then copy tonight's stuff to old. that gives a little hope for
> reclaiming work that got corroded and then backed up to old.
I don't like strategies like this that assume I'm an organized person; if
I'm disorganized once, and that happens to be when disaster struck, it's
no consolation that I can blame myself. I'd rather just have my data.
Version control it all, and then you can't lose anything. Disks are still
cheap (although Western Digital VelociRaptor drives that seek twice as
fast as any other SATA drive I've seen are a little more expensive, but
even they seem cheap enough to be worth it...).
> ls -t is one of my best friends, but automating
> the job of clipping off the newest entries for
> backup seems dicey.
Yes! Actually every time I "cd", I "ls -tr" (the -t sorts by modification
time; the -r reverses the order so that I see newest last so that new
things don't scroll off the top of my screen).
c.f. http://svn.asheesh.org/svn/public/conf/bashrc.cd_does_ls
> 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?
That's a nice plan; etckeeper is good for /etc for that. Then you can just
use "commit" to record those changes.
But again, I don't *rely* on it for backups.
> we do try to record absolute pathnames of files
> we've changed (pretty much config files in /etc/).
I'll show you the first entry automatically generated by "git log" on my
main server, rose. This commit was created when I set up a friend with
XMPP service on my server.
paulproteus at rose:/etc $ sudo git log --stat | head -n10
commit db00ca1e1e080b25d151c707aa97b95e9a63b4dd
Author: root <root at rose.makesad.us>
Date: Sun Jan 4 23:04:26 2009 -0500
+ chris XMPP
bind/cchan.org.db | 5 ++++-
jabber/jabber.xml | 1 +
2 files changed, 5 insertions(+), 1 deletions(-)
So that's my somewhat-extended plug for etckeeper and dirvish. More
convenience, less worrying. Par for the course in this extended trip into
the future from my teenage years.
-- Asheesh.
--
Q: Why did the WASP cross the road?
A: To get to the middle.
More information about the sf-lug
mailing list