Although there are many technical and procedural safeguards in place to protect against the loss of data, there remains the remote possibility of a situation developing that results in the loss of previously captured or committed data.
Complete data loss is unlikely, as long as regular copies are made and stored safely away from the production (or main) system. In addition, a stand‑by system might be employed using SDS, which enables a much faster recovery in the event of a disaster. However, a hardware, low‑level software, or firmware fault, or a combination of these faults might provide a circumstance in which a system needs to be recovered from a previous backup, and for some reason cannot be rolled forward to the last point of user data input. This would result in a period of recently applied transactions being lost.
For any IT system, you need to consider the consequences of data loss prior to the event occurring, in order to decide whether proactive strategies to mitigate the impact are warranted. Valid strategies might involve both technical and procedural or business‑related actions.
Importantly, you need to consider the impact of data loss not just in terms of the specific application in which the data loss has occurred but also the effect on any other applications that interface with it. This can be a complicated situation that developers need to consider at the design stage of any systems that receive or send updating transactions with other systems.
There is no single solution available, but it must be given careful thought in the design of each interface from each system’s perspective.
A basic design consideration in cases where separate systems update each other is to ensure that the interface has a form of sequence checking that can detect whether one of the systems has lost data; that is, has gone backwards in time. For example, if application A sends transactions to update application B, the interface at both ends might keep an incrementing sequence reference of the last processed transaction, which is compared before processing any new transaction. In the event that the sequence records are not synchronized, processing could be halted and action taken to address the problem.
You should consider design functionality to assist in the recovery in such a situation. For example, if application B has lost data, application A might be designed to retain the source of the transactions previously sent to application B in such a way that it has the ability to safely re‑send previously sent transactions, if required.
Your system must have the ability to deal with a situation in which application A has lost data and therefore application B contains transactions as a result of data that longer resides in application A. The solution will be unique for each situation, depending on the type and inter‑relationships of the data concerned.