Shane <[EMAIL PROTECTED]> wrote:
[big snippage]
>I too use BRU (the free version, from when Redhat included it in the 5.x
>series, you're allowed as long as you've went thru the upgrade path
>continuously), but I only backup my main "box" (that does everything
>from samba/nfs to www & sendmail for the time being).
Sounds like you got to use the "rhmask" process to get the new versions. ;-)
>This past weekend I picked up some 486dx266's that are making excellent
>linux boxes for all sorts of things, so I am trying to figure out how
>to consistently back them all up too, with the convenience of my
>nightly bru perl scripts running like they normally do.
Sounds like your backup scripts are a bit more complicated than mine. Does
the free version of bru come with sample scripts /bin/fullbru and
/bin/incbru? I've modified them slightly to suit my needs and they work
great for full & incremental backups. (You can do up backup levels from 0
to 9.) I run fullbru & incbru from a simple bash shell script that gets
kicked off by cron. The shell script does a couple of simple things like
stopping samba to close file, rewind/eject the tape, etc.
>It was my understanding that my version of BRU wouldn't backup
>nfs mounted drives, so this weekend I'll find out whether I need
>to purchase it or not, or move back to tar.
Yes, I think you need the full version to enable network backups, at least
using NFS. I don't know if you could use the PE version to write to
/etc/rmt using rsh/ssh or not - never tried it. I suspect it probably
won't work though, in which case you'll need to go back to tar or another
backup utility.
> >Now for the caveats:
> >In theory (and probably in reality) it's doable with a floppy disk, but I
> >decided to go a slightly different route.
>In the distant past I've read posts by people saying that they've made good
>boot floppies for use w/ bru on machines that are or are not direct/remote
>from
>the
>tape backup unit. I think I caught mentions of it on the
>http://www.estinc.com
>discussion/listserv archives at
>http://www.estinc.com/cgi-bin/messages?list=bru
I'll have to take a look.
>My thought was that the disk would have to have:
>1) a kernel that can handle the geometry of all the hard drives
> on all of the pc's you're backing up (ie if you're using
> one of those 40gb maxtors you need the ide patch or a ~2.4ish
> kernel.
>2) fdisk, mke2fs, e2fsck, mt, as well as /bru, /etc/bru*
>3) network config for eth0 as well as nic drivers
Sounds right. If you're restoring from a remote tape drive you'll also
need NFS or rsh/ssh.
>I found info about Tom's root/boot disk at http://www.toms.net/rb/
>but haven't had time yet to read about it, nor the bootdisk howto
>if one exists.
Read about it as well. Haven't had time to experiment with it.
> >I haven't had time to write up a good working description of how to go
> >about using my method, but I know it works because I've used it. In short,
> >it goes like this:
> >Obviously there are specific things for each step that need to be followed,
> >but that's the process in a nutshell. I've been threatening to write up
> >the whole mess as a web page, but I haven't gotten around to it yet.
>Oh, please do! Even though I think my method is heading into a
>different direction then yours I'm betting I could benefit from
>your documentation.
Ok, will do. It'll take a little while to write it up and flesh it out so
that it makes sense to someone other than me. When I get something
workable together, would you be willing to "be my editor", so to
speak? (See if the document makes any sense, offer suggestions, etc.)
>My general hope was to have run a script each night that would
>
>1) mount all the machines on the tape backup server via nfs as ro
That's the best way to mount NFS, especially for backup. Be aware that in
most cases backing up to a remote tape drive (either by mounting via NFS or
using /etc/rmt over rsh or ssh) will cause the tape drive to cycle quite a
bit because neither NFS or /etc/rmt seem to be able to keep the tape buffer
full. Or at least that's been my experience. Even hooked up at 100Mpbs
full-duplex the tape drive doesn't stay busy. I think neither NFS nor
/etc/rmt are terribly efficient for sustained transfers of many small files.
>2) backup the following from each machine (if needed)
>
>/home
>/root
>/bin
>/bru
>/etc
>/lib
>/sbin
>/usr
>/var
Rather than picking what you do want, it's often safer to exclude things
you know you don't want. Otherwise you run the risk of missing something
accidentially.
>I'm pretty sure it can skip /proc because that'd be recreated when the
>restored machine boots. I'm unsure about /dev.
Don't *ever* backup the contents of /proc, although you should backup the
actual /proc directory itself. They backup ok, but it gets a bit ugly when
you perform a full restore. No reason why you can't backup /dev. I'll
send you a copy of what's in my /etc/bruxtab if you'd like to compare it to
yours.
>Then on each machine, have a known machinename and ip for the "restore"
>bootdisk. If it's booted, it can read from the tape and restore
>a pc's drive(s).
Keep me up to date on this. As you said earlier, it's a different
direction than I've gone, but may prove useful anyway.
>Then with the boot floppy, on any machine I should be able to do a
>partial or full restore, or complete rebuild if needed.
You shouldn't need the boot floppy for a partial restore unless you've
managed to blow up one of the system directories.
-Eric
Eric Sisler
Library Computer Technician
Westminster Public Library
Westminster, CO, USA
[EMAIL PROTECTED]
Linux - don't fear the Penguin.
Want to know what we use Linux for?
Visit http://gromit.westminster.lib.co.us/linux
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
