Two questions to ask a backup
Did the backup run? And where is it written that it had to run, how long copies are kept and whether anyone can still alter them? Those are two questions for two audiences. What the Cohesity connector therefore writes to two separate places, and where it deliberately writes nothing at all.
In an audit, hardly anyone asks whether the backup ran yesterday. The question is where it is laid down that it has to run, how long the copies are kept and whether they can still be altered during that time. Those are two different questions. The first is operations, the second is evidence. A backup system can answer both, but the answers belong in different places.
That is exactly how the Cohesity connector is built. In the code the two paths are called level A and level B, and the distinction is not cosmetic.
Level A: what was actually backed up
The protected objects from the cluster arrive as backup status on the IT systems that already exist in the inventory: the object identifier, the time of the last backup, the outcome. That puts the last backup time on the system itself, rather than only in a console beside it.
Level B: what is supposed to be backed up
Every protection policy becomes a backup plan in business continuity management, with frequency and retention period. If a DataLock is set in the cluster, it comes along as a WORM marker. That is the entry people look for first in ransomware discussions: whether the copies can be overwritten at all during the retention period.
One small detail here decides whether the figure is worth anything later. The imported retention period carries its origin in the text: "90 days (from Cohesity protection policy)". Anyone asking in two years where the value came from can see it on the value itself, instead of reconstructing it.
What the connector does not do is more interesting
Three boundaries are drawn explicitly, and they say more about the design than any feature list.
Manually maintained backup plans are never touched. The reconciliation only ever operates on entries marked as originating from Cohesity. Whoever wrote a plan themselves keeps it, even if something similar exists in the cluster. A synchronisation that overwrites other people's manual work gets used exactly once.
The connector creates no new IT systems. Protected objects are mostly virtual machines and databases, and those would flood the inventory with pure backup objects. If no matching system is found, the entry is skipped. Creating records stays with the inventory scan that exists for the purpose.
And if business continuity management is not installed at all, the connector skips the plan part instead of aborting the whole reconciliation. The operational part keeps running. A missing stage of expansion is not an error.
Results are not rewritten
The individual backup runs arrive with start, end, status and the volumes read and written. A run already known is not created again, because a completed run is an immutable result. What happened once stays as it happened. For a chain of evidence, that is half the battle.
More on the Cohesity connector page. Where the backup plans end up is shown by business continuity management.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.