Successful System Recovery using Ignite-UX

Application backups allow you to recover application file systems and data. Typically, they are
scheduled at times when the application is down or quiescent, or in a state where a valid backup
can be executed effectively. Your application backup strategy can vary; for example you could run
daily full
2
backups, or weekly full backups and daily incremental
3
backups, or a full weekly backup
with the database down, coupled with daily multiple backups of the database log files for replay in
the event of a complete system recovery.
The following topics are discussed in this paper:
•
Documentation
•
Rapidity of change
•
Creation frequency
•
Retention
•
Budgetary and other constraints
•
Service level agreements
•
Testing recovery archives
Documentation
Analyzing the technical documentation that is created when changes occur in your environment is
very valuable in deciding how often you should create a recovery archive. Ask yourself whether
you will be able to replicate all the changes that have been applied to a system. Critically examine
the documentation that is produced with each change and decide whether the changes that were
made can be replicated from the documentation. Keep in mind that you can give rise to major
problems if you decide now that changes can be replicated, but then discover later that some
cannot because the quality of parts of the documentation is poor and therefore not repeatable.
If your change process produces high-quality technical documentation, you may be able to increase
the interval between the creation of recovery archives. You should consider, however, the
resources required to reapply changes when you recover a system. If you do not have high-quality
documentation, or if the resources required to use such documentation are prohibitive in your
environment, you must then set the period between recovery archive creation ideally to one week
or at most a few weeks to minimize the number of changes that may be lost during a recovery.
Rapidity of change
Systems that are considered to be in a maintenance mode and have very few changes
implemented may be able to span many months between generations of recovery archives.
Those systems that are more dynamic may require the creation of recovery archives in a much
shorter timeframe: days or, at most, weeks, depending on the changes that are implemented.
Most systems fit somewhere in between these two extremes with periods of large change followed
by quiet periods: for example, application, database or operating system upgrades followed by
longer periods of relative quiet during which the system only undergoes maintenance of the
application and periodic planned patching of the operating system.
2
All data associated with the application are backed up.
3
Files that have changed since the last full backup are saved into the backup. A restoration of application data involving incremental backups
would require you to recover the last full backup of the application and then the latest incremental backup. There can be varied levels of
incremental backup and the previous comments discuss only one level of incremental backup.
3