[SGVLUG] Mondo backups on "mondo" tape drives

[Jeff Carlson]

Tom Emerson wrote:
> I only mentioned Amanda because in prior releases of SuSE, this tended to be 
> listed "first" in the category of "productivity / archiving / backups"; it 
> was never actually installed "by default", so I haven't actually looked at it 
> "in depth" [but just before the latest install, I did start poking at the 
> docs, mainly 'cause Dustin asked about backups first... ;) ]

You've gotta watch out for that Dustin.  He'll get you into all kinds of 
things, like hard disk audio recording.

> it might also have been partly "my fault" in that I told the backup module to 
> create "media sized archives" (of 40GB), so perhaps "numbered archives" was 
> the method it was going to use, rather than recognize "/dev/..." as a special 
> type of file.  Then again, it did append ".tar", which isn't strictly 
> necessary for "device" files either.

True.  But you told it the file name is /dev/st0.  Yet it named it 
/dev/01_st0.tar.  That to me is broken behavior.  It should have 
attempted to open the file with that name, and since it was opening it 
with the tar command, it would have just done the right thing, since 
when tar opens a tape drive for writing, it writes to the tape.

> technically, it's for "home", but I also run a publicly-visible web server 
> (and pop/imap for my parents) and a few other things.  One thing I've found 
> is that "script kiddies" don't care if you're a lone-wolf or #2 on the 
> fortune 500 list -- if they see a "potentially open" vulnerability, they'll 
> hammer on it till something gives way (or they get bored, or someone in their 
> "group" breaks a different system and they all jump on that "bandwagon")

So?  I run HTTP, SMTP, IMAP, and FTP from my machine at home.  I also 
run NFS, LDAP, and even telnet.  But the script kiddies don't know any 
of that.  They don't get to see anything "potentially open" because I 
won't let them.  Do you need a nice iptables script?

> does this pick up things like /proc?  and what happens when it gets to 
> "/dev/st0" [ok, that might be easy to figure out -- /dev/st0 is "open 
> exclusively for writing", and thus cannot be read -- problem solved...]

Yeah, ideally you'd leave out /proc, /dev, and maybe even /tmp.  But 
when tar is packing stuff into a tarball, it's not going to care about 
the contents of a device.  It will see and store character device, major 
9, minor 0, not the contents of the tape again.  Same with /dev/hda and 
such.

> this is where my ignorance will show -- how exactly does tar handle the EOT 
> [end-of-tape] mark?  I'm used to a system that knows and expects it is 
> writing to tape, but I kind of gathered from the "docs" that you need to tell 
> tar in advance how large the "media" is [or did I misread this?)  of course, 
> the "attitude" the author has towards "man" pages kinda leaves a sour taste 
> in my mouth -- just because /he/ doesn't like them doesn't make it true that 

You know, I really don't know how it detects that.  I suppose the drive 
stops spinning and it gets some sort of device full back from the file 
system.  Yeah, that's kind of a dumb way to handle it, though.

> I'd imagine a creative use of "tee" or other I/O redirection to write the 
> list-of-files-stored to a file would do -- then it's a matter of "grep 
> <file-I-want> /etc/backups/contents/*" to pick which tape I need.

Oh sure.  It's just added hassle.  I only said it to illustrate that 
automated systems like Arkeia keep an index.