Successful System Recovery using Ignite-UX

any other cost). This is significantly lower than the cost of a disk array to hold the equivalent
amount of data (1500 GB) on disk.
Network
When deciding whether you should use network or tape recovery, you need to review your
network infrastructure.
For network recovery, you must have the available bandwidth on the Ignite-UX server to create
recovery archives and recover systems without adversely affecting production applications. If your
Ignite-UX server is shared with an application, you need to ensure that creating recovery archives
or recovering systems does not affect the application, or you must understand that the performance
of the application may be degraded while creating recovery archives or recovering systems.
When creating network recovery archives or when recovering systems while all of the network
traffic goes through the one network interface on the Ignite-UX server, then the more concurrent
recovery archives being created, the more the network interface becomes saturated. Ignite-UX does
not place a large memory load
9
on a system, only potential network congestion issues.
It is possible that with a lot of systems creating recovery archives to the Ignite-UX server at the same
time, the time required to create any one archive will be much higher than if you were to create a
lower number of recovery archives concurrently. This is because the Network File System (NFS)
traffic being sent to the Ignite-UX server may cause network congestion on the Ignite-UX server, or
the Ignite-UX server may not be able to process the NFS traffic as fast as it is being sent. If you
have time constraints when creating recovery archives (a fixed time window), you should monitor
for this occurrence and take appropriate steps to ensure the time is not exceeded.
You should be aware that Ignite-UX commands do not control the routing of the traffic between the
Ignite-UX server and client. The IP address or hostname that you specify as the Ignite-UX server
controls this traffic. If the Ignite-UX server is multi-homed and you want to control the network
interface to use, you can only control it with the Ignite-UX server name or IP address using the –s
option of make_net_recovery. You should inspect the routing tables on the client system to see
how the traffic will be routed from the client system to the Ignite-UX server. If you use the Ignite-UX
Graphical User Interface (GUI) to create network recovery archives, you cannot give the hostname
or IP address of the Ignite-UX server because the Ignite-UX GUI always gives the official hostname
of the Ignite-UX server as an argument to the –s option.
It is important to understand that, with a multi-homed Ignite-UX server, if the client has to route traffic
to a different subnet, it impacts other traffic flowing between the subnets. If the Ignite-UX server has
no network interface on the same subnet as the client, you must provide a boot helper or perform
dual-media recovery (booting from CD first and then contact an Ignite-UX server for recovery. For
more information regarding either of these topics, refer to the Ignite-UX Administrators Guide.
An overloaded network infrastructure can be very expensive to replace or upgrade to technologies
that provide more bandwidth (for example, using switches that support auto-port aggregation or
replacing a 100Base-T backbone with Gigabit Ethernet).
9
Low-end and uniprocessor systems may, however, see a large CPU impact on the system when creating a recovery archive over the network
as the archive is, by default, gzipped when created.
8