azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from GURU-5070 at 2026-06-04 19:27:51

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-04 19:27:51
This commit is contained in:
Mike Swanson
2026-06-04 19:27:56 -07:00
parent e08488ae5e
commit 8389e64a02
3 changed files with 201 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
clients/dataforth/migration-gap-diff-RESUME.md Normal file
View File

@@ -0,0 +1,63 @@
# 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 — command READY, awaiting "run AD1"
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).

86
clients/dataforth/session-logs/2026-06-04-session.md Normal file
View File

@@ -0,0 +1,86 @@
# Dataforth — Session Log 2026-06-04
## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin
## Session Summary
Recovered missing PCB manufacturing print files for the SP1366 MAQ20 Communications Module (revisions E, F, G, H), reported missing by John Lehman. The files live on AD2 (`Q:` → `\\ad2\c-drive` → `C:\Shares\c-drive`) under `DOCUMENT\DESIGN\SP\SP1366 MAQ20 Communications Module\{E,F,G,H}\PCB1366 REV <rev> PRINTOUTS FOR MANUFACTURING`. The PRINTOUTS folders existed but contained only a `TOP SIDE DRILL PANEL.PDF` each; the LAYERS/PASTE/AD/CD/DG exports were gone. The same set existed for revs A (2010) and I (2024), and the Altium source `.SchDoc` files for E–H survived — only the exported PDFs were missing.
Confirmed no local recovery path: AD2 had no shadow copies; its MSP360 (ACG-branded "Online Backup") agent showed an image plan and a Files plan both "Never started" locally, but the MSP360 account view (api.mspbackups.com) showed the AD2 Image plan running daily. The breakthrough was a second backup set in the `ACG-Dataforth` storage: a file-level NBF backup ("Backup plan on 8/29/2025", bunch `faad5a67`) with restore points 8/29–9/29/2025. Browsing it (`cbb.exe list -b <bunch> -rp <id> -path ...`) found the files under `D:\c-drive\...` (the share's pre-migration physical path) — 19 of John's 20 files present (REV F's `TOP PASTE LAYER` absent in every backup; it never existed as a separate F export).
Established WHEN the files were lost via NTFS timestamps: the `C:\Shares\c-drive` tree was created 10/1–10/2/2025 by the post-ransomware recovery restore (`Restore plan 10/1/2025`, ~3.4M files). That restore brought back only the drill panel into each PRINTOUTS folder and dropped the rest — i.e. an incomplete recovery restore, not a later user deletion. Files were intact in backup through 9/29/2025. The image backup retention only reaches back to 5/6/2026 (post-loss), so it cannot contain them.
Restored the 19 files from HGHAUBNER's pre-attack backup (`D:\DF C-Drive`, accessible after Mike installed GuruRMM on HGHAUBNER) rather than the cloud backup — same files, no B2 egress. Cross-machine copy was blocked by Windows auth (SSH double-hop; WTS-impersonation tokens can't open fresh UNC). Solution: ran the copy on HGHAUBNER in `user_session` (as logged-in `ghaubner`), reading local `D:\DF C-Drive` and writing to his existing GPO-mapped `Q:` (→ `\\ad2\c-drive`) — local read + existing-mapping write needs no fresh auth. Verified 6 files/rev landed in the live `C:\Shares\c-drive` path. Created Syncro ticket #32385, billed 1.0 hr remote labor (prepaid → $0, block 35.5→34.5), resolved + invoiced.
Set up follow-on work and parked it: rescanned the GuruRMM fleet (grew 13 → 45 agents incl. servers AD1/FILES-D1/SAGE-SQL); prepared (but did not run) an AD1 Files backup plan matching AD2's (180-day retention); and scoped a broader migration-gap audit (WizTree both sides, ~8.7M files / 5.7 TB across 7 shares). Mike will run the WizTree-on-servers pass tomorrow. All parked state is in `clients/dataforth/migration-gap-diff-RESUME.md`.
## Key Decisions
- Restored from HGHAUBNER's local pre-attack backup rather than the MSP360 cloud backup — identical files, no B2 egress, and it independently cross-validated the cloud backup (both 19/20).
- Ran the cross-machine copy on HGHAUBNER in `user_session` writing to an existing mapped drive, after both SSH-from-AD2 and AD2-side `user_session` failed (double-hop / impersonation has no network creds). Existing GPO mappings work in the impersonated token; fresh UNC does not.
- Did NOT restore REV F's paste file — confirmed absent from both independent backups; framed it as "not in our backups under that name" rather than "never existed," per Mike's caution that the ask may be slightly off.
- Moved the WizTree CSV (a sensitive full file-list) OFF the c-drive share into private `C:\ClaudeTools` on AD2 — it was wrongly staged in a share visible to all c-drive users.
- For the broad migration-gap diff, chose WizTree-both-sides (MFT-fast, exact, CSV-to-CSV) over live RMM enumeration, given ~8.7M files. Catalog is review-only — no auto-restore, since some deletions were intentional and the HGH backup is additive-only.
- AD1 backup: build fresh via `addBackupPlan` CLI (Mike's choice, option b), matched to AD2's real `.cbb` config (read `SerializationSupportRetentionTime=180 days`).
## Problems Encountered
- AD2's local `cbb.exe` reported the image/Files plans "Never started" and `listIBBContent` found "No disk image backups" — stale local repo view. Mike had me restart the Online Backup services; the `list` command then surfaced the file-backup bunch.
- Path confusion: backup stored the share under `D:\c-drive` while the live share is `C:\Shares\c-drive`. Reconciled via NTFS metadata — the old `D:` data volume is gone (now a mounted Windows install ISO); the 10/1/2025 restore migrated the data to `C:\Shares` on the C: volume.
- Cross-machine file copy repeatedly blocked by Windows double-hop / WTS-impersonation (no network creds). Resolved by running on the source machine in `user_session` and writing to an existing mapped drive.
- Repeated bash-heredoc backslash mangling of PowerShell/Python — resolved by base64-encoding PowerShell (`-EncodedCommand`) and writing Python via the Write tool / `chr(92)` instead of literal backslashes.
- WizTree export was in Georg's `Documents`, not `Downloads` as expected — found by listing largest files under the profile.
- Coord API was unreachable for the parking todo — used a repo resume doc instead.
## Configuration Changes
- **AD2 `C:\Shares\c-drive\...\{E,F,G,H}\PCB1366 REV <rev> PRINTOUTS FOR MANUFACTURING\`** — added 19 recovered PDFs (additive; existing files untouched).
- **AD2 `C:\ClaudeTools\clients\dataforth\WizTree_20260604184904.zip`** — moved here (private) from the c-drive share staging; `C:\Shares\c-drive\__wiztree` staging folder removed.
- **AD2 Online Backup services** — restarted (by request) to resync the local repo. No plan changes.
- Repo: created `clients/dataforth/session-logs/2026-06-04-session.md`, `clients/dataforth/migration-gap-diff-RESUME.md`.
- **No AD1 backup plan created yet** (command prepared, parked). No diff catalog written yet (parked).
## Credentials & Secrets
- AD2 SSH: `sysadmin` (INTRANET\\sysadmin), vault `clients/dataforth/ad2.sops.yaml → credentials.password` (note: strip stray backslash).
- HGHAUBNER: no SSH; reached via GuruRMM agent; logged-in user `intranet\ghaubner`.
- MSP360 Managed Backup API: vault `msp-tools/msp360-api.sops.yaml` (api.mspbackups.com, /api/Provider/Login).
- GuruRMM API: vault `infrastructure/gururmm-server.sops.yaml`. Syncro: per-user key (mike) in the syncro skill.
- No new credentials created.
## Infrastructure & Servers
- **AD2** — 192.168.0.6, Win Server 2022 DC + file server. Shares now `C:\Shares\{c-drive,e-drive,webshare}`; old `D:\c-drive` data volume repurposed (D: = mounted install ISO). MSP360 agent `C:\Program Files\Arizona Computer Guru\Online Backup\cbb.exe`; storage account `ACG-Dataforth` (`0b49ca5e-…`). GuruRMM agent `cfa93bb6-…`.
- **AD1** — DC; shares `Engineering`→`C:\Engineering`, `ITSvc`→`C:\Shares\ITSvc`. GuruRMM agent `bf7bc5ee-…`. Only `Image2025` backup plan.
- **FILES-D1** — file server; shares `E:\Shares\{sales,archive}` (no `staff` share — missing). Agent `8566a19d-…`.
- **SAGE-SQL** — `C:\sage`. Agent `120ba7bf-…`.
- **HGHAUBNER** — Georg Haubner's PC; `D:` = pre-attack backup of DF shares (`DF C-Drive`, `DF E-Drive`, `DF WebShare`, `DF Sage`, `DF Server Sales/Archive/Engineering`, + personal `DF Staff`/`Dataforth`). Agent `2aefe0d5-…`.
- Backup sets in `ACG-Dataforth`: `AD2 Image` (image, `35a5c3d2`), file backup `Backup plan on 8/29/2025` (`faad5a67`, restore points 8/29–9/29/2025).
## Commands & Outputs
- Browse file backup: `cbb.exe list -a "ACG-Dataforth" -b faad5a67-… -rp 20250830005237 -path "D:\c-drive\DOCUMENT\DESIGN\SP\SP1366 MAQ20 Communications Module\F\PCB1366 REV F PRINTOUTS FOR MANUFACTURING"`.
- Forensic: `C:\Shares` Created `10/1/2025 2:23 PM`; SP1366 rev/PRINTOUTS folders Created `10/2/2025 ~12:17 PM`; surviving drill PDFs Created `10/2/2025`, Modified = original 2012–2024.
- Copy (HGHAUBNER user_session): local `D:\DF C-Drive\…` → `Q:\…` (mapped `\\ad2\c-drive`) — 19 copied, 5 skipped, 6 files/rev verified.
- AD2 Files plan retention (from `de4fd4fd*.cbb`): `<SerializationSupportRetentionTime>180.00:00:00</…>`, GFS disabled.
- WizTree backup totals: DF C-Drive 2.74M files/426GB; DF E-Drive 2.29M/2261GB; DF Server Sales 461k/1487GB; DF Server Engineering 971k/1079GB; DF Server Archive 1.09M/392GB; DF Sage 58.6k/88GB; DF WebShare 1.06M/2.9GB.
## Pending / Incomplete Tasks
See `clients/dataforth/migration-gap-diff-RESUME.md` for full detail. Parked:
1. **AD1 Files backup** — `addBackupPlan` command ready (NBF, daily 2 AM, 180-day, `C:\Engineering` + `C:\Shares\ITSvc`); run on Mike's OK.
2. **Migration-gap diff** — WizTree both sides tomorrow; diff CSV-to-CSV per share → `clients/dataforth/migration-gap-catalog-2026-06-04.md`. Backup-side CSV at AD2 `C:\ClaudeTools\clients\dataforth\WizTree_20260604184904.zip`.
3. **AD2 Claude** capability updates (syncro/coord + DF wiki read-write + Dataforth data; its repo is `C:\ClaudeTools`).
4. **Dataforth wiki** GuruRMM-enrollment section: update 13 → 45 agents.
5. **REV F `TOP PASTE LAYER`** — John doesn't care; closed.
6. Housekeeping: delete sensitive local copy `GURU-5070 C:\Users\guru\AppData\Local\Temp\wiztree.zip` after the diff.
## Reference Information
- Syncro ticket **#32385** (id 112202781) — https://computerguru.syncromsp.com/tickets/112202781 ; invoice 1650579125 ($0, prepaid).
- Dataforth Corp Syncro customer 578095; contact John Lehman 2851723 (jlehman@dataforth.com).
- GuruRMM API http://172.16.3.30:3001 ; MSP360 API https://api.mspbackups.com.
- Resume doc: `clients/dataforth/migration-gap-diff-RESUME.md`.