The Payment Portal With a Six-Hour SLA

Sequence:

1. Document the scene before touching anything: hostname, asset tags, drive serials, who is present, the current time source, and a photograph of the screen showing the active SSH session.
2. Capture RAM (LiME/AVML to the USB drive). The dm-crypt master key for /mnt/vault lives in kernel memory; Monday is too late, and without RAM the vault is unreadable until the app team returns.
3. Capture volatile network and process state: ss -tanp, ps auxf, lsof, /proc/*/maps, mounts, routes, ARP, and the peer address of the live SSH session.
4. Copy /var/log and the journald store to the USB drive and hash each file, so the logs survive the 06:00 reimage even if the full image slips.

Why this order: volatile data is lost on shutdown or reboot; disk content survives, although a live image will not be bit-stable.

What I would not do: pull the plug or issue an unplanned reboot. It destroys the only copy of the LUKS key material and the live session, and it guarantees the 06:00 deadline is missed with nothing preserved. If the SLA forces a rebuild, negotiate an extension or a temporary replacement host; reimaging the original is destruction of evidence and must be escalated in writing.

LUKS volume: capture the ciphertext, not the plaintext. Image the underlying block device/LV so the LUKS header and all key slots are preserved, then decrypt a working copy on lab hardware once the passphrase is obtained. Never mount and image the decrypted mapping as the primary artefact - you lose the header, and every mount touches the source. Note the header offset and back up the first few MiB of the volume separately.

RAID-1: the two members are mirrors, so imaging one member yields the full data set. Check controller status first: if the array is degraded or a member was recently replaced, image both and document which was which. Record the controller model, firmware, and array configuration, since SAS metadata can live on the member.

The write-blocker gap: your hardware blocker is SATA-only and the drives are SAS. Options are to borrow a SAS-capable blocker, or to boot a forensic Linux distribution, ensure the device is not mounted, and use a software blocker (blockdev --setro, or an imager that opens O_RDONLY). Software blocking is weaker: you must document the deviation, hash the device before and after, and show no mount occurred. Also capture HPA/DCO status if the controller exposes it. Every deviation belongs in the notes with its potential effect on the evidence.

Integrity: image with a format that hashes blocks as it writes (E01 or AFF4). Compute SHA-256 of the image file and of the raw device stream, then re-read the image from the media and re-hash, so a silent write error on the USB drive is caught. Record both values plus the tool and version.

One honest caveat: hashing a live device is not reproducible - the source will not hash the same tomorrow. Say so in the report and rely on the image hash for integrity of the copy, treating the acquisition as documented-but-live rather than forensically sound.

Redundancy: one copy is a single point of failure and USB drives fail. If a second drive cannot be obtained, prioritise: the LUKS volume and the RAID member (the irreplaceable data), then /var/log, then the remainder. Document what was not captured and why.

Record: exhibit number, device serials, the drive the image was written to, hash values, start and end times with the time source, who was present, who handled the media at each transfer, and every deviation from SOP with its assessed impact. Chain-of-custody entries should be signed and contemporaneous, not reconstructed afterwards.

Frame it as a business risk, not a process preference.

• If the disk is imaged and the host is rebuilt, you lose RAM, which contains the only accessible copy of the vault key. The vault then stays sealed until Monday, which may extend the outage rather than shorten it.
• The rebuild also destroys the original media. If a regulator, insurer, or counterparty later asks whether the host was preserved, 'we reimaged it to hit an SLA' is a defensible answer only if it is documented and authorised by someone senior, in writing, before the fact.
• Offer a compromise: capture RAM and volatile state (roughly 30–60 minutes for 64 GB to USB 3.0, faster to internal or network storage), snapshot the logs, then let the rebuild proceed while the disk image is made from the removed drives off-host. The service comes back on new hardware and the evidence survives.
• Escalate the decision to the incident owner and legal, record who authorised what and when. Your job is to make the trade-off visible and documented, not to unilaterally block the recovery.