kenpat/kitestacks-homelab
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
kitestacks-homelab/cloud-migration/claude-memory/project-cloud-migration.md
kenpat fb822d5142 Reorganize repos into kitestacks-homelab + plain-English doc rewrite 
- Rewrote RUNBOOK.md and DEBUG-DOCUMENTATION.md in simple 5th-grade language
  with real-world analogies for every technical concept
- Updated README.md with current service inventory and folder map
- Added cloud-migration/ subdirectory (from kitestacks-cloud-migration repo)
- Added autosync/ subdirectory (from kitestacks-homelab-autosync-test repo)
- Added osticket/ subdirectory (from OSTicketSystem repo)
- Added cloud/ placeholder for future cloud configs
- Excluded binary DB/postgres files from autosync subdirectory

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-18 18:37:58 -05:00

3.2 KiB
Raw Blame History

name description metadata
project-cloud-migration KiteStacks server migration plan — Phase 1 (Forgejo backup, restore to new desktop) and Phase 2 (Oracle Cloud VPS, always-on)
node_type type originSessionId
memory project 1d92780e-77c5-41ac-8887-daca0ea55e8b

Phase 1 — STATUS: backup pushed & verified, restore not yet performed

Goal: be able to pull the backup repo onto a new (desktop) machine and physically relaunch the homelab from it.

  • Full server backup lives in Forgejo repo kenpat/kitestacks-cloud-migration (private), clone url http://100.90.13.55:3006/kenpat/kitestacks-cloud-migration.git (also reachable at gitforge.kitestacks.com for small files).
  • Source backup: /home/kenpat/kitestacks-cloud (git repo, 1 commit 6ffcbea, ~4.3GB). Contains archives/*.tar.gz (docker bind-data, syncthing-shared, scripts, host /etc subset), volume-exports/*.tar.gz (named Docker volumes), inventory/, restore/RESTORE.md, SHA256SUMS.
  • 14 large files (~2.3GB) are tracked via Git LFS — required apt-get install git-lfs (no passwordless sudo on this host, user ran it manually) and git lfs migrate import --include="archives/*.tar.gz,volume-exports/*.tar.gz".
  • Known gotcha: Forgejo's public hostname gitforge.kitestacks.com (Cloudflare Tunnel) returns HTTP 413 for any LFS object >~100MB. The 3 big files (docker-bind-data.tar.gz ~967MB, kite-ai_open-webui.tar.gz ~963MB, syncthing-shared.tar.gz ~165MB) had to be PUT directly to http://100.90.13.55:3006/kenpat/kitestacks-cloud-migration.git/info/lfs/objects/<oid>/<size> (local Tailscale IP, bypasses Cloudflare). git lfs pull for these 3 files will need the same workaround — clone/pull via the local IP, not the public hostname.
  • Verified: local HEAD == remote HEAD, all 15/15 LFS objects present server-side with sizes matching SHA256SUMS OIDs.
  • Documented in /home/kenpat/forgejo-repos/kitestacks-homelab/docs/KiteStacks-Homelab-Documentation-v1.3.922.md.

Phase 1 remaining work: actual restore-to-new-desktop has NOT been done/tested yet. When the user pulls a Claude session in on the new desktop, the workflow is: clone kitestacks-cloud-migration (via local IP for LFS), follow restore/RESTORE.md, restore Docker volumes from volume-exports/, restore bind-mounts from archives/docker-bind-data.tar.gz, bring stacks up via the compose files, re-point Cloudflare Tunnel.

Why: User wants to migrate the KiteStacks homelab off the current desktop onto new hardware first (Phase 1), then to an always-on Oracle Cloud VPS (Phase 2) so services don't go down when the desktop sleeps/is off.

How to apply: When the user says they're moving to a new desktop / starting the restore, walk through restore/RESTORE.md using this memory's notes (especially the LFS/Cloudflare gotcha). Once services are confirmed running on the new desktop, mark Phase 1 complete in this file, notify the user explicitly, and begin Phase 2 (Oracle Cloud VPS setup) — update this file with Phase 2 progress the same way.

Phase 2 — STATUS: not started Plan: provision an Oracle Cloud VPS, migrate the same stack there for always-on hosting (independent of desktop power state). No infra details yet — to be filled in once started.