The system nobody wants to touch
Every business has one eventually: something built years ago, in a language or platform nobody's hired for anymore, by someone who's no longer around to explain it — and it still runs the actual business, quietly, until it doesn't. The instinct is usually "we should rewrite this properly," which is often the wrong first move. The first job is understanding what it actually does and getting it stable, before deciding whether it needs replacing at all.
What "recovery" covers
Reading and documenting old, undocumented code across whatever it was actually written in — including languages well past their prime. Extracting data out of proprietary or discontinued formats when the software that wrote them isn't installable anymore. Rebuilding just enough of the surrounding integration (the part that broke, or the part connecting it to something newer) without touching what still works. Sometimes that's the whole engagement; sometimes it's the first step before a proper rebuild.
Real experience with this, not a hypothetical
This has meant working directly with legacy Visual Basic (VB6) trading utilities, and separately, writing a pipeline to convert data out of .sas7bdat files — a proprietary SAS statistical format — into something usable, once the original software producing them wasn't part of the workflow anymore. Old and unfamiliar formats aren't a reason to say no to a project; they're a normal part of this kind of work.