Snapshot restore runs rm -rf * before extraction — data loss on failed restore #7

New issue

Closed

opened 2026-05-09 00:18:16 +00:00 by Mark · 2 comments

Mark commented

2026-05-09 00:18:16 +00:00

Owner

server/index.js line 391: rm -rf * inside target volume before extracting backup. If backup corrupt or extraction fails, volume data permanently lost.

Mark added the

needs-triage

label

2026-05-15 21:00:01 +00:00

Mark commented

2026-05-16 02:10:56 +00:00

Author

Owner

Ops Pipeline — Not an Ops Task

This issue was labeled ops-task but doesn't appear to be an operations task. It has been returned to feature triage for proper routing.

Research analysis:
IS_OPS: NO
HOST: localhost
STATUS: NOT_OPS
EVIDENCE: The issue describes a bug in the restore logic in server/index.js line 391 — rm -rf * runs before backup extraction, meaning a corrupt backup leads to permanent data loss. While the issue tag says "ops" and the context is backup/restore, the actual problem is a code logic bug: the application's restore routine operates destructively before validating inputs. Fixing this requires modifying application source code to defer deletion until extraction succeeds (e.g., atomically rename to a temp directory, then clean up on success). That is a code bug fix, not an operational procedure — no commands to run on a host, no config changes, no service management, no infrastructure work.

PROCEDURE: N/A — not an ops task. The fix belongs under feature triage / bug fix: modify the restore handler to move data aside rather than delete it, validate backup integrity before destructive operations, or use a staging directory.

VERIFY: N/A
RISKS: N/

## Ops Pipeline — Not an Ops Task This issue was labeled `ops-task` but doesn't appear to be an operations task. It has been returned to feature triage for proper routing. **Research analysis:** IS_OPS: NO HOST: localhost STATUS: NOT_OPS EVIDENCE: The issue describes a bug in the restore logic in `server/index.js` line 391 — `rm -rf *` runs before backup extraction, meaning a corrupt backup leads to permanent data loss. While the issue tag says "ops" and the context is backup/restore, the actual problem is a code logic bug: the application's restore routine operates destructively before validating inputs. Fixing this requires modifying application source code to defer deletion until extraction succeeds (e.g., atomically rename to a temp directory, then clean up on success). That is a code bug fix, not an operational procedure — no commands to run on a host, no config changes, no service management, no infrastructure work. PROCEDURE: N/A — not an ops task. The fix belongs under feature triage / bug fix: modify the restore handler to move data aside rather than delete it, validate backup integrity before destructive operations, or use a staging directory. VERIFY: N/A RISKS: N/

Mark added

triage-approved

quickfix

and removed

needs-triage

labels

2026-05-19 02:51:53 +00:00

Mark removed the

quickfix

label

2026-05-26 00:40:44 +00:00

Mark removed the