[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