Successful System Recovery using Ignite-UX

generations of recovery archives become important if there is a problem with more recent recovery
archives whose use prevents you from recovering a system.
This introduces ad hoc (created before and after major system changes) recovery archives should
have a retention period of 3-6 months. When choosing a retention period, you must choose one
that supports your business objectives.
The following issues for network recovery archives:
Typically, you may keep two recovery archives for a given system. This means that your backup
cycle for the Ignite-UX server (or other location where the recovery archives reside) must allow for
the retention of recovery archives that follows the retention cycle you have defined.
If the recovery archives are not kept on the Ignite-UX server, the system on which they do reside
must have its backups synchronized with the Ignite-UX server. It is pointless to create a recovery
archive unless you can recover the archive configuration onto the Ignite-UX server, as well as the
matching network recovery archive to the place where it is kept.
Retention periods for recovery archive tapes are simple since the tapes can be managed just as
any other tape in your tape retention strategy.
Caution:
You should review the Ignite-UX White Paper, Successful System Cloning
using Ignite-UX, for issues that could prevent you from successfully
recovering systems using recovery archives (tape or network).
Budgetary and other constraints
There are additional constraints that further determine the solutions that are possible for recovering
your systems. In general, the constraints are budgetary rather than technical. These constraints
and your business requirements dictate the solutions that are feasible and most effective for your
environment. The topics that follow describe some of the constraints that you may encounter.
Disk-space cost
The issue of disk-space covers several different areas and assumes that you are using
make_net_recovery to create your recovery archives. First, there is the cost of disk space
dedicated to recovery. Second, there is the amount of disk space that is available per system for
recovery archives. Lastly, there is the amount of recovery archives required per system.
Suppose, for example, that you have 100 systems connected to an Ignite-UX server for recovery
purposes and you need to save six recovery archives for each of the systems. Assuming that the
average size of the recovery archives is 2.5 GB, approximately 1500 GB of disk space is required
for recovery archive storage on the Ignite-UX server. If you are only able to purchase 300 GB for
recovery archive storage, then you have a dilemma: some systems may be limited to only one
recovery archive while other, more important systems will have multiple archives.
A possible hybrid solution this dilemma would be to use both the network and tape for recovery
archive creation and storage.
The cost of the disk space is not the only cost. Due diligence dictates that the recovery archives
must also be saved onto tape regularly so that they can be stored at an off-site location to allow for
the recovery of the systems and/or the archives if the Ignite-UX server is lost or the site is lost (the
6