Let me carefully analyze this query. The user says "Same, plus: one log is unlinked-but-open (63 GiB) and backup was taken without consistency guarantees. Does this change the verdict? Which recovery options are now dead?" This is a follow-up question ("Same, plus...") referencing a previous conversation that I don't have access to. The human's message implies there was prior context — likely a scenario about a database server or filesystem with data loss, where I previously gave some "verdict" about recoverability. Now they're adding new facts: 1. One log is "unlinked-but-open" (63 GiB) — this is a classic Unix/Linux scenario: a file has been deleted (unlinked from the directory) but a process still holds an open file descriptor to it. The data still exists on disk, accessible via /proc//fd/, and the space isn't reclaimed until the last fd closes. 63 GiB of log data still recoverable via copying from the fd. 2. "Backup was taken without consistency guarantees" — meaning the backup is a "fuzzy"/inconsistent backup (e.g., a plain file copy of database files without snapshot, without FLUSH TABLES WITH READ LOCK, without LVM snapshot, without pg_start_backup, etc.). For a database, an inconsistent backup alone is often NOT restorable directly — it typically requires archived WAL/binlogs/redo logs to roll forward to a consistent point (crash recovery or point-in-time recovery). If the only log that could provide the roll-forward is the unlinked-but-open one... The question: "Does this change the verdict? Which recovery options are now dead?" Since I don't have the prior context, I need to reason about what the likely scenario is. This strongly resembles a database recovery scenario — perhaps PostgreSQL (WAL), MySQL (binlog), MongoDB (journal/oplog), or Elasticsearch. The mention of "one log" suggests maybe multiple log files were deleted, one of which survives as unlinked-but-open. Actually, a very common scenario: someone ran out of disk space, deleted old WAL/binlog files to free space, or deleted files in a data directory. Previous verdict might have been "restorable from backup + archived logs" or "PITR possible." Now: - The unlinked-but-open log (63 GiB) means that log's contents are still recoverable — actually this is GOOD news for recovery, as long as the holding process doesn't die/close the fd before you copy it. But it's also a live risk: if the process exits or the machine reboots, that data is gone permanently. So the verdict might change from "log is gone" to "log is recoverable if you act now, but the clock is ticking." Wait — "Does this change the verdict?" implies the previous verdict may have assumed the log was simply deleted (gone). Now we learn one log is unlinked-but-open — recoverable. And the backup is inconsistent — which changes the backup's status from "restorable" to "only usable with logs." So the interplay: - Inconsistent backup alone: NOT directly restorable for most databases. Options that relied on "just restore the backup" are dead. - Inconsistent backup + continuous log archive from backup start to a consistent point: viable (roll-forward). The unlinked-but-open log might be the critical piece covering the gap since the backup. - If the unlinked-but-open log is the ONLY copy of the log stream covering the period after the backup, then the recovery path is: (1) immediately copy the fd contents out (via /proc/pid/fd, cp, or dd), (2) stop/kill nothing until copied, (3) restore fuzzy backup, (4) replay logs to reach consistency. Which recovery options are now dead? - Restore-from-backup-as-is (backup-only restore): dead, because the backup lacks consistency guarantees. Unless the DB can do crash recovery on it (e.g., if the "backup" is a filesystem copy that looks like a crashed state, InnoDB/WAL crash recovery might work IF the copy captured a coherent-enough state — but copying a live DB's files without snapshot gives files from different points in time; InnoDB redo might not even cover it; PostgreSQL will refuse or corrupt). So "backup-only" restore is dead or at least not trustworthy. - Any option that required the deleted logs other than the unlinked-but-open one: if other logs were deleted and fully closed (no fd), they're gone unless carved from free space (photorec-style) or recovered from replicas/standbys. So options assuming complete log availability are dead except through the open fd. - Replica/streaming-based recovery? Not necessarily dead — but if the replica was also affected... unknown. - PITR to arbitrary points: dead beyond what the surviving log chain covers. You can only roll forward through the logs you have. If there's a gap, PITR past the gap is dead; you can only recover up to the start of the gap (or to the end of available logs if continuous). Also, the unlinked-but-open log has unique urgency and hazards: - The data exists only as long as the fd remains open and the process lives. Kill/restart the process, reboot, OOM-kill, crash → data gone, blocks freed. - Copying 63 GiB takes time; during that time the process keeps appending (the fd offset grows). Copy via /proc//fd/ — better to open a new fd to the same file (via the /proc link) and copy from offset 0, or use `cp /proc/PID/fd/N dest`. Note: reading through the /proc fd symlink gives you a new file handle at offset 0, independent of the writer's offset, so you can copy the whole file. But the file keeps growing during the copy; to capture a consistent tail, copy, note the size, then copy the delta, or freeze the writer (SIGSTOP) briefly, or copy and then re-copy the appended part. - lsof +L1 or `find /proc/*/fd -lname '*deleted*'` to locate it. - Do NOT restart the service "to be safe" — that kills the fd. - Also caution: some tools/ops like logrotate, or the process itself closing the handle when done. - Also, 63 GiB needs 63 GiB of free space somewhere to copy to; and the blocks aren't freed until close, so disk space pressure: the space is still "used," so you need additional space. If disk is full-ish, copying within same fs adds 63 GiB usage; consider copying to another mount/host (nc, ssh, rsync from /proc path). Consistency angle: Even if you recover the log, was the log itself being written when unlinked? An open fd means the writer is alive and writing — the tail of the log may be partial (last record torn). Roll-forward will stop at the last complete record; that's your effective recovery point. Recovery target time = last valid record in the copied log. The verdict question: I should acknowledge I don't have the prior thread's full context, but treat the question on its merits. Actually — as an assistant in a continuing conversation, the platform would normally include the prior turns. Here it doesn't (the conversation begins with "Same, plus..."). The honest approach: note briefly that I'm reasoning from the facts given, then answer substantively. I shouldn't pretend to remember a specific prior verdict I never gave, but I can reconstruct the likely shape: previous scenario presumably: data directory loss / log deletion, verdict maybe "recoverable via backup + logs" or "logs gone, so X." Rather than fabricate, I can frame: "Relative to the earlier assessment, here's what flips and what doesn't." Hmm, but the user expects continuity. Best practice: answer the substance, and where the prior verdict matters, phrase conditionally ("If the earlier verdict was 'recoverable via PITR,' that now hinges on..."). A short caveat like "Working from the facts as stated" is fine. Don't over-hedge. Let me now construct the substantive answer. Scenario reconstruction (most likely): A database (or similar) suffered deletion of its log(s) (WAL/binlog/journal), possibly the data too, and there's a backup. The prior verdict probably was something like "full recovery possible if logs are intact / restore backup and replay logs." New facts: 1. Exactly one log survives, and only as an unlinked-but-open file held by a running process — 63 GiB, still being written (or at least held). 2. The backup is inconsistent (fuzzy) — taken live without snapshot/lock/backup mode. What changes: A. The backup is no longer a standalone recovery path. A fuzzy backup without the log stream covering the copy window through a consistent endpoint is not restorable as-is (for Postgres: needs WAL from backup start to end plus replay to a consistent point; for MySQL/InnoDB: a raw copy needs redo to be coherent; etc.). So "restore backup only" is dead — or at best gives you a corrupt/refusing-to-start instance. B. The unlinked-but-open log flips from "gone" to "recoverable but perishable." It's now the single most critical asset: likely the only continuous log covering the post-backup window. Everything now funnels through: preserve that fd, copy it out immediately, then roll forward. C. The margin for error collapses: previously maybe two independent paths (backup, logs); now there's a single chain: fuzzy backup + this one log (plus whatever older archived logs exist). Any gap in the log chain = recovery only up to the gap. Which options are dead: 1. Backup-only restore (restore-and-start): dead. Inconsistent files; engine will either refuse (PG: "invalid checkpoint"/corrupted pages across copy boundary) or produce silent corruption. Not a viable path to a trustworthy database. 2. Any recovery requiring other deleted logs that were fully closed (unlinked with no open fd): those blocks are free-space now; options counting on them are dead barring low-level carving (unreliable for large busy filesystems, and for DB logs often useless due to fragmentation/overwrite). If there were multiple deleted logs and only this one is open, the others' absence defines the gap. 3. Clean PITR to "any time before the incident": dead. You can only roll forward through a continuous log chain. If the surviving log starts after the backup's earliest needed point, or if there are gaps, then PITR is bounded: from the backup's restorable starting LSN to the last complete record in the recovered log — and only if continuity holds. 4. "Restart the service to clear things / let it recreate logs" — dead as an option (it was never a recovery option, but it's now actively fatal: closing the fd frees the 63 GiB). Also: don't reboot, don't let OOM killer hit the process, don't let logrotate/systemd restart it. Any plan that includes a restart before securing the fd is dead on arrival. 5. Crash-recovery-as-consistency: i.e., treating the fuzzy backup as "like a crash" — mostly dead, because crash recovery assumes the data files are from one moment in time (or at least that redo covers all written pages). A minutes-long copy means pages from different times; redo in the copied files may not span the whole copy window. Unless the copy was fast relative to redo retention, this path is unsound. Some engines with full-page-write-style mechanisms can still choke (PG needs backup mode for exactly this reason: full_page_writes + backup_label; without it, torn pages during copy → unrecoverable blocks, though if full_page_writes=on and you have WAL from before the copy started, PG can often still replay because each page's first modification after a checkpoint is full-page logged... wait, subtlety: without backup mode, PG doesn't know it's restoring a fuzzy backup, but if you manually supply WAL from before copy start and the cluster had full_page_writes on, replay can repair torn pages. It's unsupported-ish but often works; pg_backup_start/stop exists to guarantee WAL range and checkpoint. So "dead" should be qualified: with sufficient WAL coverage from before the copy began and full_page_writes=on, PG roll-forward from a fuzzy copy often succeeds. Without WAL covering the copy window, truly dead.) Similarly MySQL: an rsync-of-datadir backup of InnoDB: if redo logs were copied last/continuously, crash recovery may make it consistent-ish, but pages copied at different times with redo that doesn't reach back far enough → corruption. Officially dead without proper tooling (xtrabackup exists precisely for this). 6. If prior options included "failover to replica / rebuild from standby": not killed by these facts per se — but the user asks which are now dead; the unlinked log + bad backup don't kill replica-based recovery unless the replica is the thing that died. I shouldn't assume. I can note that replica-based paths are unaffected if a replica exists. Now, what becomes THE plan (the live path): 1. Freeze the situation: do not restart/stop anything; identify holder: `lsof +L1`, `ls -l /proc/*/fd | grep deleted`, find pid/fd. 2. Protect the process from OOM (echo -1000 > /proc/PID/oom_score_adj — actually oom_score_adj min is -1000; -1000 makes it never killed... setting to -1000 disables OOM killing for it), prevent deploys/restarts, disable logrotate/cron/systemd auto-restart timers temporarily, ensure no reboots/patches. 3. Copy out: `cp /proc/PID/FD /safe/location/log` (cp opens the symlink target fresh, reads from offset 0 — captures everything present; the writer's offset is unaffected). Better: since file is growing, either SIGSTOP the writer during copy (risky if it serves traffic) or copy, then append-copy the grown tail (use dd with skip to grab delta, or rsync? rsync on /proc fd path — rsync won't handle the pseudo-file well maybe; actually cp works; for the tail, `dd if=/proc/PID/FD bs=1M skip=N of=tail` where N is blocks already copied). Or simplest: pause writer briefly (SIGSTOP), copy full file, SIGCONT. 63 GiB copy at, say, 200–500 MB/s ≈ 2–5 min; network copy slower. 4. Space: ensure destination has ≥63 GiB + growth; copying on same fs doubles usage; the unlinked blocks still count as used until fd closes, so you may need another mount. 5. Verify the copy: size matches `stat` on the fd link (Link count 0, size growing), checksum, and parse the tail to find last complete record (pg_waldump / mysqlbinlog / equivalent) → that's your recovery horizon. 6. Then: restore fuzzy backup, apply archived logs + this recovered log, replay to last valid record; run consistency checks (amcheck, innodb checksum validation, pg_dump smoke, etc.) before declaring victory. 7. Only after the copy is verified (and ideally after a second copy elsewhere) may you consider letting the process close the fd — but honestly keep it open until recovery completes; the fd is also your evidence of continuity. Also note: the fact that the log is still open means the DB process may still be writing to it — wait, if the DB is still running and writing its log to an unlinked file, then the database itself may be alive?! Interesting sub-case: admin deleted "old" logs but one was actually the live log; the DB keeps running on the unlinked fd. Then the *live database* is the primary source of truth and the correct move is: secure the fd copy immediately, then take a *proper* consistent backup NOW (pg_basebackup / xtrabackup / snapshot) from the still-running instance, which sidesteps the fuzzy backup entirely. That changes the verdict a lot: recovery may not even be needed yet — prevention is. But if data files were also deleted... the running DB with deleted data files is a zombie; dump everything via SQL while it lives, plus copy fds. I don't know the prior scenario, so I should present the decision logic compactly: the verdict now hinges on (a) log continuity from the backup window to the recovered log's tail, and (b) keeping that fd alive. Also quantify urgency: 63 GiB is big; copying takes minutes-to-tens-of-minutes; every minute the risk of a restart/OOM/crash persists; also the file keeps growing, so start now, and consider that growth might fill the disk (the unlinked file's blocks aren't freed — disk full risk continues). Edge: "unlinked-but-open" detection reliability: confirm it's really the right log generation/segment, not an old rotated one. 63 GiB single log suggests binlog with huge retention or WAL with removed segments? A single 63 GiB "log" could be a MySQL binlog file, MongoDB journal, Kafka segment?, Elasticsearch translog, or an application log. If it's an *application* log rather than the DB write-ahead log, then it has zero recovery value for the database and the verdict doesn't improve at all — the unlinked log is a red herring except for disk-space accounting (it explains why space isn't freed). I should raise that: value depends on whether it's the transactional log or just an app log. Hmm, the user said "one log is unlinked-but-open" — in context of recovery, presumably the WAL/binlog. But a good engineer verifies: is this the log the recovery chain needs, and does its LSN range connect to the backup? Also "backup without consistency guarantees": could also mean a storage-level snapshot without crash-consistency, or mysqldump without --single-transaction (inconsistent logical dump), or pg_dump of a live DB (actually pg_dump is consistent via MVCC snapshot — pg_dump IS consistent; mysqldump without single-transaction is not). If it's a logical dump without consistency, then restore gives you a database with cross-table inconsistencies (FK violations, money moved between accounts mid-dump). Logs can't fix a logical dump easily (replay against dumped state is possible with binlog position... mysqldump without master-data doesn't give a binlog position, so no roll-forward anchor → roll-forward option is dead too; you'd only have the fuzzy state + whatever the log can be aligned to... without an LSN/position anchor, you can't attach the log chain at all → then the only honest recovery is the inconsistent dump with data reconciliation). So the death list depends on the backup type; I should ask/branch briefly: file-level fuzzy copy vs. non-atomic logical dump. Given the missing prior context, my answer should: - State how the two new facts move the verdict (conditional framing, one line acknowledging). - Dead options list — crisp. - The one remaining viable path + immediate actions (preserve the fd) — with concrete commands. - The key unknowns that determine the final verdict: which log it is, whether its range overlaps the backup window, whether there are gaps, whether an older archive exists, whether a replica exists. Format considerations: This is a technical incident-response question from someone clearly expert (uses "unlinked-but-open", "consistency guarantees", asks "which options are dead"). They want density, precision, no fluff. Use short headers or bold labels, bullets, concrete commands. Medium length — not a sprawling essay. Maybe 400-600 words. Include the urgent action first (time-critical: preserve the fd before anything else — arguably lead with that because it's perishable). The user asked two specific questions: does the verdict change, which options are dead. Answer both directly, then the action items. Let me draft. Verdict change: Yes, materially. Two facts pull in opposite directions: - Fuzzy backup kills the "restore backup and done" path and makes the log chain mandatory, not optional. - The unlinked-but-open log resurrects a log presumed lost — but only as a perishable, single-copy artifact. So overall: recovery narrows from "several routes" to exactly one route: fuzzy backup + continuous log chain ending at the last complete record in that 63 GiB fd — and that route has a fuse on it. Dead options: 1. Backup-only restore. An inconsistent copy won't start cleanly / will be silently corrupt. Dead as a standalone path; it only has value as the base image for roll-forward. (Nuance: engines can sometimes crash-recover a fast rsync if redo/WAL copied covers the copy window — that's a maybe, not a plan.) 2. PITR to arbitrary timestamps. You're bounded by log continuity. Any target (a) before the surviving log's start (if other segments were deleted closed) or (b) after the last complete record in the recovered copy is unreachable. If there are gaps between archived logs and this segment, everything past the gap is dead. 3. Anything requiring the other deleted logs (closed before unlink): they're free blocks now. Carving 63 GiB-class DB logs out of a live filesystem's free space is not a recovery plan; call it dead. 4. Any plan containing a restart, reboot, logrotate, deploy, or "let the service recreate its logs" before the fd is secured — not just dead, it's the single most likely way to convert this into total loss. Also guard against OOM killer. 5. Treating the backup as crash-consistent ("it looks like a power-cut state") — mostly dead: copy skew means pages/LSNs from different wall-clock moments; without log coverage spanning the entire copy window plus replay, you can't reason about it. If the backup is a non-atomic logical dump (mysqldump without --single-transaction/--master-data etc.): even worse — no LSN anchor, so attaching any log chain to it is impossible; roll-forward from it is dead; you'd be reconciling data by hand. The live path (do in order): 1. Find and pin the fd: `lsof +L1` or `ls -l /proc/*/fd 2>/dev/null | grep -i delet`; note PID/FD. `echo -1000 > /proc/PID/oom_score_adj`. Freeze systemd/logrotate/cron/deploys. No reboots. 2. Copy it out now: `cp /proc/PID/FD /mnt/safe/log` — reading via the proc symlink starts at offset 0 and doesn't disturb the writer's offset. File is still growing; either SIGSTOP the writer for the copy (minutes) or copy then re-copy the delta (`dd` from the prior end offset). Destination needs ≥63 GiB + growth, on different storage if possible; the unlinked blocks aren't freed until close, so same-fs copy needs real headroom. 3. Verify: sizes match `stat -Lc%s /proc/PID/FD`, checksum, and parse the tail (pg_waldump/mysqlbinlog/your tool) to find the last complete record — that is your recovery horizon, and it's behind "now." 4. Then restore the fuzzy backup, replay archived logs + this segment, stop at last valid record; run integrity checks before trusting it. 5. Don't let the fd close until the copy is verified and, ideally, a proper consistent backup of the recovered state exists. What decides the final verdict — three checks: - Is this log the transaction log the engine needs, or an app log? (If app log: no recovery value; verdict unchanged/worse — but do keep the fd for disk accounting: it also tells you why space isn't freed.) - Does its starting LSN/position connect, with archived logs, back across the fuzzy backup's copy window? Continuity = recovery to the log's tail. Gap = recovery only to the gap. - Is the DB process itself the holder and still running? If the instance is alive on deleted files, the fastest "recovery" is a proper consistent backup taken right now (pg_basebackup/xtrabackup/snapshot) from the live instance — which makes the fuzzy backup irrelevant. Answer to "does this change the verdict": yes — recovery is still possible but is now single-threaded and time-boxed; the probability rests entirely on preserving one fd and on log continuity across the backup window. Length check: aim for tight. Use headers/bold. I think the above is good. Trim fluff. Also acknowledge continuity gap briefly at top in one clause — like "Taking the new facts on their own terms" — maybe just answer directly; a single short framing sentence suffices. Since the user assumes context, I'll write as if continuing, but where the prior verdict matters I'll say "if the earlier call was 'backup + logs gets you home,' it now reads 'one fd gets you home.'" That handles it gracefully without pretending specifics. One more technical check on cp from /proc/pid/fd: opening /proc/PID/FD/N opens the same file (for regular files, it's like opening by path; you get a new struct file with offset 0). Yes, `cp /proc/pid/fd/N out` copies current contents from the start while writer continues appending; cp will read until EOF as observed — it may keep reading as the file grows (cp reads until read() returns 0; on a growing file, read at end returns 0 at that moment, so cp terminates with whatever existed up to when it hit the then-EOF — it can actually race and capture a bit more; generally you get up-to-EOF-at-time-of-read). So a delta pass is wise. dd approach: `dd if=/proc/PID/FD of=tail bs=1M iflag=skip_bytes skip=$SIZE` — skip_bytes with count none. Or simpler: SIGSTOP writer, cp, SIGCONT. SIGSTOP on a DB writer: connections pile up but no data loss; for 2–10 min might be unacceptable in prod — mention trade-off briefly. oom_score_adj: valid range -1000..1000; -1000 = never kill. Good. Also mention: after copy, keep process running until recovery validated — don't "clean up." Also the disk-full risk: writer appending to an unlinked file on a full filesystem — blocks can't be freed by deleting anything else? No—other files can be freed, but this file's blocks stay. Growth can fill the disk and then the writer errors/stalls. Worth one line. Also: `stat` on /proc/PID/FD/N: use `stat -L` to follow to the file; the symlink target shows "(deleted)". Also tail-parse tools by engine: pg_waldump, mysqlbinlog --verify-checksum..., mongo? Keep generic with two examples. Dead options — should I also list "transactional consistency of the restored state at the exact incident time"? The last record may be torn; recovery to last complete record, so "recover to the final committed transaction" is only guaranteed if the log tail is intact; writes in the page cache... The log on disk via fd is what the writer flushed; fsync state unknown for the not-yet-flushed tail? The writer has written() those bytes to the page cache; reading via fd gets page-cache contents, so you get everything written() even if not fsynced — good, the copy includes dirty pages. The torn-record risk is about partial records at the write boundary, minimal. So recovery point = last complete record as of copy time (and you can re-copy delta just before cutover). Nice point: because reads hit page cache, the copy includes data never fsynced — you actually get more than a crash would have preserved. Structure: - Lead: yes, verdict changes — now single-path, time-critical. One-line framing. - "Now dead" list (numbered, bolded lead-ins). - "The one surviving path" with immediate steps (this addresses urgency; arguably should come first — user asked verdict + dead options, but incident-wise fd preservation is burning. I'll put a one-line urgent callout at the very top, then dead options, then the path.) - "What decides it" short checklist. Keep it expert-to-expert. I'll write it now, moderately compact. **Yes — the verdict changes, and the clock is now the dominant factor.** Before anything else: that open fd is a single-copy, perishable artifact. One restart, reboot, OOM-kill, logrotate, or deploy and 63 GiB of log evaporates. Secure it first, deliberate after. ## What the two new facts do - **Fuzzy backup:** demotes the backup from "recovery path" to "base image." It's only useful as a foundation for log replay — it can't stand alone. - **Unlinked-but-open log:** resurrects a log that was presumed gone, but only as long as the holding process lives and keeps the fd. Recovery narrows from "several routes" to exactly one chain: fuzzy backup + continuous logs ending at the last complete record in that fd. ## Options that are now dead 1. **Backup-only restore.** An inconsistent copy won't start cleanly or, worse, will start silently corrupt. Dead as a standalone path. 2. **Arbitrary-point PITR.** You're now bounded by log continuity. Anything before the surviving log's start position, anything across a gap in the chain, and anything after the last complete record in the recovered copy is unreachable. 3. **Anything depending on the other deleted logs.** Closed-before-unlink means their blocks are free space on a live filesystem. Carving multi-GiB database logs out of free space is forensic theater, not a recovery plan. 4. **Treating the fuzzy backup as crash-consistent** ("it's like a power cut"). Copy skew means pages/LSNs from different wall-clock moments; without log coverage spanning the entire copy window plus replay, that reasoning is unsound. (Partial exception: if WAL/redo from *before* the copy started survives and the engine full-page-writes, replay often repairs it — but that's exactly the chain above, not a separate option.) 5. **Any plan containing a service restart "to clean things up"** before the fd is copied. Not just dead — it's the most likely way to convert this into total loss. If the backup is a *non-atomic logical dump* (e.g., `mysqldump` without `--single-transaction`/`--master-data`), it's worse: no LSN/position anchor means the log chain can't attach to it at all. Roll-forward from it is dead outright; you'd be reconciling data by hand. ## The one surviving path ```bash # 1. Find the holder and pin it lsof +L1 # or: ls -l /proc/*/fd | grep deleted echo -1000 > /proc//oom_score_adj # OOM-killer immunity # 2. Copy out via the proc symlink — reads from offset 0, # doesn't disturb the writer's offset cp /proc//fd/ /mnt/safe/recovered.log ``` - The file is still growing. Either SIGSTOP the writer for the duration of the copy (2–10 min at typical disk speeds — weigh against prod impact) or copy, note the size, then grab the delta with `dd ... iflag=skip_bytes skip=`. - Destination needs ≥63 GiB *plus* growth headroom — the unlinked blocks aren't freed until close, so a same-filesystem copy needs real space. Different mount or host strongly preferred. - Bonus: reading through the fd hits page cache, so you capture even writes the process never fsynced — you may recover *more* than a clean crash would have preserved. - Freeze logrotate, cron, systemd timers, deploys. Watch disk fill: the writer appending to an unlinked file on a near-full filesystem can stall or error. Then: verify the copy (`stat -Lc%s /proc//fd/` vs. copy size, checksum), parse the tail (`pg_waldump`, `mysqlbinlog`, or equivalent) to find the last complete record — **that's your recovery horizon, and it's behind wall-clock now** — restore the fuzzy backup, replay archives + this segment to that point, and run integrity checks before trusting anything. Do not let the fd close until the copy is verified and the recovered state is itself properly backed up. ## What actually decides the final verdict 1. **Is this log the transaction log, or an application log?** If it's an app log, it has zero recovery value — it only explains where your disk space went. 2. **Does its starting position, chained through any archived logs, reach back across the backup's copy window?** Continuity = recover to the log's tail. Any gap = recover only to the gap. 3. **Is the holder the database itself, still running on deleted files?** If so, skip the fuzzy backup entirely: take a *proper* consistent backup (`pg_basebackup`, xtrabackup, storage snapshot) from the live instance right now. That's the best outcome available and it expires without notice. Net: if the earlier read was "backup + logs gets you home," it now reads "one fd gets you home, if its chain is unbroken."

SCB SCB-forensics-T2 MK3