Backup over a data diode

How it works

The backup server stays where it is and keeps doing its job. What changes is the destination: instead of writing to storage it can read back from, it hands the result to the middleware’s sender node. The sender terminates the protocol, sends the payload as a one-way stream across the diode, and the receiver rebuilds the files and verifies the hash before writing them to the store.

The hard part is sizing

The receiving side cannot ask the sender to slow down. Send more than the link carries and the excess is lost — and the sender does not notice. For telemetry a lost sample is noise; for backup a lost file is a broken restore that surfaces when it is needed.

Size for the peak, not the average. The largest single job, divided by the actual window in seconds, plus the middleware’s redundancy, plus margin for interleaved jobs — then compare against 1 Gbit, which is the ceiling in this catalogue. A production network with several terabytes of nightly change does not fit across a 1 Gbit link however well the flow is built. Write that into the study rather than discovering it at commissioning.

Verification without an acknowledgement

Nothing comes back, so verification has to be built as an independent flow out of the backup domain to a third place — not as a return path. Three mechanisms, in the order they should be introduced: a manifest per job listing what was sent, a heartbeat that alarms when it stops, and a periodic test restore. A pattern without the third is not verified. It is monitored.