Narrator: An example of disaster recovery in action is the use of system backups.

The timeline in this

image looks backward in time from the moment of incident detection (on the right) as a way of
identifying the amount of work that will be lost by reloading from a backup. Transaction processing
events (the triangles) and some backup events (shown as database symbols) have been numbered as
events 1 through 21 from left to right along the timeline. The green transactions (events 1 through 14)
are ones that were fully processed prior to the intrusion or the start of the incident. Presumably, and if
antivirus and other systems are working correctly, this may be a safe assumption. These transactions
were not exposed to possible loss of integrity, authenticity, privacy, or any other required security
attributes.

The database symbols shown in gray (events 2, 5, 9, and 13—all prior to the event) represent some form
of system and data backup that may have captured the changes to the system as a result of properly
completing the green transactions.

It is events 15 through 21, however, that are in doubt. They may be okay, or they may represent a lack
of integrity if the data was compromised. The database backup symbols in orange, between the time of
the incidence occurrence and it's being detected, are clearly in doubt as to their integrity or safety. They
may contain bogus, corrupted data or they may even contain malware in a variety of forms. Moving
backward in time from the detection of the incident, it's not until we get to that right most gray
database symbol—event 13 the backup just before the incident occurs—that we have our last clean,
trustworthy backup.

Three sets of work that were lost since the incident started to occur can be identified: all transactions or
changes prior to that last good backup that were not part of that backup—if it was an incremental or
partial backup and not a full backup—events 15, 17 through 19 and 21; all transactions and other
changes processed or attempted from that backup forward in time until after the incident was detected,
not started to occur; and all transactions changes, etc. that would normally have been processed from
the time the incident was detected until the system was fully operational again, but were not able to be
processed at all due to the disruption.