claudetools/session-logs/2026-06-03-mspbackups-b2-storage-cleanup.md

MSP360 / Backblaze B2 storage cleanup — PARKED 2026-06-03

User

• User: Mike Swanson (mike)
• Machine: GURU-5070
• Role: admin

Status: PARKED — bucket is in a safe, stable state. Scheduled purge completes on its own in ~24–48h.

Goal

Clean up the legacy shared MSP360 destination (generic B2 bucket MSPBackups20200311 / "B2Storage") — find data still using it, migrate active users to per-client buckets, remove orphaned data, eventually retire the bucket.

Key findings (B2 = ground truth; MSP360 numbers are NOT reliable)

• MSP360 dashboard storage is a plan-derived internal tally, refreshed daily — NOT a live read of B2. (GET /api/Billing: CurrentSpaceUsed "updated once a day", AverageSpaceUsed "calculated based on backup plans information".) It does NOT reconcile to physical B2 per-account in either direction (overstates seastman 1.98TB→21GB, mike@ 0.43TB→2GB; understated beckykahn ~0→475GB).
• Phantom accounts explained: admin@azcomputerguru.com (15.21TB), vland@airyoptics (12.57TB), etc. show big MSP360 volumes but have no/spent data in B2 — their data was already deleted by prior lifecycle purge rules, and MSP360's counter froze. admin@ is NOT a destination-owner aggregate (bucket is 51TB, not 15.21) — it's a frozen phantom. Confirmed by lifecycle rules present on MBS-f1885cea…, MBS-98f0c6ae… (vland) etc. with no live data.
• Generic bucket physical = 51.015 TB, 11.33M versions, 28 top-level MBS-<guid>/ prefixes. ~48 TB is active client backups (the migration set); only ~3–4 TB is genuinely orphaned. Migrating active data to other buckets does NOT save cost (same bytes elsewhere) — only orphan purge does.
• Dual-destination accounts: freshness check (newest object ts) decided them — rohrbach/Mike-Think (13.23TB) is still live on generic today (not reclaimable); bestmassage frozen 2024-08 (migrated to ACG-PST, reclaimable).
• Storage accounts (GET /api/Accounts): only 2 — Local-E (LocalFS), MSPBackups (BackblazeB2, AccountID ad1b19fd-9350-4fa2-9a07-6200fca14797). ACG-* names are destinations under MSPBackups. Create/modify via API: POST/PUT /api/Accounts, …/CreateDestination, …/EditDestination. Reconcile: all 13 MSP360 destinations have a B2 bucket; ACG-IX is an empty B2 bucket with no MSP360 destination (orphan/reserved). No bucket has immutability/object-lock.

Actions TAKEN this session (bucket MSPBackups20200311, current state: 21 lifecycle rules, revision 63)

Scheduled purge (~3.2 TB, completes ~24–48h via B2 lifecycle hide@1/delete@1):

• Tucson Safety MBS-1c527291-…/ (0.292TB) — user-authorized
• bestmassage generic MBS-54a647a3-…/ (2.474TB) — frozen 2024-08; verified current copy is live in ACG-PST (newest 2026-06-03)
• Saguaro ×3: MBS-114c80eb-…/ (L0U6QUN), MBS-a460695c-…/ (SC-SERVER), MBS-ff910354-…/ (DGM4C1T) — offboarded
• seastman …/CBB_GTI-EXCHANGE/ only — user-authorized ("GTI-EXCHANGE can go")
• mike@ MBS-85b4355a-…/ (2GB webhost), rogue MBS-4969337d-…/ (~0, no MSP360 user, mdmlaw)

Protective rule REMOVALS (non-destructive — un-scheduled erroneous/pending purges):

• MBS-a39b0d4c-…/CBB_MIKE-THINK/ — rohrbach 13.23 TB ACTIVE — pre-existing purge rule from a prior cleanup; caught before B2's daily pass fired (data confirmed intact). Active backup was at risk of deletion.
• MBS-651e4c79-…/ — diegobuilder (Air Pros), active — same.
• MBS-c064d061-…/CBB_MAS90SVR/ + my over-broad account-root MBS-c064d061-…/ — protect MAS90SVR pending Mike's check.

OPEN ITEMS (resume here)

1. HIGH/SAFETY — audit ALL B2 buckets' lifecycle rules for purge rules on ACTIVE accounts. A prior cleanup endangered rohrbach's 13 TB here; same may exist in ACG-* per-client buckets. Read-only; do this first.
2. MAS90SVR — Mike checking status; CBB_MAS90SVR rule removed (protected). Decide keep vs purge.
3. beckykahn / LAB-BECKY (475 GB) — held; stopped backing up 2026-04-14 (not long-abandoned). Confirm decommissioned before purge (MBS-20e00bf6-…/).
4. rohrbach + diegobuilder — confirm protective rule removal was correct (almost certainly — both active). Re-addable if intentional.
5. Post-purge verify (after 2026-06-05): re-measure MSPBackups20200311 (expect ~3.2 TB drop), then lifecycle-remove the spent rules.
6. Phantom MSP360 user cleanup (cosmetic): admin@/vland/etc. via DELETE /api/Users/{id}/Account (metadata-only — does NOT touch B2). Fixes the dashboard; frees nothing (data already gone).
7. Active-user migration (the big project, ~48 TB): per-client destination + plan repoint (console — Remote Management API is disabled, no API automation) + reseed; only then retire the generic bucket. Not a cost play.

Reference / access

• MSP360 API: https://api.mspbackups.com (DNS fails locally → pin 52.6.7.137 + SNI). Auth POST /api/Provider/Login. Creds: vault msp-tools/msp360-api.sops.yaml. /Help = full endpoint docs. Correct user-data delete = DELETE /api/Users/{id}?deleteUserData=true (but blocked on "personal" accounts); computer = DELETE /api/Users/{userId}/Computers (body [{DestinationId,ComputerName}]).
• B2: skill .claude/skills/b2/; account 46f69bc61163; generic bucketId b4268f56790bccc671010613. Purge = delete-prefix <bucket> <prefix> [--allow-account-root] --confirm (lifecycle, ~24–48h); undo-able only before the daily pass via lifecycle-remove.
• Separately pending (earlier today): Glaztech SBS MSP360 removal needs the web portal (API blocked by "personal user" guard) — coord todo db03f8fe. Grok post-mortem: docs/session-notes/2026-06-03-claude-postmortem-grok-mspbackups-sbs.md.

Note

Unrelated dev-mode lock guruconnect/agent/src (held by this session) is from other work — left as-is.