RouterOS Stable Still Needs A Canary: A 7.23 Upgrade Runbook
Tech GuruQuick Answer
Choose a recoverable RouterOS device that represents the hardware and features you actually use. Save both a binary backup and a readable export off-device, preserve local recovery access, then upgrade that canary before the fleet. Test IPv4/IPv6, DNS-over-HTTPS, bridge VLANs, CAPsMAN, containers, scripts, and export behavior where used. A stable-channel label does not establish compatibility with every router model or configuration.
Evidence status: MikroTik's 7.23 announcement documents the release and pre-upgrade backup, power, and free-space precautions. No canary upgrade, feature test, export comparison, or Netinstall recovery was performed here. This is a maintenance test plan, not a tested device-specific upgrade recipe.
What To Check
MikroTik's 7.23 announcement calls for off-device backup/export files, reliable power, and enough free storage for the packages. Use the vendor announcement and target release notes for release facts; reports from other operators can suggest tests but cannot certify your router.
Pick the canary by its role, model, architecture, packages, and active features, not simply because it is spare. A router without CAPsMAN or containers cannot establish that those services survive the upgrade. Record the limits of each canary before expanding to unlike devices.
Key Concepts In Plain Language
- Canary: A recoverable router chosen to represent a defined part of the fleet.
- Binary backup and text export: Two records to preserve and review separately; do not assume either is a universal cross-device restore image.
- Feature coverage: The IPv4/IPv6, VLAN, DNS, wireless-management, container, and script behaviors actually exercised.
Technical Checklist
- Save both a binary backup and a readable text export, and record RouterBOARD firmware, packages, device mode, and storage state.
- Upgrade one recoverable router, then test IPv4, IPv6, DNS-over-HTTPS, bridge VLAN filtering, CAPsMAN, containers, scripts, and exports.
- Compare configuration and effective routing or bridge state before fleet rollout, including defaults introduced by the target release.
- Keep Netinstall or another supported recovery path, local access, and the prior package set available during the canary window.
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 RouterOS and RouterBOARD firmware, installed packages, architecture/model, device mode, storage state, and active features. Protect binary backups and exports off-device. Keep local access, the appropriate prior package set, and a supported recovery method available before beginning.
- 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 upgrade if the device cannot be recovered locally, the package/architecture choice is unclear, or the target lacks a representative test case. Stop fleet expansion on any unexplained export, VLAN, routing, authentication, or container change.
Planned Checks And Recovery
Step 1: Select the canary and baseline
Record the model, role, versions, packages, device mode, storage, and enabled services. Write the expected behavior for each used feature and identify devices that differ from this canary. Capture effective routes and bridge state alongside the saved configuration.
Step 2: Preserve and review recovery inputs
Save both backup types to another protected storage device and verify they are accessible to the recovery operator. Preserve keys/certificates and external application data as applicable. Confirm the model-specific recovery instructions and local access before the maintenance window; this article supplies no verified universal downgrade or Netinstall command.
Step 3: Upgrade only the selected device
Follow the official procedure for the chosen package set and device. Confirm power and free-space prerequisites, then record the installed version after reboot. Compare configuration and effective state before combining the upgrade with unrelated cleanup or policy changes.
Step 4: Exercise every used feature
Run ordinary-client IPv4 and IPv6 transactions, DNS-over-HTTPS resolution, allowed and denied VLAN paths, CAPsMAN-managed client access, container workloads, and relevant scripts. Create and inspect a fresh export. Mark unused features as not applicable, not passed, and keep the failure details for any mismatch.
Step 5: Rehearse recovery and expand by group
Use the supported recovery path on a safe target, compare its restored configuration and client behavior with the baseline, and verify alert delivery. Expand only to the represented device group after the required tests pass. Keep separate canaries for materially different hardware or feature sets.
Validation Checklist
- Off-device binary backup and text export are readable/available, and the intended local recovery path is verified.
- The post-upgrade version, package set, routes, bridge state, and export are compared with the baseline.
- Every used feature has a client/workload result, including a denied VLAN or management-access case.
- Recovery and alerts are tested; unrepresented hardware and feature combinations remain outside the rollout approval.
Troubleshooting
- Only one model fails: Compare architecture, packages, RouterBOARD firmware, device mode, and free storage before broadening the rollout.
- Routing works but VLAN clients fail: Compare effective bridge/VLAN state and permitted paths with the baseline.
- The export changes unexpectedly: Identify each changed/defaulted setting against target release guidance rather than automatically importing an old export.
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
No router was upgraded for this article, and no particular 7.23 point release is declared the current recommended target. One canary cannot establish compatibility for every architecture, wireless stack, container workload, or script. Verify device-specific backup/restore and recovery requirements before relying on the saved files.
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
Group the fleet by the hardware and features the canary actually represents. Keep failed or uncovered cases out of the next rollout group.
