liveBook · Manning

Recovery

Recovery is the process of restoring access, data, computation, or system operation to an acceptable state after failure, loss, or disruption.

How 3 Manning books explain it

Akka in Action, Second Edition

A recovery strategy is a planned response that restores operation or limits the effects of a fault or failure.

How it is used
Frames distributed-system failure handling as planned containment, continuation, replacement, reboot, or deliberate shutdown.
How deep it goes
Defines recovery strategies and compares several mechanisms, then sketches supervisor decisions without detailing implementation internals.
Examples
Uses unavailable networks and services, failed servers or disks, and an Akka application supervised across components.
What you can do after
Operate/configure supervisor responses that continue, restart, stop, isolate, replace, or reboot components after failure.

Read how Akka in Action, Second Edition explains recovery →

Elixir in Action, Third Edition

Error detection and recovery is a set of mechanisms for identifying failures and restoring affected computation or service.

How it is used
Deploys failure detection and supervised restarts to keep server-side services reliable and independently manageable.
How deep it goes
Explains supervision hierarchy, startup and shutdown, restart boundaries, escalation, and restart-frequency limits.
Examples
Uses a database-worker crash, a nested service tree, and a comparison of two web-server technology stacks.
What you can do after
Operate supervised services by reasoning about failure propagation, restarting workers, terminating child services, and escalating recovery.

Read how Elixir in Action, Third Edition explains recovery →

Think Distributed Systems

Recovery is a technique for restoring a system or transaction to an acceptable state after failure or interruption.

How it is used
Frames recovery as the transition from an illegal state to a legal state after failure or interruption.
How deep it goes
Explains restart logs, idempotent Undo, and state-dependent REDO or UNDO, while showing that coordinator failure can block progress.
Examples
Uses crash restart, Transaction Undo Logs, participant failures, coordinator failure, and state-specific recovery actions.
What you can do after
Diagnose/debug with it by tracing persistent transaction state and selecting restartable Undo, REDO, abort, or coordinator inquiry.

Read how Think Distributed Systems explains recovery →

Related concepts

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.