How to Factory Reset an ASIC Miner: Back Up, Reset, and Verify Recovery

Factory-reset an ASIC miner only after saving the current logs, firmware identity, network settings, pool URLs, worker names, and a known-good baseline. Use the exact procedure for the manufacturer, model, control board, and firmware; a reboot, factory reset, and recovery flash are different actions. After the reset, change credentials, restore configuration manually, and prove sustained accepted work and failover before returning the miner to unattended service.

Choose the smallest recovery action that fits the fault

A factory reset returns settings or software state toward the manufacturer's default. It is disruptive because it can remove the configuration that made the miner reachable and productive. It also cannot repair a failed fan, damaged connector, unstable power source, bad hashboard, or other physical fault.

Start with the symptom and the evidence you already have. Do not reset merely because the dashboard contains an unfamiliar warning.

Situation	Best next action	Why	Stop condition
The interface is responsive and one setting was entered incorrectly	Correct that setting or restore a known-good configuration	Preserves logs and unrelated settings	You cannot identify what changed
The miner is responsive but a service is stuck	Use the documented reboot or service restart	Tests whether a clean restart resolves a temporary state	The same fault returns after a controlled restart
Settings are corrupted, ownership is changing, or the vendor directs a reset	Use the exact factory-reset procedure for that model	Returns configuration toward a known baseline	The procedure, control board, or current firmware cannot be confirmed
An upgrade failed or the control system will not boot	Use only the manufacturer's matching recovery or reflash procedure	A normal reset may not replace a damaged system image	The recovery image, signature, board revision, or instructions are uncertain
Burn smell, damaged connectors, liquid, repeated protection trips, or unsafe power behavior	Power down safely and arrange qualified inspection	A software reset cannot remove an electrical or mechanical hazard	Do not energize the unit to collect more evidence

If the miner is reachable, preserve the failure before erasing it. The site's kernel log capture guide explains how to keep the complete event window, model and firmware identity, timestamps, and surrounding symptoms. A screenshot of one error line is rarely enough to compare the state before and after a reset.

Build a recovery packet before you press anything

The goal is not to save every screen. The goal is to retain what you need to identify the device, reach it again, restore intended work, and show whether the reset changed the fault.

Field	Record before reset	Why it matters afterward
Hardware identity	Manufacturer, exact model, serial or asset label, control-board revision if known	Prevents use of instructions or firmware for a different unit
Software identity	Firmware name, version, source URL, and last change	Establishes what was running when the fault occurred
Network	DHCP or static assignment, address, subnet, gateway, DNS, VLAN or switch port	Lets you find the miner and restore an approved network position
Pool configuration	Primary and backup URLs, ports, account or wallet format, worker name, priority	Restores the intended destination and failover order
Access controls	Current administrator account policy and who owns the device	Ensures the reset does not leave known default access in service
Operating baseline	Averaged local hashrate, pool-side accepted work, reject/stale counters, temperatures, fans, power mode	Gives the post-reset state something comparable to beat or match
Fault evidence	Full current/history logs, visible symptom, start time, recent changes	Shows whether the original failure actually stopped recurring
Recovery resources	Current official manual, matching firmware or recovery package, local access path	Prevents an improvised recovery after the reset changes reachability

Store secrets securely rather than pasting them into an ordinary worksheet. A record should identify which credential or wallet belongs to the miner without exposing the secret itself.

Export the configuration when the manufacturer's interface supports it, but also record critical values in a readable form. An exported backup can be incompatible with a different firmware release or can reintroduce the setting that caused the problem. Plan to review each restored value instead of assuming a bulk import is safe.

Manufacturer buttons do not share one universal sequence

The labels may look similar while the required timing, boot state, indicator pattern, and result differ. Use the current manual or support page for the exact unit in front of you.

Bitmain's factory-reset support page illustrates the problem with a universal instruction. It documents a reset-button method inside a boot-time window, web-interface methods for named product generations, and an IP Reporter method limited to specific older models. It also lists an exception for certain hardware layouts and says the reset returns the miner to its original firmware. Those details make model identification a gate, not a formality.

