Clarify VPS full-host migration parity and storage posture
This commit is contained in:
axiomlogicnexus
parent
0ea2656990
commit
992a03a266
2 changed files with 186 additions and 40 deletions
|
|
@ -278,20 +278,25 @@ Confirmed:
|
|||
Not confirmed:
|
||||
|
||||
- current production web artifacts are **not** identical to the currently
|
||||
visible local build outputs for `ScriptoriumAI` and `VerticalTension`
|
||||
visible tracked local build outputs for `ScriptoriumAI`
|
||||
- `VerticalTension` no longer shares that same uncertainty because a fresh
|
||||
detached `HEAD` build reproduced the live public asset hashes
|
||||
|
||||
Observed mismatch examples:
|
||||
|
||||
- production `scriptoriumai.io` serves asset `index-DKzZ39HF.js`
|
||||
- current local `ScriptoriumAI` build references `index-B2KwrMUv.js`
|
||||
- production `verticaltension.com` serves `index-CgVsNXoc.js`
|
||||
- current local `VerticalTension` build references `index-ChYBuzHU.js`
|
||||
- fresh detached `VerticalTension` build from repo `HEAD` also produced
|
||||
`index-CgVsNXoc.js` and `index-ismjD07_.css`
|
||||
|
||||
Reconstruction rule:
|
||||
|
||||
- if exact production continuity matters, migrate deployed artifacts from the
|
||||
old server
|
||||
- do not assume a local rebuild reproduces the current public state exactly
|
||||
- for `ScriptoriumAI`, if exact production continuity matters, migrate deployed
|
||||
artifacts from the old server and preserve repo `HEAD` separately
|
||||
- for `VerticalTension`, the current live public site is reproducible from a
|
||||
fresh `HEAD` build, but migrating the deployed web root is still prudent for
|
||||
rollback and zero-surprise continuity
|
||||
|
||||
## Minimum reconstruction set for a control-plane-only cutover
|
||||
|
||||
|
|
@ -327,6 +332,12 @@ If the new VPS is replacing the old host completely, also reconstruct:
|
|||
- `/srv/verticaltension-web`
|
||||
- all matching certbot SAN certificates listed above
|
||||
|
||||
Additional full-host rule:
|
||||
|
||||
- the new VPS should explicitly cover `www.verticaltension.com` in the final
|
||||
NGINX/vhost/TLS shape because live inspection of the old host currently shows
|
||||
a certificate-name mismatch on that host
|
||||
|
||||
## Recommended next action
|
||||
|
||||
Before live migration:
|
||||
|
|
|
|||
|
|
@ -286,7 +286,7 @@ This is the key result for migration safety.
|
|||
Confirmed:
|
||||
|
||||
- local `HyperTwist` app repo `HEAD` and remote `origin/main` match at:
|
||||
- `19c8a78f92f6c5d84558cbb57d682288edb302b2`
|
||||
- `0ea26569902f181ebeb7c9db2c14c2c0b59ae466`
|
||||
- local `ScriptoriumAI` repo `HEAD` and remote `origin/main` match at:
|
||||
- `118a85c0fee3fff34c071dd78d7cfe3eacc8ba95`
|
||||
- local `VerticalTension` repo `HEAD` and remote `origin/main` match at:
|
||||
|
|
@ -307,37 +307,150 @@ Operational consequence:
|
|||
|
||||
### Production artifact parity
|
||||
|
||||
The live production web roots on the old VPS are **not** provably identical to
|
||||
the current local built outputs.
|
||||
The three important truths are:
|
||||
|
||||
- source-control heads are safe
|
||||
- `VerticalTension` production is now reproducible from a fresh `HEAD` build
|
||||
- `ScriptoriumAI` production is **not** provably reconstructible from the
|
||||
currently tracked clean source alone
|
||||
|
||||
#### `ScriptoriumAI`
|
||||
|
||||
Observed:
|
||||
|
||||
- production `scriptoriumai.io` `index.html` serves:
|
||||
- latest repo `HEAD` is:
|
||||
- `118a85c0fee3fff34c071dd78d7cfe3eacc8ba95`
|
||||
- commit date: `2026-05-08 18:05:14 +0200`
|
||||
- latest tracked frontend artifact update in git is older:
|
||||
- `012fc396ea6eba826f27f4a0f0c9cc17a3354af8`
|
||||
- commit date: `2026-04-23 14:56:12 +0200`
|
||||
- production `scriptoriumai.io` currently serves:
|
||||
- `/assets/index-DKzZ39HF.js`
|
||||
- current local `C:\ScriptoriumAI\scriptoriumai-ui\dist\index.html` references:
|
||||
- `/assets/index-D8zU9W-S.css`
|
||||
- those live assets report:
|
||||
- `Last-Modified: Fri, 08 May 2026 16:20:04 GMT`
|
||||
- which is `2026-05-08 18:20:04 +0200`
|
||||
- current tracked/local
|
||||
`C:\ScriptoriumAI\scriptoriumai-ui\dist\index.html` references:
|
||||
- `/assets/index-B2KwrMUv.js`
|
||||
- production `verticaltension.com` `index.html` serves:
|
||||
- `/assets/index-CgVsNXoc.js`
|
||||
- `/assets/index-ismjD07_.css`
|
||||
- current local `C:\VerticalTension\dist\index.html` references:
|
||||
- `/assets/index-ChYBuzHU.js`
|
||||
- `/assets/index-Ck8vgTXb.css`
|
||||
- `/assets/index-D8zU9W-S.css`
|
||||
- the production JS hash `DKzZ39HF` was not found in tracked
|
||||
`scriptoriumai-ui/dist/index.html` history during local inspection
|
||||
|
||||
Meaning:
|
||||
|
||||
- source-control heads are safe
|
||||
- current production artifacts are not byte-for-byte the same as the currently
|
||||
visible local build outputs
|
||||
- therefore, if the goal is exact production continuity, migrate the currently
|
||||
deployed web/app content from the old VPS instead of rebuilding from local
|
||||
source during cutover
|
||||
- the latest committed source-control state is the May 8 repo `HEAD`
|
||||
- the latest known deployed public artifact state is the May 8 production web
|
||||
root on the old VPS
|
||||
- those are related in time, but not provably byte-identical
|
||||
- the exact live `ScriptoriumAI` public surface should therefore be preserved
|
||||
from the old VPS as deployed content, not re-derived from git alone during
|
||||
the first cutover
|
||||
|
||||
Recommended safety rule:
|
||||
Safety rule for `ScriptoriumAI`:
|
||||
|
||||
- for zero-surprise cutover, copy the live deployed content from the old VPS
|
||||
- only do a fresh rebuild/deploy after the new VPS replacement is stable and
|
||||
only when you intentionally want to refresh production to the current source
|
||||
state
|
||||
- preserve both:
|
||||
- repo `HEAD`
|
||||
- old VPS deployed state under `/var/www/scriptoriumai` and related app roots
|
||||
|
||||
#### `VerticalTension`
|
||||
|
||||
Observed:
|
||||
|
||||
- production `verticaltension.com` currently serves:
|
||||
- `/assets/index-CgVsNXoc.js`
|
||||
- `/assets/index-ismjD07_.css`
|
||||
- a fresh detached build from repo `HEAD`
|
||||
`91bee21a7101ef08d3e91db9040f8a3ec8d3dd27` reproduced:
|
||||
- `index-CgVsNXoc.js`
|
||||
- `index-ismjD07_.css`
|
||||
|
||||
Meaning:
|
||||
|
||||
- `VerticalTension` production is aligned with a fresh `HEAD` build
|
||||
- preserving the live deployed web root is still prudent for rollback, but the
|
||||
current public site is not showing the same ambiguity seen in `ScriptoriumAI`
|
||||
|
||||
Cross-product safety rule:
|
||||
|
||||
- for zero-surprise cutover, archive and copy the live deployed content from
|
||||
the old VPS for all public surfaces
|
||||
- after the new VPS is stable, intentional rebuild/redeploy can then replace
|
||||
those copied artifacts where desired
|
||||
|
||||
## Confirmed operator decisions
|
||||
|
||||
As of the current migration pass, these decisions are now treated as confirmed:
|
||||
|
||||
- this is a **full-host replacement**, not only a control-plane-only move
|
||||
- all current production domains should end up on the new VPS
|
||||
- DNS stays hosted at IONOS
|
||||
- nameserver delegation does **not** need to change for remote development
|
||||
- remote development only depends on SSH reachability, Linux user/tooling
|
||||
setup, and the host being stable
|
||||
|
||||
Additional cutover rule:
|
||||
|
||||
- `www.verticaltension.com` must receive explicit NGINX vhost coverage and a
|
||||
certificate that matches that host on the new VPS
|
||||
- this is necessary because live inspection of the old host currently shows a
|
||||
certificate-name mismatch on `https://www.verticaltension.com`
|
||||
|
||||
## Authorship preservation posture
|
||||
|
||||
Authoritative source:
|
||||
|
||||
- local Windows folder:
|
||||
`C:\Users\Anthracite Ace\Desktop\Authorship`
|
||||
|
||||
Current measured local size:
|
||||
|
||||
- total: `17.70 GiB`
|
||||
- `.zip` files: `11.78 GiB` across `459` files
|
||||
- non-zip files: `5.93 GiB`
|
||||
|
||||
Recommended migration posture:
|
||||
|
||||
- keep the current working-files mirror lane for visible non-zip content
|
||||
- preserve the full local folder authority before any destructive cleanup
|
||||
- if the operator wants the backup zip history on the new VPS as well, store it
|
||||
as a **separate cold archive lane**, not mixed into the normal incremental
|
||||
working-files mirror lane
|
||||
|
||||
Reason:
|
||||
|
||||
- that preserves the existing lightweight change-oriented mirror behavior for
|
||||
active authorship work
|
||||
- while still allowing the new higher-capacity VPS to hold the backup zip
|
||||
history after cleanup and one-time upload
|
||||
|
||||
## Storage posture for the current local corpus
|
||||
|
||||
Measured local sizes during this pass:
|
||||
|
||||
- `C:\VectorShell`: `28.22 GiB`
|
||||
- `C:\ScriptoriumAI`: `15.86 GiB`
|
||||
- `C:\HyperTwist`: `14.69 GiB`
|
||||
- `C:\Users\Anthracite Ace\Desktop\Authorship`: `17.70 GiB`
|
||||
- `C:\VerticalTension`: `0.11 GiB`
|
||||
|
||||
Important nuance:
|
||||
|
||||
- the current observed `C:\VectorShell` footprint is materially below the
|
||||
operator's rough `~100 GiB` estimate
|
||||
- inside `C:\VectorShell`, the largest current slices are:
|
||||
- `mirrors`: `17.54 GiB`
|
||||
- `UnrealVectorShell`: `6.51 GiB`
|
||||
- `sentrux`: `3.11 GiB`
|
||||
- if other large VectorShell-related stores exist outside `C:\VectorShell`,
|
||||
they must be added separately to any final storage budget
|
||||
|
||||
Operational conclusion:
|
||||
|
||||
- the current observed local corpus comfortably fits within the new VPS
|
||||
capacity envelope
|
||||
- long-term repo growth is still real, so production retention policy should
|
||||
stay intentional rather than assuming the VPS is an infinite mirror warehouse
|
||||
|
||||
## Rider remote-development setup
|
||||
|
||||
|
|
@ -391,17 +504,14 @@ Recommended use:
|
|||
|
||||
## Recommended next action
|
||||
|
||||
Do not start live server migration yet.
|
||||
Do not change DNS yet.
|
||||
|
||||
Next action is to fill the pending-input section above with:
|
||||
Next action is to complete the pre-cutover archive and reconstruction pass:
|
||||
|
||||
1. new VPS IP and access details
|
||||
2. DNS/nameserver details
|
||||
3. hostname cutover scope
|
||||
4. preferred development username
|
||||
|
||||
Once those are supplied, the live execution pass can begin from the new-host
|
||||
bootstrap phase.
|
||||
1. archive the old VPS live surfaces and config
|
||||
2. restore the full selected role set on the new VPS
|
||||
3. validate NGINX/vhost/cert readiness there, including `www.verticaltension.com`
|
||||
4. only then perform the DNS record switch at IONOS
|
||||
|
||||
## DNS record recommendations based on current findings
|
||||
|
||||
|
|
@ -456,8 +566,18 @@ Current observed public DNS already points to the old production VPS:
|
|||
- `A git -> 212.227.22.66`
|
||||
- `CNAME www -> scriptoriumai.io`
|
||||
|
||||
Do not change these yet unless the ScriptoriumAI production surfaces are part of
|
||||
the same cutover window.
|
||||
For the full-host cutover window, change all of these `A` records to:
|
||||
|
||||
- `212.227.13.220`
|
||||
|
||||
Keep unchanged:
|
||||
|
||||
- `CNAME www -> scriptoriumai.io`
|
||||
- current mail records
|
||||
- `_domainconnect`
|
||||
- `_dmarc`
|
||||
- DKIM-related CNAMEs
|
||||
- CAA records
|
||||
|
||||
### `verticaltension.com`
|
||||
|
||||
|
|
@ -470,8 +590,23 @@ Current observed public DNS already points to the old production VPS:
|
|||
- `A ci -> 212.227.22.66`
|
||||
- `A git -> 212.227.22.66`
|
||||
|
||||
Do not change these yet unless VerticalTension is included in the same cutover
|
||||
window.
|
||||
For the full-host cutover window, change all of these `A` records to:
|
||||
|
||||
- `212.227.13.220`
|
||||
|
||||
Keep unchanged:
|
||||
|
||||
- the existing non-`A` `www` records
|
||||
- current mail records
|
||||
- `_domainconnect`
|
||||
- `_dmarc`
|
||||
- DKIM-related CNAMEs
|
||||
|
||||
Important nuance:
|
||||
|
||||
- do **not** convert `www.verticaltension.com` to `CNAME` in this pass
|
||||
- simply update the existing `A www` target once the new VPS is ready
|
||||
- the new VPS must explicitly serve `www.verticaltension.com` with matching TLS
|
||||
|
||||
## `www` guidance
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue