One of the essential resources required to recover our
IT systems today is really data,
and we have to be prepared so we are able to recover
the data if we have a major outage.
That means we have some type of data preservation plan.
We use this term the recovery point objective.
The recovery point objective means we won't lose too much data
and that recovery point objective determines,
or in many cases, influences or drives what our backup strategy should be.
Do we back up our data to the cloud so that it should be available from
an offsite location if our head office burned down?
Do we actually have some type of storage area network with say
internal hard drives or some type of removable storage that we
could put off in a secure location, say every day?
Do we mirror our data on two different, should we say,
systems, maybe even geographically dispersed locations?
Do we take all of our data,
say once an hour and write it off into an electronic vault or
maybe every 1000 transactions so it goes offsite,
and if there was a problem with the primary site,
well the most I would ever lose is that 1000 transactions that
have happened since the last time I did a vault.
When we deal with databases, whenever we make a change to a database,
we write a little journal entry that allows us to recover
the actual changes made to the database,
even if the database was corrupt or failed.
The thing is that if that journal is just kept on the same system that failed,
it's probably going to be lost as well.
So we will write that journal off to another location.
We'll take a full database backup on a regular basis,
and we can apply those journals to bring the database
right up to the time of the failure, minimizing the amount of actual data loss.
We want to build our systems to be resilient.
That means quite often fault tolerant.
We put in things like, for example,
duplication and redundancy of equipment and networks so that if one failed,
the others will still be able to keep going,
and one of the solutions to that is a cluster.
Maybe I have a number of servers working together
and all of them sharing the load.
If one goes down,
the others just keep on processing and should have a very
minimal impact on our customers and users.
We build high‑availability systems,
systems where we've built in the ability to failover
if a piece of equipment fails, for example.
We also make sure we have the appropriate levels of quality of
service which ensures that we have the bandwidth,
the storage we need for our processing to actually be then handled.
In summary, in this module,
we set out the foundation for continuity of operations.
Our goal is to ensure the organization is prepared to deal with and
manage disruption to business mission and operations.
This is so that we can sustain the critical business
operations through proper preparation and planning.