> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/release-and-readiness/external-drive-storage-migration.md). # External-drive storage migration Status: planning only. Do not move or delete data until the new drive is connected, identified by model/serial, health-checked and assigned a stable drive letter. ## Current local pressure observed 2026-07-19 * `C:` is a 475.7 GB NTFS volume with approximately 12.2 GB free. * `C:\AEGIS\.deploy` contains approximately 15.76 GB. * `C:\AEGIS\hyperliquid-ai-terminal` contains approximately 5.75 GB. * `C:\Users\brens\.codex` contains approximately 3.65 GB. These are logical file totals, not exclusive on-disk allocation, and must be measured again immediately before migration. ## What should move first Good first candidates are cold, reproducible or archival data: 1. old verified deployment archives, detached release worktrees and retained QA screenshots under `C:\AEGIS\.deploy`; 2. generated videos, marketing masters, screenshots, exports and large download artifacts; 3. verified backups that already have another independent copy; 4. old completed project archives that are not live working trees. Keep the active Git repository, current `node_modules`, package-manager store and ordinary source edits on the internal SSD initially. Running Node/Next builds from a USB drive is slower and an accidental disconnect can corrupt a working tree. Move WSL or Docker virtual disks only through their supported export/import or settings workflow in a separate maintenance window. An external drive is additional storage, not a backup by itself. Irreplaceable source, credentials and private operational evidence require at least one other encrypted copy. ## Drive setup 1. Connect the drive directly to a reliable USB 3.x port and note its manufacturer, model, serial and reported capacity. 2. In Windows Disk Management, confirm the new disk by capacity before touching any partition. Never identify it by disk number from memory. 3. For Windows-only use, initialize it as GPT and create one NTFS volume. Use exFAT only if routine macOS/Linux interchange is more important than Windows permissions and resilience. 4. Label it clearly, for example `NYTSHIFT_ARCHIVE`, and assign a stable unused drive letter. This runbook does not assume a letter. 5. If private backups or operational evidence will be stored on it, enable BitLocker and save the recovery key somewhere other than the drive. 6. Check SMART/vendor diagnostics and run a full filesystem scan before trusting the device. 7. Create a simple structure: ``` :\NYTSHIFT\ deploy-archives\ qa-evidence\ media\ backups\ cold-projects\ manifests\ ``` ## Safe copy-and-verify procedure The first pass is **copy only**. Do not use `/MOVE`, `/MIR`, `Move-Item` or deletion. 1. Re-measure the source and confirm no release build or deployment is using it. 2. Create a SHA-256 manifest for the selected immutable archives and important evidence. 3. Copy with metadata and restartable I/O. A reviewed command will use the actual detected drive letter and exact source subdirectories; do not paste a guessed example against the wrong disk. 4. Compare file counts, byte totals and hashes between source and destination. 5. Open a sample of archives, screenshots and receipts from the external drive and run the repository's public-release verifier on at least one transferred release pair. 6. Leave the original intact for a cooling-off period. Point future archive output at the new drive and complete at least one successful build/verify cycle. 7. Only after the user reviews the verified manifest may old internal copies become deletion candidates. Deletion is a separate explicit operation. Directory junctions can preserve an old path after a successful migration, but add operational ambiguity. Prefer updating archive/output configuration to the new stable path. If a junction is necessary, create it only after the original path has been renamed, the destination has been verified and rollback is documented. ## Later optional migrations ### WSL Use `wsl --export`, unregister only after verifying the export, and `wsl --import` to a directory on the external NTFS volume. Stop all WSL distributions first. This is a maintenance operation because unplugging the drive makes the distribution unavailable. ### Docker Desktop Use Docker Desktop's supported disk-image location setting or backup/restore workflow. Do not manually drag its VHDX while Docker is running. ### Package and build caches Prefer safe pruning of reproducible caches before moving them. If a cache is moved, configure the owning tool's supported store path; do not junction an active cache while processes are running. ## Acceptance checks * The physical drive model/serial and stable letter are recorded. * NTFS health and BitLocker state are known. * Destination capacity comfortably exceeds selected sources plus growth reserve. * Hash manifest, file count and byte count match. * At least one public release archive independently verifies from the external drive. * Active NYTSHIFT source and live VPS release workflows still work. * The drive can be disconnected only after all related processes are stopped. * No original data is deleted without a separate explicit approval. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://nytshift.gitbook.io/nytshift-docs/release-and-readiness/external-drive-storage-migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.