WhatsMiner's current factory-reset FAQ confirms a long press of the RESET button as a recovery route, but the short page does not provide one duration and model matrix for every device. That is a reason to consult the matching operation guide, not permission to borrow another vendor's timing.

Canaan publishes a different Avalon factory-reset sequence: start from power off, hold FUNC while powering on, wait for the indicator to flash for about 10 seconds, release FUNC, and then press RST. The sequence is useful for the covered Avalon workflow and should not be transferred to an Antminer or WhatsMiner.

Before acting, complete this short gate:

• The manufacturer and exact model match the page or manual.
• Any control-board or hardware-layout condition is satisfied.
• The miner is in the required powered-on, boot-window, or powered-off state.
• You know what the documented success indicator looks like.
• You know how the network address will be rediscovered.
• You have a separate recovery route if the ordinary reset does not restore access.

If any item is unknown, stop and obtain the matching documentation. Repeatedly pressing controls or interrupting power adds state changes without adding evidence.

Restore access and security before pool work

Keep the miner on a controlled local network during recovery. Discover its address with the manufacturer-approved method and confirm that the interface identifies the expected serial, model, and firmware. If the device appears under an unexpected address, update inventory and network reservations rather than leaving two records for one machine.

Change or confirm the administrator credential before exposing management access beyond the recovery segment. Do not assume that an old password survived, and do not assume that a manufacturer's default is unique. Reapply only the access services your operation needs. Remote management, APIs, and fleet tools should remain disabled until ownership and authentication are established.

Check the firmware identity shown after reset against the model's current official support material. A factory reset and a firmware recovery are different operations: if the vendor directs an update after reset, use the exact signed or officially distributed package for the device and follow its power and reboot instructions. Do not substitute a similarly named model or control-board image.

Restore mining settings one layer at a time

Rebuild the network, time, pool, worker, and operating mode in a sequence you can test. Restoring everything at once makes a repeated fault difficult to isolate.

1. Confirm local reachability and stable access to the miner interface.
2. Set the approved network and time configuration, then verify it survives one normal reboot.
3. Add only the primary pool and a clearly named worker. Confirm the pool shows that exact worker.
4. Let the miner complete its documented initialization or tuning process without repeatedly rebooting it.
5. Add the backup destinations in the intended priority order.
6. Restore power targets or other operating modes only after stock or baseline behavior is stable.
7. Reconnect monitoring and management tools last, then confirm that their labels point to the correct asset.

Use the pool settings and failover guide to verify URL, port, worker identity, and backup order. A miner can look healthy locally while sending work to the wrong account or sitting on an invalid endpoint.

Avoid restoring a stale configuration blindly. Review old DNS, gateway, wallet, pool, firmware, and tuning values against the current approved setup. A reset is an opportunity to remove an unknown change only if you do not immediately import that change again.

Prove recovery with independent observations

A reachable web interface proves that the control system booted. Spinning fans prove that fans received power. Neither proves that the pool accepted useful work.

Compare the recovered miner with the baseline over a consistent observation window:

Acceptance check	Evidence to collect	Pass condition
Device identity	Serial or asset label, model, firmware, network record	The intended physical unit matches inventory
Local initialization	Board/chip detection, stable averaged hashrate, fans, temperatures, power mode	Values stabilize within the model's documented behavior
Pool identity	Pool dashboard worker name and account or wallet destination	The expected worker appears under the intended owner
Accepted work	Pool-side accepted hashrate or difficulty-weighted shares over a consistent window	Useful work continues rather than only a connection appearing
Rejects and reconnects	Miner and pool counters plus logs for the same window	No recurring fault that motivated the reset
Persistence	One controlled normal reboot	Network and pool configuration return correctly
Failover	Attended primary-to-backup test and restoration	Backup credits the intended worker and recovery follows the documented order
Security	Credential, exposed services, management access, inventory	No default or unknown access remains in production

Do not demand that a short pool-side estimate exactly match the miner's displayed hashrate. Pools estimate work from submitted shares, so short windows vary. The useful test is sustained accepted work, correct attribution, and a stable trend over a window appropriate for the pool's reporting method.

