# 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)
1. Push portable WizTree to the 4 live servers via RMM (AD2, FILES-D1, SAGE-SQL, AD1).
2. 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).
3. Diff CSV-to-CSV per share (backup relative paths − live relative paths, case-insensitive) → files present in backup, missing live.
4. 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`, vault `clients/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).
