To create a local flash archive, setup
a disk slice (say c0t0d0s7) with a filesystem (i.e., newfs), and mount it:
| mkdir /export/flash
mount /dev/dsk/c0t0d0s7 /export/flash |
To create a flash archive of the local system and name
it (the name is arbitrary), run:
flarcreate -n mail-server-01 -x /export/flash
-c /export/flash/your_flash_archive_name
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
BigAdmin Submitted Article Using Flash Archive in the Solaris Operating System for
Disaster Recovery
Generic disaster recovery preparation for
the UNIX platform includes maintaining the server's configuration details. For
example, in the system information, you need to keep a hard copy of the method
you are using for backup and restore. If you use
ufsdump to back up the OS
to locally attached tape drives, the information to keep includes all the backup
file systems, the order of the file systems backed up, as well as information
about the backup tape, OS level, patch level, disk partitions, file system layout,
the third-party drivers, and so on.
The Solaris 9 and 10 OS releases provide a new
installation function called flash installation. With flash installation, you
can create a single reference installation of the Solaris OS on one system,
called the master system. Then you can replicate that installation as a new
installation on any number of systems, called cloned systems, that have the
same architecture as the master system.
Although flash installation is designed
to clone a master machine, I have done some tests and found it to be very useful
for disaster recovery. This article shows what I did to back up the system using
the flar
command and then recover the system using the backup on the tape. This test
used a Sun Enterprise 4000 server with the RSM Array 2000 disk system, running
the Solaris 8 OS, with the latest cluster patch installed. There were two 16
Gbyte internal disks. One had the original OS installed and the other was used
to test the recovery of the OS. A Digital Linear Tape (DLT) 7000 tape drive
was connected to the machine.
SUMMARY JumpstartWebflash Images Dan Cave
dan.cave at gmail.com
Thu Jan 27 05:40:24 EST 2005
A belated thanks to Iain Millar, Daniel Nuqo and Dan O'Callaghan who
kindly enlightend me to use the -S switch which doesn't spend time
processing the flar archive size, along with some very useful
information. I was also told that when recovering the flash images,
the jumpstart server decompresses the image into swap/memory.
I managed to reduce the time from 2hr, 34mins -> 1hrs 35m just by
using the -S switch., That was 30 minutes faster than using a
traditonal dds4 tapedrive on scsi3.
Interestingly, the time it took to archive the 22Gb flash archive over
1Gb network directly to the sagita san from the client over nfs was
exactly the same time writing to the JBOD raid 5 disk over Gbit NFS
which was attached at the jumpstart server. (i'd be interested to hear
you comments). Possibly a limiting factor of NFS?
Also, thanks to those of you, including Scott Cooper, who helped out
with getting me sorted with my original flasharchive/jumpstart server
and solaris2.6 questions.
You know who you are, thanks!!!
regards
dan.
My original post below with Dan's reply.
---------- Forwarded message ----------
From: Dan O'Callaghan
Date: Tue, 25 Jan 2005 10:05:34 +0000
Subject: Re: Jumpstart webflash image resore times.
To: Dan Cave <dan.cave at gmail.com>
Dan
You can save time with flarcreate by using the "-S" switch, stops it
calculating the size.
I've never had flarcreate accurately calculate the image anyway, i think
(could be very wrong here) but for this to work properly you need as
much swap space as the size of the flar.
The boxes i create are usually about 2-3gig in size and when i create
the initial image, the swap is usually around 500M. I've noticed that is
spends about an hour trying to calculate the size of the flar and then
gives up and creates the image as if i had uses the "-S" switch.
When you restore the image, i always have the message "no size
information of the flar archive". I'm using Solaris 8 2/04.
One day i'll add a temp swap file to see if i'm right.
On Thu, 2005-01-20 at 15:54 +0000, Dan Cave wrote:
> Hi all.,
>
> Previous to my last two emails, I thought I'd update you and ask for a
> bit of feedback.
>
> My orginal email asked if anyone knew whether it was possible to
> backup and restore solaris2.6 images created via flarcreate and
> restored via a jumpstart webflash archive on a solaris 8 box.
>
> Well, I successfully managed to build a jumpstart server (sol8) with
> flash image capability, recover the images after using Gbit ethernet
> point to point, and copying the flarcreate script to the 2.6 box,
> creating a 26Gb flar image(via a local nfs mount), which we usually
> store on a dds3/4 tape using ufsdump/ufsrestore.
>
> However, our usual tape resore takes just over two hours from a home
> rolled restore cd from which we boot.
>
> The restored flar image from jumpstart takes over two hours also,
> however I would have expected it to be quicker as I'm using Gbit
> ethernet.
>
> Has anyone had any experiences with restores from flar images which
> take roughtly the same ammount of time from tape? I've been
> enlightened that you cannot use compressed flash archives as they are
> purely for storage purposes.
>
> I was really looking to save time when creating and restoring flar
> (FRU's as sun call them) images using jumpstart, but I'm a little
> bemused as to why this is so.... I had applied the 2Gb patch for
> restoring flar images and have a working system from which I created
> my 26Gb image. (a mix of OS data, applications and user data)
>
> It takes 2hrs 43 minutes to work out and create my flar image over a
> Gbit net, as I also believe that roughly 40% of this time is spent
> working out how large the image is going to be. Some editing of the
> script and adding in timing debug which I added in and created a flar
> archive of my jumpstart server to work this out.
>
> Has anyone else experienced similar behaviour?
>
> Feedback is most definitely appreciated. I shall summarise..
>
> Regards
>
> dan.
> _______________________________________________
> sunmanagers mailing list
> sunmanagers at sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
--
SUN MICROSYSTEMS ON Tuesday introduced Sun Management Center Change Manager,
which is provisioning software for installing, updating, and auditing software
stacks on Sun Solaris systems.
The software dramatically reduces the time and expense of software upgrades
and installations, according to Jonathan Han, senior product manager for systems
management product marketing at Sun, in Los Angeles.
"Basically, this is a new installation and provisioning product that allows
you to rapidly and easily provision Sun ONE software stacks or your own custom
software stacks to various servers," Han said.
Users must first build a reference system for installs, which can take three
to five hours. Then, it takes 15 to 30 minutes to upgrade multiple serves, Han
said. "In the past, it would take a systems administrator on the average four
to five hours to install or apply updates" for each server, Han said.
The product, which features a choice of either a browser-based or command-line
interface, is based on Sun's Solaris Flash and LiveUpgrade technologies.
Key features of the product include:
* Archive Manager, for importing Flash Archives group into folders and deleting
and searching for an archive.
* Target System Manager, to add a new server or group of servers.
* Configuration Writer, to manage server configuration profiles.
* Software Auditor, to create a software stack manifest of one or more deployed
servers.
* Task Scheduler, to schedule service provisioning during offload hours.
The product costs $250 for a Managed Solaris Image RTU (Right to Use) license
for Change Manager; $5,000 for a single Change Manager management server RTU
license; or $50,000 for a single Change Manager Server RTU license for managing
an unlimited number of managed Solaris images from a single management server.
Paul Krill is editor at large at InfoWorld.
[Jun 22, 2005]
The Blog of Ben Rockwood Solaris Flash Archives: Protect your development box
If you've started to play with OpenSolaris you might have noticed
that one of our constant concerns is turning your beloved development
workstation into a brick. Brickification, or the result of a bad
BFU (upgrade), can be painful. You have to remember that OpenSolaris
is in fact the OS/Net conslidation of Solaris
(and we call the Solaris 11 codebase
we all now use Nevada, hence ONNV or OS/Net Nevada - thats OpenSolaris)
is not simply the kernel like Linux but the whole base OS, from
LibC to the tools, to the kernel, to the modules. On Linux if you
build a bad kernel, no problem, reboot and select a diffrent kernel
from GRUB or LILO and figure out what went wrong, but even on Linux
if you jack up GNU LibC or the base toolset your gonna be reaching
for a rescue or install CD. So when you upgrade a complete OpenSolaris
system a lot is at stake. For the record, you can infact install
only a kernel using the Install (pronounced Cap-Eye-Install)
tool, but thats not nearly as much fun as upgrading the whole system
via BFU. So, what we need is a way to protect our investment of
time and effort. On Solaris we have
two amazingly kick ass tools to help us solve this problem, and
they become more important than ever in OpenSolaris development:
Live Upgrade and Flash
Archives.
I've actually written a paper on OpenSolaris development that
covers both, but I haven't completed it yet and don't have time,
so I'll blog it in request to several folks who are curious about
it. I'd like to extend a hearty thank you to Mr. John S. Howard
who is no longer with Sun (who ever decided that was a dipshit),
who is the unquestioned Jumpstart, Live Upgrade,
Flash Archive god of
Solaris. John, you rule.
Live Upgrade (LU) and Flash Archive
(Flar) are both essentially big ass wrapper around CPIO, and neither
do anything that seems particuarly unusual at first look, they are
both definately "Ya, of course!" tools, but the point is that no
one else does it, at least not as well as they do.
Live Upgrade allows you to create a copy of your root disk onto
another disk in the system, and then (the Live bit) upgrade that
copy (which we call an Alternate Boot Enviroment, or ABE). When
you finish patching or upgrading the ABE you simply activate the
ABE and reboot into it. In this way you can do time consuming (a
complete recommended patch cluster on Solaris9 for instance can
take 3-4 hours to install) upgrades to Solaris
without incurring any more downtime than it takes to reboot.
Flash Archives
on the other hand are root disk images. You create a
flash archive using the "flar" tool,
which will output a single file containing your system image. We
can use these system images in a variety of ways to provide a robust
imaging and snapshot/backup solution. The reason
Flash Archives
are so much more polished than other solutions is the fact that
when you run the Solaris Installer (from
CD usually) you'll notice you actually are given 3 (or more) install
options: Install, Upgrade, or Flash.
When we create a Flash Archive we can
store it on either an NFS, FTP or HTTP server and then access it
again via a CD installer, as well as the fact that we can also use
these archives via both JumpStart and
Live Upgrade! When archives are installed
onto a system they are done with the networking unconfigured (just
like a sys-unconfig'ed system) making them great for imaging, just
get a Solaris install how you like it,
create the archive, then JumpStart install the archive onto your
pool of servers, effortless rollouts!
For our purposes we're interested in simply creating point in
time snapshots of our system. Flash
Archives indeed could be cron'ed and
made to act as a nightly backup solution, but there are certainly
better tools for doing that. When you feel you've got your box the
way you like you can use "flarcreate" to create a
Flash Archive, which we can store in
some place accessable via NFS, FTP or HTTP. If for some reason we
destroy or extensively damage our installation for some reason we
can just pop in the Install CD, enter the networking information
and point the installer to the archive... minutes later we're booting
back into our system. Every time I feel I've significantly improved
or upgraded a system I cut an archive just in case.
Creating Flash
Archives is easy. NFS provides the best
method for archive storage, imho, so mount an NFS share locally,
I prefer to mount to /flash. Then run
run "flar create" with the appropriate arguments like this:
$ flarcreate -n "Monolyth B16 Snapshot" -a "benr@cuddletech.com"
> -S -R / -x /flash /flash/Monolyth-Snapshot-`date '+%m-%d-%y'`.flar
So, looking at the arguments:
- -n adds a description to the archive (this is displayed
during installation later)
- -a adds a string containing conact information
- -S tells flarcreate to skip its size checks, normally it
will estimate the size of the archive prior to creating it,
which can take a really really long time, this argument just
lets us speed up the process
- -R specifies the root directory, by default its /, but I
often supply it for completeness.
- -x specifies a directory to exclude from the archive, supply
one -x per directory to exclude (ie: -x /opt -x /export). NFS
mounted filesystems are excluded by default, but again for completeness
I tend to put them in there anyway.
- (archivename).flar is the actual name of the output archive
file. You can name it whatever you want, but typically its wise
to put the hostname, archive creation date, and a .flar extention
in the filename just to help identify it. The filename should
be a absolute pathname, so since we've mounted our NFS archive
repository to /flash, we'll specify
that path.
If your not using NFS then you should create a directory to put
the archive in and be sure to exclude (-x) that directory during
creation before you move it to your FTP or HTTP server.
As you can see, Flash
Archives are quick and easy methods
of creation snapshot backups of your system. I used one just this
morning! I needed a bigger IDE harddrive in Monolyth, so I created
an archive last night before I left the office, then this morning
I shutdown, pulled the old drive completely and put in the new one,
booted the installation CD (Solaris
Express: Community Release in this case), setup networking, partitioned
the new drive, and then installed from my NFS archive, all from
the graphical installer. An hour later the copy completed and the
system rebooted. I didn't know anything had changed! I logged in
and got back to work. Absolutely painless and I've got a faster
disk with 70GB more space! :)
So, in the future as you play with OpenSolaris (or
Solaris) and for whatever reason think
that the system is good as it is, but you might want to reinstall
it, or you want to see what rm -rf / does or whatever, don't worry,
don't pull the drive and put it aside or mess with tapes, just create
a Flash Archive and know that if you
need to get back to where you were its only a quick install a way.
Enjoy.
For more information check out:
solaris jumpstart; solaris flash archives; solaris
volume manager; Some rather
complex but robust Bourne shell scripts written by Gary Mitchell ...
This article provides techniques to augment a
DVD-ROM-based installation with the services and behaviors typically provided
by a JumpStart server. The techniques presented in this article can be used
when you need to perform an automated installation of a Solaris Flash archive,
but are unable to use a JumpStart server. This article describes a procedure
to create a bootable installation DVD-ROM with a complete software stack on
a DVD that you can use to perform a standardized and fully automated installation
of the software stack from the DVD.
This article also examines the structure of a bootable Solaris OS DVD and provides
information about modifying installation behaviors to perform an automated install
of a Solaris Flash archive from a DVD.
This article introduces the concepts and best practices for using Solaris Flash
and Solaris Live Upgrade technologies to perform quick, consistent, controlled,
and reproducible Solaris Operating Environment installations and upgrades. Creating,
archiving, and deploying a Flash archive is covered along with how to create and
manage multiple boot environments.
I was recently asked how to extract
a single file from a Solaris flash archive and, funnily enough
it had never occured to me that it might come in handy some
day. The procedure is super easy.
First we split the flash archive into one file for each section,
the file we’re interested in is called archive. If you don’t
know the path and name of the file you want then list the cpio
archive and grep for it. The last step is to do the actual extract,
or copy in as it’s called in cpio speak.
# flar split myflasharchive.flar
# ls
archive identification predeployment summary
cookie postdeployment reboot
# cpio -it < archive | grep somefile
export/ldap/adduser.ldif
# cpio -ivdm export/ldap/adduser.ldif < archive
export/home/lasseoe/adduser.ldif
It can of course be a little
time consuming if you’re working with big archives and/or have
slow I/O. Have a look at the manpages for
cpio(1) and
flar(1M) for further information.
Hi everyone!
I'm trying to get cygwin cpio to view/extract a flash archive made on solaris
9.
According to the docs, a flash archive is just a cpio archive. Reading
the during the solaris install works fine, but I am having trouble getting cygwin
cpio to view it:
E:\>cpio -ivF v240-disbox-v1-08-archive /etc/release
cpio: warning: skipped 90486 bytes of junk
cpio: warning: archive header has reverse byte-order
cpio: warning: skipped 188023 bytes of junk
cpio: warning: skipped 1360 bytes of junk
cpio: warning: skipped 146962 bytes of junk
cpio: premature end of file
E:\>
both the file and the drive I am reading it with work fine.
I can't say I've used cpio much, but the man pages say that it should recognise
the format automatically.
any ideas what I'm doing wrong?
thanks,
chris
Re: CPIO with solaris 9 flash archives
On May 19 17:44, Peter A. Castro wrote:
> On Wed, 18 May 2005, Clemson, Chris wrote:
> >E:\>cpio -ivF v240-disbox-v1-08-archive /etc/release
> >cpio: warning: skipped 90486 bytes of junk
> >cpio: warning: archive header has reverse byte-order
> >cpio: warning: skipped 188023 bytes of junk
> >cpio: warning: skipped 1360 bytes of junk
> >cpio: warning: skipped 146962 bytes of junk
> >cpio: premature end of file
>
> How did you get the file to your PC? Did you FTP it? Did you remember
> to use binary mode? As an experiment, I FTP'd a Solaris 8 CPIO file in
> ASC mode and ran cpio against it. The results are similar to what you
> show above.
And just for the records, Solaris usually creates cpio archives which are
compatible with Cygwin. The output of file shows:
Solaris$ find . | cpio -o > x.cpio
Cygwin$ file x.cpio
x.cpio: byte-swapped cpio archive
Solaris$ find . | cpio -oc > x.cpio
Cygwin$ file x.cpio
x.cpio: ASCII cpio archive (SVR4 with no CRC)
I just tried it, out of curiosity. Both variations are readable by
GNU cpio.
Homan, Charles (NE)
Charles.Homan at GDC4S.Com
Fri Aug 15 12:52:58 EDT 2003
Thanks to Andrew Hay and Daniel Lorenzini for their responses. Suggestions
from them and Sun support ranged from using JumpStart to putting the
archives on one of the hard disks in the machine.
Unfortunately, although we use JumpStart pretty extensively, I can't put a
JumpStart server on these particular machines. The hard disk idea is a
pretty good one, although if the box goes up in smoke then it doesn't help
so much. The "official" Sun support answer vis a vis having an archive
split over multiple CDs was: "...at this time there is no way to do this.
[The engineers] said they will revisit this in Solaris 10." That makes
putting the archive on hard drive pretty attractive, and is the direction I
will be pursuing.
My other problem (with the unrecognized archive CD) was apparently that I
had written the CD with the archive down one level from the root of the CD.
Of course, the docs don't indicate that the archive has to be at the root
level, but when I re-wrote the CD with the archive at the root it worked as
expected.
My original question follows.
Regards,
/charles
> -----Original Message-----
> From: Homan, Charles (NE)
> Sent: Friday, August 08, 2003 11:53 AM
> To: 'sunmanagers at sunmanagers.org'
> Subject: Flash Archive issues
>
>
> Greetings,
>
> I have two Flash Archive issues. The first is an
> installation problem. The second is a production question.
>
>
> I am attempting to get a working configuration wherein I can
> boot from a CD, then install the system with a flash archive
> on a (different) CD. I seem to have hit a roadblack. I am
> using the Solaris 8 HW 2/02 media kit, as well as a Solaris 9
> media kit. My Flash Archive is Solaris 8 HW 2/02 - although
> I'm not getting that far, so I doubt it matters. ;-)
>
> There are two cases where the installation from CD doesn't
> work, and in both cases I am (*gasp*) following the
> instructions in the manual (Advanced Installation Guide, pp.
> 136-8.) More's the fool me for reading the directions, I guess...
>
> Case 1) Boot from the Webstart Installation CD, go through
> system ID, etc. It re-boots from mini-kernel. At the
> "Specify Media" panel I choose "CD-ROM". The system ejects
> the Installation CD, and I put in my flash archive CD. The
> system looks at it, and rejects it because it doesn't contain Solaris.
>
> I have tried the Solaris 9 Webstart Installation CD, and it
> exhibits the same behavior. I even tried to fake it out by
> telling it I had an FTP archive so it would let me choose
> other Flash Archives. It gave me a second media selection
> panel for my "other Flash Archives", which behaved exactly
> the same as the "Specify Media" panel did.
>
> Case 2) Boot from the software 1 of 2 CD with 'boot cdrom -
> w'. Go through system ID, etc. to the point where I can
> choose the media for my Flash Archive. I choose "local
> device", and follow the example on the screen to give it the
> path to my CD-ROM drive (/dev/dsk/c0t6d0s0) and the path on
> the CD to my archive. It does not give me the chance to swap
> the CD, but just looks on the Software 1 of 2 CD for my
> archive, and - of course - can't find it.
>
> The Flash Archive CD in question worked fine when booted from
> the network. (Solaris 8 2/02 image, installed from the very
> CDs I am trying to boot the machine from.) So I know the
> archive is readable, etc., I just can't get the installation
> program to look at it.
>
> Am I doing something wrong? Has anyone else seen this
> problem? Is there a fix, or at least a workaround?
>
>
>
> The second issue is, "How can I make a Flash Archive span
> multiple CD-ROMs?" In the fully installed configuration
> (including tools, not data) we will be approaching 4 GB to
> archive, which even compressed will take up several CDs. How
> do I go about this? Do I need to split the archive, or can I
> somehow write on consecutive CDs? (I don't see a way to do
> the latter with "cdrw".) Sadly, the "target" machines won't
> have DVD drives on them, or I would just go that route.
>
>
>
> Any help will be greatly appreciated, and I will summarize.
>
> Regards,
> /charles
>
> ObDisclaimer: Any opinions contained herein are mine and are
> not the property - or responsibility - of General Dynamics C4 Systems.
_______________________________________________
sunmanagers mailing list
sunmanagers at sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Sun blueprints/Building a Bootable DVD to Deploy a Solaris Flash Archive
-by John S. Howard
This article provides techniques to augment a
DVD-ROM-based installation with the services and behaviors typically provided
by a JumpStart server. The techniques presented in this article can be used
when you need to perform an automated installation of a Solaris Flash archive,
but are unable to use a JumpStart server. This article describes a procedure
to create a bootable installation DVD-ROM with a complete software stack on
a DVD that you can use to perform a standardized and fully automated installation
of the software stack from the DVD.
This article also examines the structure of a bootable Solaris OS DVD and provides
information about modifying installation behaviors to perform an automated install
of a Solaris Flash archive from a DVD.
Provisioning in Replicated, Mission-Critical Environments -by Jay Daliparthy
and James Falkner
This article introduces the concepts and best
practices for using Solaris Flash and Solaris Live Upgrade technologies to perform
quick, consistent, controlled, and reproducible Solaris Operating Environment
installations and upgrades. Creating, archiving, and deploying a Flash archive
is covered along with how to create and manage multiple boot environments.
The Solaris 8 Operating Environment (OE) 4/01 release introduced the Solaris
Web Start Flash extensions to the JumpStart framework. Web Start Flash extends
the JumpStart framework by adding the mechanism to create a Flash archive, a
system snapshot of the Solaris OE and all installed software, from a master
machine. This archive can then be used to rapidly install client systems; this
installation client may be any hardware platform capable of running the Solaris
OE, including those hardware platforms typically referred to as "servers".
This article will explain how to identify the master machine as well as provide
recommendations and examples of creating and administering Flash archives. This
article assumes the reader has an understanding of basic Solaris OE or UNIX
systems administration skills and a basic understanding of JumpStart technology
and the Solaris OE installation procedure
Generic disaster recovery preparation for
the UNIX platform includes maintaining the server's configuration details. For
example, in the system information, you need to keep a hard copy of the method
you are using for backup and restore. If you use
ufsdump to back up the OS
to locally attached tape drives, the information to keep includes all the backup
file systems, the order of the file systems backed up, as well as information
about the backup tape, OS level, patch level, disk partitions, file system layout,
the third-party drivers, and so on.
The Solaris 9 and 10 OS releases provide a new
installation function called flash installation. With flash installation, you
can create a single reference installation of the Solaris OS on one system,
called the master system. Then you can replicate that installation as a new
installation on any number of systems, called cloned systems, that have the
same architecture as the master system.
Although flash installation is designed
to clone a master machine, I have done some tests and found it to be very useful
for disaster recovery. This article shows what I did to back up the system using
the flar
command and then recover the system using the backup on the tape. This test
used a Sun Enterprise 4000 server with the RSM Array 2000 disk system, running
the Solaris 8 OS, with the latest cluster patch installed. There were two 16
Gbyte internal disks. One had the original OS installed and the other was used
to test the recovery of the OS. A Digital Linear Tape (DLT) 7000 tape drive
was connected to the machine.
Caution
- Do not modify the Archive Files section or you compromise the integrity of
the archive.