docs-alpha.jayfield.org/SYNC-PLAN.md

# alpha.jayfield.org — Intranet Sync Plan (vlda-01 → alpha)

**Status: item 1 (Gitea) done, the rest still planning-only.** This is a
point-in-time plan for later reference, not a live inventory (`README.md`
is the live inventory) and not a build runbook (`SETUP.md` is that).
Update this file as decisions get made and pieces get built; move
finished work into `README.md` once it's live, the way the
KeePass/Nextcloud migration and Gitea did.

`vlda-01` itself, and anything else on the home LAN, lives under the
private `home.jayfield.org` namespace — not part of `alpha`'s public,
authoritative `jayfield.org` zone (see README.md's "Domain namespace").

## Problem

`vlda-01` (home intranet server, behind a home LAN, not 24/7 online) hosts
four things the household wants reliably available: plain files, Gitea,
Jellyfin, and a Dogecoin node/wallet used for daily transaction catchup.
Goal: use `alpha.jayfield.org` (public, 24/7, already running Docker +
Nextcloud) as the always-available side, without reproducing the failure
mode that got the old setup removed.

**Why not just revive the old WireGuard tunnel + CIFS mount** (see
`README.md`'s "Previously resolved" history — `alpha_at_moon` tunnel +
`192.168.22.0/24` CIFS mount, purged 2026-07-19, configs backed up to
`/root/removed-configs-backup/` if ever needed as a reference): that setup
required `vlda-01` to be reachable *at the moment alpha wanted the data* —
a live mount. That's structurally incompatible with "not 24/7 online." Each
service below instead either pulls data to alpha ahead of time or migrates
outright, so alpha's availability stops depending on vlda-01's.

## Per-service plan

### 1. Files → Syncthing

- Syncthing container on alpha, data lands at `/srv/intranet-data/<folder>`
  (host-inspectable, matching the `/srv/nextcloud/data` pattern). Admin GUI
  bound to `127.0.0.1:8384`, reverse-proxied through Apache like
  Portainer/Nextcloud — never expose the setup UI directly.
- Syncthing client on `vlda-01` dials **out** to alpha — no inbound port
  forwarding needed at home, unlike the old tunnel. Catches up automatically
  whenever vlda-01 gets power + internet.
- Direction: start **send-only from vlda-01 → receive-only on alpha**
  (vlda-01 stays authoritative, alpha is a live mirror). Revisit bidirectional
  later once trusted.
- Firewall: open `22000/tcp` + `21027/udp` on alpha for Syncthing.
- Expose via Nextcloud: enable the built-in `files_external` app, mount
  `/srv/intranet-data/<folder>` as local external storage — same web UI
  (`cloud.jayfield.org`) already used for the KeePass vaults.

**Status: not started.**

### 2. Gitea → full migration, not sync

**Status: done, 2026-07-26 — see `README.md`'s "Gitea" section for the live
setup.** vlda-01's copy left stopped as a cold backup, not decommissioned.

#### 2b. Ongoing backup: `git.jayfield.org` (alpha) → `vlda-01.home.jayfield.org`

**Status: sketch only, not built.** Now that alpha is the canonical live
Gitea, vlda-01's stopped copy will just get staler over time unless
something keeps feeding it. Goal here is a **backup**, not a hot standby
or live mirror — point-in-time recovery if alpha's Gitea is ever lost,
not instant failover.

**Same network constraint as everything else in this plan**: alpha has no
route into the home LAN (that's exactly the tunnel dependency removed
2026-07-19), and vlda-01 isn't guaranteed to be on. So the pull has to be
**initiated by vlda-01** whenever it happens to be up — never alpha
reaching in.

**Why not a raw `rsync` of `/srv/gitea/data`**: the DB is a live SQLite
file (`gitea.db`); rsyncing it while Gitea is writing risks grabbing it
mid-transaction and shipping a corrupt copy. Gitea ships a purpose-built
`gitea dump` command for exactly this (confirmed available on this
install/version) — it produces one consistent archive (DB + repos + LFS +
config together), which is also what Gitea's own restore procedure
expects, rather than reinventing consistency handling.

**Design**:
1. **On alpha** — a nightly cron job runs
   `docker exec -u git gitea gitea dump -f /data/backups/gitea-dump-<date>.zip --skip-index`
   (`--skip-index` drops the regenerable Bleve search index, which isn't
   needed to restore and just adds size/time) into
   `/srv/gitea/data/backups/` (a subdirectory of the same bind mount, so
   it's already host-inspectable without extra volumes). Prune to the
   last ~14 daily archives in the same job — at the repo sizes seen here
   (~4GB total) that's a bounded, comfortable footprint against alpha's
   136GB free.
2. **On vlda-01** — a cron job (running whenever vlda-01 is powered on;
   picks up wherever it left off, same "catches up automatically"
   philosophy as the Syncthing files plan above) pulls the newest archive
   from alpha via `rsync`/`scp` over SSH into a dedicated backup directory
   (plenty of headroom on the Unraid array — 3.7TB free at last check).
   Keep its own retention window there too, independent of alpha's.
3. **Restore path, if ever needed**: manual, deliberate — stop the target
   Gitea container, unpack the chosen dump's DB/repos/etc. into `/data`
   per Gitea's documented restore steps, restart, verify. Not automated;
   matches how every other risky operation in this repo is handled
   (careful, verified, not blind).
4. **Explicitly out of scope for this design**: real-time replication,
   automatic failover, or DNS/traffic cutover — none of that fits a
   personal git host's actual usage pattern (a handful of commits per
   session), and the added complexity/failure surface wouldn't be worth
   it. Revisit if that ever changes.
5. **Future consolidation**: if/when Syncthing (item 1 above) actually
   gets built, it could carry these dump archives too instead of a
   separate rsync/cron pull — one sync mechanism instead of two. Not
   worth blocking this on Syncthing existing first, though.

**Open question before building**: nightly cadence assumed above — confirm
that matches how often this actually needs protecting (probably fine,
given commit frequency, but worth a sanity check before automating it).

### 3. Jellyfin → scoping question, not yet planned

Media libraries are often hundreds of GB to multiple TB, and local hardware
transcoding at home may not have an equivalent on the VPS. Before sketching
an approach, need:

- Approximate library size.
- Is the actual goal *remote* streaming (away from home), or is Jellyfin
  only ever watched on the home LAN? If the latter, migrating buys nothing —
  Jellyfin only needs to be up when someone's actually watching, which is
  whenever vlda-01 would be on anyway. If remote access is wanted, next step
  is sizing alpha's disk/bandwidth budget for it.

**Status: blocked on the above — no plan yet.**

### 4. Dogecoin node/wallet → security-conscious split, needs sign-off

**Do not migrate the wallet wholesale without explicit confirmation.** Per
the attacker report (`SendUserFile`'d 2026-07-19), this host takes on the
order of 10,000 automated SSH/scan attempts a month. Putting spending keys
on the same public, constantly-probed box is a materially different risk
than at home.

Recommended design:
- Run `dogecoind` on alpha as a Docker container with **`disablewallet=1`**
  — blockchain sync only, no private keys, no funds at risk. Stays
  permanently caught up with the network regardless of vlda-01's uptime.
- Keep the actual wallet (`wallet.dat`, spending keys) only on vlda-01.
  Point vlda-01's `dogecoin-cli`/GUI at alpha's node as its backend
  (`-connect=`), with RPC reachable **only** over an authenticated tunnel
  (SSH-forwarded or WireGuard) — never bind RPC to a public interface; an
  open Dogecoin RPC port is exactly the kind of thing scanners probe for.
- Result: "daily transaction catchup" becomes near-instant once vlda-01
  turns on, since the chain is already synced — without private keys ever
  touching the internet-facing box.

**Open question, needs the user's explicit answer before implementing**:
go with the wallet-split design above, or is the fund exposure small enough
to just run the wallet on alpha too, for simplicity? Do not proceed with
either without confirmation — this is the one piece of this plan with real
financial/security stakes.

## Suggested build order

1. ~~Gitea~~ — done, see above.
2. Files via Syncthing (validates the intermittent-sync approach before
   trusting it with anything else).
3. Dogecoin node — **only after explicit sign-off on the wallet-split
   question above.**
4. Jellyfin — **only after the scoping question above is answered.**