A.P. Lawrence

using removable hard drive for backup

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: backup/restore using disk instead of tape
Date: Mon, 18 Nov 2002 06:26:59 GMT References: <60bd4c6b.0211161339.69262ce2@posting.google.com> <60bd4c6b.0211162058.130e5f07@posting.google.com> <20021116221414.R3983@mammoth.ca.caldera.com> <60bd4c6b.0211171317.4abbfc19@posting.google.com>

Brian K. White wrote:

> You insult me! I am using a commercial crash-recovery software thank
> you very much, and am perfectly willing to use any other one if it
> could do this. All I am not using is a *tape*. In this case it's ctar
> + airbag, I did't select them, but neither have I yet seen a need to
> tell my boss he has to switch to something else when he's been using
> this for years before I came along and it does the job as well as
> anything else as far as I can tell. I've had to restore a few times,
> to new/bigger hardware even, and it was fairly easy and worked. what
> else do I need? features like being able to fast-seek through a tape
> to get a particular file out fast, or putting more than one backup on
> a single tape using filemarks, or burning bootable cd's or dvd's are
> "neat" and all, but of no real world value to me.

Ok... I forget your exact scenario, but before we get all weird with
sconf and stuff, maybe you can do something else...

I'm making this up without looking back up-thread.  Suppose you have an
old machine with a small drive, and you want to move to a new machine
with a big drive (or even to the same machine with a new big drive as
root).  You could:

  1. add the new large drive as a secondary drive
  2. partition it "whole disk for Unix"
  3. divvy it with one division large enough to hold your backup, and
     physically at the end of the partition
  4. backup to that division (as a raw device)
  5. put the drive into the new (or old) machine at the bootable
     position (IDE primary/master, or SCSI ID 0, or whatever you can do
     with BIOS)
  6. use the crash recovery software to restore from that end-of-disk
     division onto a set of newly created divisions

Phone and Email Support at Monthly rates

For this to work, the new drive has to be twice as big as the old (well,
twice as big as the old data, or big enough for the restored old data +
a compressed copy of it in the bridge division).  This shouldn't be a
big deal since you're probably going from a 10GB drive to 180GB or
something like that...

This would still be tricky because you have to convince the crash
recovery software to let you add new divisions to the drive without
trashing the old one.  Or, I suppose you could do all the dividing under
the old root -- then you just have to convince the crash recovery
program to use the premade divisions.

> sconf looks like it might be the ticket, thanks.
> 
> other questions would be:
> 
> * perhaps I could use Sdsk=... Sflp=... and pretend the tar disk is a
> floptical?
> would the floptical driver work on a hard disk?

There's a chance that it would, actually.  Not a very good chance, but
worth a try.  You can try it without all the weird booting stuff, just
run `mkdev flopti` and point it at the SCSI coordinates of a trashable
hard disk; reboot; try to access it.

Oddly enough, you might also be able to lie that it's a SCSI CD-ROM,
with "Srom=".  The Srom driver doesn't support writing, but that would
be OK for your purposes.

In both cases I suspect you'll be foiled by the respective driver
complaining "hey, that's not a SCSI [floptical | CD-ROM]".  Chances are
pretty good that if you disabled only that self-check, the drivers would
actually work well enough to access data (probably not well enough for
live use).  Such disabling would be a simple patch in the Driver.o --
simple for someone who's into hacking such things, that is.

> * what happens when you have a kernel with a particular scsi driver
> and a few disks configured in, and then you boot up on new hardware
> with btld for the new scsi card, but don't put any Sdsk= on the boot:
> command line?
> do the disk devices automatically try to use whatever ha is found? Is
> this maybe exactlty what the "auto" keyword, in place of an "ha"
> driver name in the mscsi file is for? could I build a kernel that had
> several "likely" scsi disks configured, (adapter 0, bus 0, target 0-6,
> lun 0-6), with auto in place of the adapter name in mscsi, and then
> boot using a btld for the adapter, not specifying any Sdsk on the
> boot: line, or, specifying just the root (0,0,0,0) disk, and then be
> able to use any disk that fell within my "likely" range of addresses
> on the new hardware? (assuming I manually ran mknod to create the /dev
> nodes, or had them built into the floppy already.)

Hmmm, I can't see anything wrong with this idea.  "auto" gets filled in
with the first detected host adapter, so you get limited to just one HA
(until you're restored enough to start working on the _real_ kernel
configuration) -- probably not a fatal limitation.

In machines with multiple HA hardware, you can use "disable=fooha,barha"
to disable any drivers that are being detected before the one you need.

If the machine has two adapters using the same driver, there's no way
to prevent one from being recognized; in that case you're forced to
use whichever is recognized first.  (You might be able to affect the
recognition order by fooling around in BIOS setup, host adapter BIOS
setup, or by moving cards around in slots.)

The kernel on the install disks we ship has a couple of "auto" host
adapter disks, at least one tape and one CD-ROM.  I think it actually
has those on "standard" IDs like 0, 1 for disk, 2 for tape, 5 for
CD-ROM, and actually _does_ use `sconf` to reconfigure them on the fly.
You could do that, or you could preconfigure a lot of likely
coordinates.  I'm pretty sure you can safely configure two peripherals
to the same coordinates, e.g.

  auto    Sdsk    0       2       0       0
  auto    Srom    0       2       0       0

(/etc/conf/cf.d/mscsi entries) indicating both a disk and a CD-ROM at ID
2, LUN 0 of adapter 0 -- as long as you do not attempt to _access_ both
of them during one system uptime.

> I can, if all else fails, just "cheat" and build a boot floppy with
> the currently running kernel, but this means that in order to restore,
> I need the same model of raid card on the new machine. fine for
> restoring to the same box, and fine if the restore happens within a
> year or so, but I think a proper backup solution must allow you to
> restore onto a completely new box, in case the original hardware is no
> longer manufactured. And I have not been able to load btld drivers
> using the fully configured kernel on either the new or old boxes, only
> using the unix.install kernel. (the airbag utility lets you specify
> the kernel that will be built into the floppy)
> 
> thanks again for the reminder of sconf. that's probably my answer.

It's one of my top two choices, the other being the Swiss Army Kernel
with every HBA turned on and a whole bunch of "auto" entries in mscsi...

>Bela<

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/1757.html copyright 1997-2004 Bela Lubkin All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here