Unraid 7.3 Internal Boot: Move Off USB Without Losing Recovery
Tech GuruQuick Answer
Treat internal boot as a change to boot media, not as a replacement for configuration backups or a licensing plan. Record the current devices and boot order, preserve the configuration and array assignments, and test recovery before switching. If using a mirror, rehearse one-member loss and replacement on a safe target. Keep the supported USB-first restore path available even after the server boots from internal storage.
Evidence status: Unraid's Internal Boot FAQ documents mirroring, licensing separation, and USB-first backup restoration. No migration, degraded-boot, replacement, resynchronization, or TPM test was performed for this article. Hardware-specific results remain to be collected.
What To Check
The Internal Boot FAQ treats internal boot as optional, supports a mirrored ZFS boot setup, and separates licensing from boot method. It also says both internal SSD/NVMe boot devices count toward the attached-device limit. Check that limit before allocating a mirror.
Decide what problem the move solves on your server. Boot-device resilience, configuration recovery, array data protection, and license recovery are different checks. A successful first boot answers only one of them. Keep the original USB/configuration recovery materials until the remaining checks have passed.
Key Concepts In Plain Language
- Boot redundancy: Continued boot capability after a supported boot-device failure; it is not a historical configuration backup.
- Configuration recovery: Restoring the saved server configuration through the vendor-supported path, with array assignments preserved.
- License dependency: The USB or TPM-related licensing arrangement to verify separately from the selected boot device.
Technical Checklist
- Separate boot-device redundancy from configuration backup, array data protection, license handling, and the USB-first recovery path.
- Record firmware boot order, internal-device count, TPM or encryption behavior, and the exact identifiers shown before migration.
- Simulate loss of one mirrored internal boot member and prove alerts, continued boot, replacement, and resynchronization.
- Exercise recovery to supported USB media without overwriting the protected configuration backup or array assignment records.
Interactive Operating Model
Use the detailed runbook and acceptance checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Record device identifiers and array assignments before selecting internal boot targets. Protect the configuration backup, credentials, encryption material, and original recovery media outside the server. Use an isolated rehearsal where possible; do not simulate a boot failure by disconnecting an unidentified array or pool member.
- Confirm the exact installed release, edition, repository, firmware, and add-on state instead of relying on the dashboard label alone.
- Export configuration and protect application data, credentials, certificates, and encryption material separately.
- Stage on a clone, spare node, canary device, or least-critical workload whenever the platform allows it.
- Define stop conditions and console access before the maintenance window begins.
Go, Hold, Recover, Or Escalate
Hold the move if device identity, licensing/device-count eligibility, or USB recovery is unclear. Stop on any unexpected disk assignment, boot-order change, or encryption prompt, and resolve it before starting normal services.
Planned Checks And Recovery
Step 1: Record media, licensing, and boot order
Capture the installed release, boot and array device identifiers, firmware boot order, configuration-backup location, and license method. Record TPM or encryption dependencies where used. Decide which devices are safe boot targets before entering the migration workflow.
Step 2: Prove USB-first recovery
The FAQ restore path starts by restoring the backup to USB and booting it, then using Settings > Onboarding Wizard to switch back to internal boot. It says not to copy flash-backup files manually into the internal boot partition. Rehearse the supported path while protecting the original backup and array records.
Step 3: Migrate one recoverable target
Follow the supported workflow for the installed release and selected devices. After boot, compare actual boot media, firmware order, license state, and array assignments with the before record. Do not treat a reachable web interface as proof that all recovery and storage settings survived.
Step 4: Rehearse mirror degradation and replacement
On a safe test target, identify the exact boot member involved and plan the failure simulation so it cannot affect protected data devices. Record degraded-state alerts, continued boot behavior, replacement, and resynchronization using the documented assignment flow. Stop if the remaining member or its boot path is uncertain.
Step 5: Return through the recovery path
Repeat the USB-first restore rehearsal and verify the restored configuration, boot selection, licensing, and service access. Keep the USB recovery materials available after returning to internal boot. Record any firmware or TPM-dependent steps another operator would need.
Validation Checklist
- Before/after records identify the same intended boot devices and unchanged protected array assignments.
- Boot-member loss, alert delivery, replacement, and resynchronization each have a separate observed result.
- Configuration restoration follows the supported USB-first path without overwriting the only backup.
- License/device-count state, firmware boot selection, and applicable encryption/TPM behavior are checked after recovery.
Troubleshooting
- The server still boots from USB: Compare actual firmware boot order with the intended internal device selection; keep the working recovery path intact while investigating.
- The mirror is degraded: Identify the failed boot member and use the supported replacement flow, distinguishing it from array/data devices.
- Recovery boots but configuration or licensing differs: Compare the restored backup, device labels/identifiers, and license method with the before record before allowing normal service.
Security, Privacy, Legal, And Recovery Boundaries
Security
Use official packages and release guidance, preserve signing and authentication controls, and do not expose a management plane to simplify migration.
Privacy
Configuration exports and support bundles may contain names, addresses, tokens, certificates, device identifiers, and user data; encrypt and restrict them.
Legal
Review software licenses, support entitlements, and retention obligations before copying production data into a test environment.
Recovery
A rollback is credible only when its media, configuration, keys, data, boot path, and restore order are available outside the system being changed.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
The documented mirror and recovery features are not evidence that this server's firmware, TPM setup, device count, or replacement procedure has passed. No throughput improvement, hardware longevity measurement, or data-recovery guarantee is claimed. Boot redundancy does not establish that configuration or array data can be recovered.
Related TechGeeks Resources
- Linux and Homelab Notes: Start Here
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- How Do You Document a Homelab So Someone Else Can Recover It?
References
Next Action
Keep the migration only after both the boot-failure rehearsal and USB-first restore are explained. Store the configuration backup and device-assignment record outside the server.