Keep the recovery attended until the miner has survived a normal reboot and a real failover test. If local hashing resumes but the pool sees nothing, verify identity and endpoint settings before resetting again. If the original log pattern returns under the same external conditions, the reset did not establish a software cause.

When a reset does not solve the problem

One controlled reset is an experiment. Repeating the same reset without a changed hypothesis is not troubleshooting.

If the miner remains unreachable, use the exact manufacturer's recovery path only when the image, hardware revision, preparation method, and success indicators all match. If the interface returns but a board, fan, sensor, or power fault repeats, preserve the new logs and compare them with the pre-reset record. That before-and-after pair is more useful to support than another erased failure window.

Stop when the next step requires opening energized equipment, bypassing protection, probing a power supply, moving internal parts without a service procedure, or risking warranty evidence. A factory reset can narrow a diagnosis by removing configuration state; it cannot make an unsafe hardware symptom safe.

What should a future-proof reset process preserve?

The unresolved problem is fleet portability. Manufacturers differ in reset controls, backup formats, firmware recovery, credential behavior, and the evidence their tools export. Even within one brand, control-board and firmware changes can alter the sequence.

Operators can reduce that dependence by keeping a vendor-neutral asset record: physical identity, approved firmware source, network assignment, pool ownership, worker naming, baseline measurements, and links to the exact recovery documents. The open question is how much of that record future management tools can validate automatically without storing secrets or restoring stale settings.

Review the recovery packet whenever hardware ownership, firmware, network design, or pool identity changes. A reset plan is reliable only while it still matches the machine and environment that will use it.

Frequently asked questions

Does a factory reset repair a failed hashboard or power supply?

No. A factory reset changes configuration or software state; it does not repair burned connectors, failed fans, damaged chips, unstable input power, liquid damage, or other physical faults. It can help test whether an unexplained software or configuration state caused the symptom. If the same board, fan, sensor, or power error returns after one controlled reset under verified external conditions, preserve the new logs and move to the manufacturer's diagnostic or repair process.

Is rebooting an ASIC miner the same as factory-resetting it?

No. A reboot restarts the current software with its existing configuration. A factory reset returns settings or system state toward the manufacturer's defaults and may change how you reach, authenticate to, and configure the miner. A recovery flash replaces or restores a system image and has additional model and control-board requirements. Choose the least disruptive action that matches the evidence, and record the current state before any step that may erase it.

What should I save before resetting an ASIC miner?

Save the exact model, serial or asset label, firmware name and version, network assignment, pool URLs, worker identity, backup order, operating mode, and a stable local and pool-side baseline. Export complete current and relevant historical logs before they can be replaced. Keep credentials in an approved secret store rather than the worksheet. Also save the current official manual and matching recovery package location so a loss of web access does not leave you guessing.

Can I use one manufacturer's reset-button timing on another miner?

No. Official examples differ in boot state, button name, press duration, indicator behavior, and follow-up action. Differences can also exist within one manufacturer's product families and control boards. Match the current documentation to the manufacturer, exact model, and hardware revision before touching the controls. If the page does not clearly cover the unit, stop and obtain the model manual or vendor guidance instead of adapting a sequence that merely looks similar.

How do I know the miner is fully recovered after a reset?

Confirm more than dashboard access. The physical identity and firmware must match inventory; network and time settings must persist through a normal reboot; all expected boards and fans must stabilize; and the intended pool account must show the exact worker receiving sustained accepted work. Test the configured backup while attended, then confirm the primary route recovers as designed. Review new logs for the original recurring fault before returning the miner to unattended operation.

Should I import my old configuration immediately after the reset?

Usually, restore critical settings in reviewed layers rather than importing everything immediately. A bulk backup may contain the bad setting that motivated the reset, an old pool or wallet, a stale network address, or values that do not fit the current firmware. Establish local access, security, network, time, and one primary worker first. Add failover, tuning, monitoring, and fleet tools only after each earlier layer works and the pool confirms correct accepted work.