The following section gives you an overview of how flash archive can be used to
perform bare-metal recoveries. It also provides a list of setup questions to consider when
setting up flash archive.
Before using flash archive, there are many things to consider. This section will
help you decide which methods of backup and recovery are best for you, based on your
requirements.
Flash archive has the following minimum system requirements:
Warning
Please test your flash archive recoveries before you really need them. You don’t
want to find out that your new system isn’t supported or that your method of
recovery won’t work.
When restoring an existing image, your Sun system must have a CD/DVD drive and a
bootable CD/DVD of the Solaris operating system, or access to a Solaris network boot
server that supports flash archive installations. The version of Solaris used should
be the same or greater than the version of Solaris used on the source system. For
example, when recovering a Solaris 9 (HW 09/05) server, you should boot from a Solaris
9 (HW 09/05) or later CD/DVD. (The urgency of this requirement varies depending on the
OS version, but I strongly recommend that you use the same or later version CD to
avoid potential problems.)
If you plan to perform restores to dissimilar hardware, the system being backed up
should include the entire Solaris distribution plus OEM support
(SUNWCXALL). If you are restoring a system with a limited
Solaris distribution to a system with different peripherals or of a different
architecture (for example, Sbus versus PCI bus), required drivers may be missing and
the recovery can fail. If you plan to perform restores on the same hardware, this is
not a requirement.
Your individual requirements determine how frequently you create flash archive
images. If you’re using flash
archive images only for bare-metal recovery purposes, you definitely need to create a
new image every time you make a change to the server that you want included when
performing a bare-metal recovery. Most users of flash archive, though, automate the
creation of fresh flash archive images on a regular basis, which makes sure that your
system images are always up to date.
Flash archive images can be written directly to disk or tape, and you’ll need to make a choice as to
which option works for you. How you plan to use the images plays a large part in
determining whether to use tape or disk. For example, if flash archive images are
created solely for the purpose of off-site bare-metal recovery, you may conclude that
a tape-only environment is right for you.
Most environments use a combination of tape and disk by storing a flash archive
image on disk, and then copying to tape periodically. This lets you send a copy of the
image off-site for disaster recovery purposes and retain a copy on-site to restore a
server locally. Companies may also choose to implement a
flash
image server. In this case, flash images are stored on and restored from
a central server. Many system administrators also use their existing Jumpstart boot
servers to store their flash images (Jumpstart is a Sun tool used to simplify Solaris
installation). This provides a network-based boot and an image to recover from all in
the same place. In either case, the server may also have one or more tape drives
attached to provide an easy way to create portable copies of the image for storage
off-site.
If you are considering using disk, keep in mind that sufficient disk space is
required to store the flash archive images. Depending on the options selected during
the image creation process, a flash archive is typically between 75 and 100 percent of
the size of the filesystems included in the archive.
Restore from tape or disk?
A flash archive image can be used locally to restore the Solaris operating system on a server
that has failed. In this scenario, either tape or an NFS mount provides an excellent
source from which to recover. If hardware and network resources permit, it is
recommended that images be stored on disk and restored over an NFS mount. Generally,
this method requires less locally attached hardware (useful when recovering multiple
servers) and is usually faster than tape.
A flash archive image can also be used to restore a system in an off-site
location, such as in the case of a disaster recovery. In this scenario, a company may
decide that restoring critical servers directly from tape is its best option. Others,
depending on several factors (number of servers to restore, hardware availability,
etc.), may decide to restore all flash images to disk and perform the actual flash
recoveries from an NFS mount.
Finally, another option worth mentioning is the use of cloning in conjunction with
flash images to build new servers. This option allows users to deploy a standard,
hardware-independent build to servers much quicker than if Solaris had to be installed
separately on each system.
Interactive or noninteractive restore?
When deciding how to set up flash archive, you first have to decide whether you
want to be able to perform an interactive or noninteractive restore. An
interactive restore requires almost no
initial setup but more input is needed during the restore process. It may also entail
more significant post-recovery efforts. A noninteractive restore
method requires more setup work but calls for little to no input during the restore
process (when time is typically critical).
Either method is considered acceptable. However, since time is usually most
critical when a server is down, most system administrators find the time spent
creating the files and scripts up front for the noninteractive restore method to be a
worthwhile investment.
Other environmental constraints
Many organizations use DMZs and other network tools to restrict access from
certain systems to the production network. If this applies to your company, consider
how it will impact your implementation of flash archive.
It is recommended that the flash archive infrastructure in a DMZ should mirror
what is available in production. Examples of required infrastructure include tape
drives, NFS servers, and backup servers. If resources are not available to mirror the
production infrastructure, be sure to have a tested, reliable process in place to back
up and restore the servers in the DMZ.