- .claude/scripts/cdp.py: drive Chrome via DevTools Protocol; screenshots to disk (so Gemini/Grok can see the live site). Fixes invisible-window + no-disk-screenshot. - reference_cdp_chrome_driver.md (+ MEMORY index) - gururmm submodule pointer -> dashboard redesign docs (local 3cef6ba) - session log Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5.7 KiB
Dataforth Migration-Gap Diff — RESUME (parked 2026-06-04)
Status: PARKED. Mike will run approach A (WizTree on all servers) tomorrow (2026-06-05).
Goal
The 2025 post-ransomware recovery restore (Restore plan ~10/1–10/2/2025, ~3.4M files) migrated each share from its old D:\<share> location to the current C:\Shares\... layout and silently dropped files (proven by the SP1366 case — see ticket #32385). Find what else was dropped, per share. Review-only catalog — NO automatic restore (some deletions were intentional; the backup is additive-only).
Backup-side data (already captured)
- HGHAUBNER (Georg's machine)
D:is a pre-attack backup of the DF shares. - Full-drive WizTree CSV exported (2.3 GB) + zip (196 MB):
AD2 C:\ClaudeTools\clients\dataforth\WizTree_20260604184904.zip(moved OFF the c-drive share — it's a sensitive file list). - Local working copy also at
GURU-5070 C:\Users\guru\AppData\Local\Temp\wiztree.zip. - Backup scale (the 7 mapped shares): ~8.7M files / ~5.7 TB — too big for live enumeration via RMM, hence WizTree both sides.
Share → live-server mapping (HGH folders are named by SHARE, not server)
| HGH backup folder | Live target | Notes |
|---|---|---|
DF C-Drive |
AD2 C:\Shares\c-drive |
SP1366 already restored |
DF E-Drive |
AD2 C:\Shares\e-drive |
2.29M files / 2.26 TB |
DF WebShare |
AD2 C:\Shares\webshare |
|
DF Sage |
SAGE-SQL C:\sage |
|
DF Server Sales |
FILES-D1 E:\Shares\sales |
|
DF Server Archive |
FILES-D1 E:\Shares\archive |
|
DF Server Engineering |
AD1 C:\Engineering |
|
DF Staff |
— SKIP | Georg's personal profile backup |
Dataforth |
— SKIP | Georg's personal work-data backup |
Also flag: the staff share is entirely absent on FILES-D1 (only archive + sales exist) — separate issue, not in scope here.
Plan (approach A — WizTree both sides)
- Push portable WizTree to the 4 live servers via RMM (AD2, FILES-D1, SAGE-SQL, AD1).
- Export each relevant volume/share to CSV:
WizTree64.exe "<path>" /export="<csv>" /admin=1. Treat CSVs as sensitive — keep them out of any share (stage to a private dir, e.g.C:\ClaudeTools\..., transfer via SFTP off AD2 like we did the backup CSV). - Diff CSV-to-CSV per share (backup relative paths − live relative paths, case-insensitive) → files present in backup, missing live.
- Write catalog →
clients/dataforth/migration-gap-catalog-2026-06-04.md(per share: whole folders missing + individual files missing).
RMM agent IDs (GuruRMM, client "Dataforth Corp")
- AD2
cfa93bb6-0cdc-4d4e-a29e-1609cda6f047(has OpenSSH too:sysadmin, vaultclients/dataforth/ad2.sops.yaml) - AD1
bf7bc5ee-4167-4a62-912a-c88b11a5943d - FILES-D1
8566a19d-49a9-4f8b-9c6c-012cc934484b - SAGE-SQL
120ba7bf-8544-48a0-98a1-40ed5cdd3e1f - HGHAUBNER
2aefe0d5-2357-4bdd-965a-abfccb4767a5(Georg logged in; user_session writes to mapped Q:/T:/V:/X: → AD2 shares)
Transfer trick (proven)
HGHAUBNER/server user_session can write to existing GPO-mapped drives (e.g. Q: → \\ad2\c-drive) but cannot open fresh UNC (WTS-impersonation has no network creds). So: copy to a mapped AD2 share → SFTP off AD2 (sysadmin) → process locally → delete the staged copy from the share.
Other Dataforth items PARKED 2026-06-04 (not started)
1. AD1 Files backup — [DONE] created 2026-06-05
Created 2026-06-05 ~18:40 UTC via GuruRMM remote command (cmd id a12d59a3-117d-497a-a080-75823b8db08d) on AD1 (agent bf7bc5ee…); cbb.exe returned "Backup plan is created." (180-day retention, fast-NTFS, compress, NBF, synthetic full, daily 2:00 AM). Initial run NOT triggered (first run at 2:00 AM, per Mike). AD1 now has image (Image2025) + file (Files), parallel to AD2. Original prep notes below for reference:
AD1's shared data folders need a Files plan matching AD2's (NBF, daily 2 AM, 180-day retention, ACG-Dataforth). Shares: Engineering→C:\Engineering, ITSvc→C:\Shares\ITSvc. AD1 currently has only the Image2025 image plan. Verified AD2 Files plan config: SerializationSupportRetentionTime=180 days, GFS off, synthetic full, compression, fast-NTFS. Run on AD1 via RMM (agent bf7bc5ee…):
cbb.exe addBackupPlan -n "Files" -a "ACG-Dataforth" -nbf -syntheticFull yes -d "C:\Engineering" -d "C:\Shares\ITSvc" -c yes -fastNtfs yes -ntfs yes -every day -at "2:00 AM" -purge "180d" -notification errorOnly -dr yes
(cbb.exe = C:\Program Files\Arizona Computer Guru\Online Backup\cbb.exe.) Optionally trigger an initial run after. Confirm with user before executing (production DC).
2. AD2 Claude capability updates
AD2 runs its own Claude from C:\ClaudeTools (a git clone of the ClaudeTools repo; has .claude/commands/ mirroring ours) + C:\dataforth-ad2-context (DOS-project workdir w/ its own CLAUDE.md). ~/.claude (sysadmin) has no commands/ and no CLAUDE.md. User wants the AD2 Claude to: (a) know how to use syncro + coord, (b) read/update the DF wiki, (c) have access to all Dataforth data in ClaudeTools. TODO: check whether C:\ClaudeTools remote == shared Gitea (so updates flow via repo + git pull) or is a diverged clone; then add the syncro/coord commands + a CLAUDE.md w/ DF context + ensure the DF wiki + clients/dataforth data are present, and that it can auth (vault/identity, coord API).
3. Dataforth wiki fleet update
GuruRMM enrollment grew 13 → 45 agents (40 online) incl. servers AD1, FILES-D1, SAGE-SQL, DF-HYPERV-B, DF-SVR-D2-Sync, eng-dev-server. Update wiki/clients/dataforth.md GuruRMM-enrollment section (currently lists only DF-GAGETRAK).
Housekeeping
- Sensitive backup-CSV copy on GURU-5070:
C:\Users\guru\AppData\Local\Temp\wiztree.zip— delete after the diff is done (or now if not needed).