Hi Gurus

I have a sun V210 server running a variety of apps. I generally do my
backups using standard unix tools (cpio). I would like your views on the
best method for backing up a sun server for disaster recovery purpouses. I
would like a straight forward one step process for re-creating myu server
should i loose a disk or should the whole thing be crushed by a 10 ton lorry
and needs to be set up on another bit if hardware.

many thanks
#regards
dean

In article <EeSdnaAQNJRH8inanZ2dnUVZ8h6dnZ2d@bt.com>, "a" <b> wrote:

> Hi Gurus
>
> I have a sun V210 server running a variety of apps. I generally do my
> backups using standard unix tools (cpio). I would like your views on the
> best method for backing up a sun server for disaster recovery purpouses. I
> would like a straight forward one step process for re-creating myu server
> should i loose a disk or should the whole thing be crushed by a 10 ton lorry
> and needs to be set up on another bit if hardware.
>
> many thanks
> #regards
> dean

Here's some general guidelines:

Solaris doesn't have a "bare metal restore" bootable tape akin to mksysb
on AIX or the Ignite bootable tape, so you'll have to rebuild from
install media. The standard practice is to keep the installation media,
printouts of any volume layouts and patches installed, copies of any
software and license keys (e.g. Veritas Volume Manager--VxVM), and
hardcopy of other system information (DNS, router, printers, etc.). Oh,
and you'll need a full set of your last full backup plus the most recent
differential incremental.

If you're restoring the system to the same hardware, just with disks
replaced, boot from install media, layout the system disks the way they
were in the original (or change them if they need larger slices--this is
the perfect time to do that). Load the OS, install all patches, install
and setup any volume manager, configure volumes the way they were or
"upgrade them". Install the 3rd-party applications (e.g. Oracle).
Restore the data.

Oh, and the standard tool for backups and restore on Solaris is
ufsbackup and ufsrestore for UFS filesystems. If you're using VxVM,
it's their version of backup and restore. If you're using a 3rd-party
backup tool like Netbackup or Networker, you'll need to have the backup
server up and running before restoring the data from your tapes (along
with a license for the backup software in your box).

If you're restoring to a different system than the one that's dead (e.g.
different architecture or hardware model entirely), make sure the
restored system will run on it before disaster strikes. If you have no
control over what machine you'll get in the event of an full disaster
restore, you've got bigger problems that need solving first than the
"how to".

All this is different of course if you're not using tape backups. But
you knew that. I leave the step by step writing up to you. Good luck.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Michael Vilain wrote:
> In article <EeSdnaAQNJRH8inanZ2dnUVZ8h6dnZ2d@bt.com>, "a" <b> wrote:
>
>> Hi Gurus
>>
>> I have a sun V210 server running a variety of apps. I generally do my
>> backups using standard unix tools (cpio). I would like your views on the
>> best method for backing up a sun server for disaster recovery purpouses. I
>> would like a straight forward one step process for re-creating myu server
>> should i loose a disk or should the whole thing be crushed by a 10 ton lorry
>> and needs to be set up on another bit if hardware.
>>
>> many thanks
>> #regards
>> dean
>
> Here's some general guidelines:
>
> Solaris doesn't have a "bare metal restore" bootable tape akin to mksysb
> on AIX or the Ignite bootable tape, so you'll have to rebuild from
> install media. The standard practice is to keep the installation media,
> printouts of any volume layouts and patches installed, copies of any
> software and license keys (e.g. Veritas Volume Manager--VxVM), and
> hardcopy of other system information (DNS, router, printers, etc.). Oh,
> and you'll need a full set of your last full backup plus the most recent
> differential incremental.

I would say that "standard practice" nowadays is more like having a
jumpstart server and use some Flash Archive scenario for getting the
system to a predefined state including licenses, software, patches etc.
After each system change you just make a new archive. Keep a couple with
revisions and you can roll back to a working one quickly. After that you
can just roll back user data from the backup system.

http://www.sun.com/bigadmin/content/...sh_archive.jsp is one
start...


> If you're restoring the system to the same hardware, just with disks
> replaced, boot from install media, layout the system disks the way they
> were in the original (or change them if they need larger slices--this is
> the perfect time to do that). Load the OS, install all patches, install
> and setup any volume manager, configure volumes the way they were or
> "upgrade them". Install the 3rd-party applications (e.g. Oracle).
> Restore the data.

If you're doing that by hand you're probably out of work before you're
finished. It takes too long compared to automate it.

> Oh, and the standard tool for backups and restore on Solaris is
> ufsbackup and ufsrestore for UFS filesystems.

It is?

If you're using VxVM,
> it's their version of backup and restore.

What? VxVM is the volume manager...

If you're using a 3rd-party
> backup tool like Netbackup or Networker, you'll need to have the backup
> server up and running before restoring the data from your tapes (along
> with a license for the backup software in your box).
>
> If you're restoring to a different system than the one that's dead (e.g.
> different architecture or hardware model entirely), make sure the
> restored system will run on it before disaster strikes. If you have no
> control over what machine you'll get in the event of an full disaster
> restore, you've got bigger problems that need solving first than the
> "how to".
>
> All this is different of course if you're not using tape backups. But
> you knew that. I leave the step by step writing up to you. Good luck.
>

a wrote:
> Hi Gurus
>
> I have a sun V210 server running a variety of apps. I generally do my
> backups using standard unix tools (cpio). I would like your views on the
> best method for backing up a sun server for disaster recovery purpouses. I
> would like a straight forward one step process for re-creating myu server
> should i loose a disk or should the whole thing be crushed by a 10 ton lorry
> and needs to be set up on another bit if hardware.
>
> many thanks
> #regards
> dean
>
>

One of the first, most important, things to do is to verify that you can
restore your backups! More than one sysadmin has discovered, to his
horror, that something critical didn't get backed up, that his backups
were unreadable, etc, etc.

This is best done by testing at a Disaster Recovery "Hot Site"!

Can your backup tapes be destroyed by the same "10 ton lorry"? Do you
have the necessary documentation for your hardware configuration? After
that ten ton lorry has finished its work, how many disks will you
need? What size disks do you need? How must they be partitioned? If a
V210 should not be readily available, what else can you use? Next
larger/faster model? Two smaller slower? How much RAM do you need?

Can another tape drive read those tapes? It has happened more than once
that a tape drive has become worn to the point that it is the one and
only drive that can read the tapes it wrote.

Do you have a Disaster Recovery Plan? It should tell you, or your
successor (if you don't survive the disaster) where to go, how to
restore, etc, etc. If should be sufficiently detailed that a complete
stranger should be able to execute it. That complete stranger may be
sadly deficient in Sun/Solaris skills.

If your data center had been in the World Trade Center on September 11,
could you, or your successor, recover your company's data processisng?
With little or no loss of data? THAT is the "acid test"!!!!

Your company may be able to survive the loss of X hours of data. You
need to get an authoritative estimate of the value of X! How many hours
or days can your company survive without access to your data? You need
that number as well. The two numbers will drive your planning.

Doing all this stuff takes time and costs money. If your company is
serious about this, it will spend the time and money. If it's not
serious, make sure that your resume is up-to-date and that you have a
copy off-site! Try to be somewhere else when the disaster happens.