Arista EOS Factory Recovery for ITAD: startup-config Wipe vs fullrecover
Short answer
For an owner-authorized Arista switch, use a startup-config wipe when the goal is to remove configuration while preserving a known-good EOS image and the work order does not require flash recovery. Use Aboot fullrecover only when the approved disposition requires a factory-default flash state or the internal flash/image state itself needs recovery.
Full recovery is not a stronger spelling of a configuration reset. It is a destructive flash operation. It can remove configuration files, EOS image files, and user files before restoring the applicable factory-default flash contents. Decide the scope before entering Aboot, preserve only the approved evidence, and verify Zero Touch Provisioning after recovery so prior automation does not reappear.
Scope: This guide is for equipment your organization owns or is explicitly authorized to process. Do not use recovery procedures to defeat access controls or claim ownership. If authorization, Aboot access, image provenance, or data-retention requirements are unclear, stop and escalate.
Choose the reset scope first
| Need | Preferred path | What to verify afterward |
|---|---|---|
| Remove customer configuration; current EOS image is healthy | Release-supported configuration wipe | No prior startup configuration, normal boot, expected image remains |
| Restore factory-default flash state or repair a damaged flash/image layout | Aboot fullrecover | Factory files restored, boot image is valid, clean boot, ZTP outcome is controlled |
| Image or storage condition is unknown | Pause for evidence and engineering review | Do not erase the only diagnostic or recovery path |
| Ownership or retention policy requires preservation | Capture approved evidence before any destructive step | Evidence stored privately and linked to the work order |
A configuration wipe is usually the lowest-impact resale path. Full recovery is appropriate when its additional erase scope is necessary and understood.
Preflight checklist
- Match the switch to an owner-approved work order.
- Disconnect production and customer network paths.
- Start a timestamped console transcript.
- Record model family, installed EOS train, active image, and current boot result internally.
- Record flash contents and boot configuration before changing them.
- Identify whether a configuration-only reset will meet the work order.
- If full recovery is required, confirm the available factory or approved recovery image path before erasing flash.
- Confirm console access and stable power through the entire operation.
- Plan the post-recovery Zero Touch Provisioning decision before reconnecting any network cable.
- Keep raw configuration, serials, MAC addresses, addresses, credentials, certificates, and customer topology out of public records.
Useful non-destructive checks vary by EOS release, but a typical internal evidence set includes:
show version
dir flash:
show reload cause
In Aboot, inspect storage before destructive recovery:
ls /mnt/flash
ls /mnt/usb1
Use the exact path and image name expected by the running Aboot context. Do not infer an image is usable merely because a file extension looks familiar.
Configuration wipe: when the image is already healthy
Use the release-supported configuration-reset procedure when all of the following are true:
- the switch boots a known-good EOS image;
- flash health does not require repair;
- the work order asks for prior-owner configuration removal, not factory flash reconstruction;
- the required evidence is preserved; and
- the owner-approved procedure covers the actual model and EOS release.
After a configuration-only reset, verify that the old startup configuration, automation settings, local users, routing state, VLAN details, and management settings do not remain. Also verify that the expected EOS image still boots normally. A successful prompt is not enough evidence for resale.
Aboot fullrecover: full flash recovery path
Enter Aboot only from an authorized console session. The timing and entry prompt depend on the platform. Once at the Aboot prompt, full recovery uses:
fullrecover
The operation displays an erase warning and requires an explicit confirmation. Read the warning before confirming: it applies to the internal flash, not only the configuration file.
After confirmation, Aboot recreates factory-default flash content appropriate to its recovery context. A healthy completion still needs post-recovery checks. Some hardware and software combinations may not retain a backup EOS image in the factory partition, and an approved current image may need to be available separately.
Image prerequisite gate
Do not call a missing-image error a reset success. If Aboot reports that no EOS image is available from its recovery source, pause the workflow. Verify the exact file name, placement, model compatibility, signature requirements, and approved source before retrying.
Field note: In a sanitized owner-provided Aboot recovery session on an Arista DCS-7050QX-32-F family switch, fullrecover displayed the expected internal-flash erase warning. A later attempt reported that no EOS image was available from the recovery partition or mounted USB path. Supplying the approved image under the required recovery name was a prerequisite for continuing. The practical rule is simple: an erase prompt proves only that the destructive branch started; valid recovery media and a normal boot prove the result.
Zero Touch Provisioning must be a deliberate choice
A clean flash does not guarantee a quiet bench boot. After recovery, the switch can enter Zero Touch Provisioning and request a startup configuration or boot script from the attached network.
Keep the device isolated until the intended state is clear. If the release-supported workflow requires disabling ZTP for resale preparation, use the documented command:
zerotouch disable
This action can reload the switch. Capture the reload and post-boot state. Do not attach the device to a customer network merely to see whether ZTP succeeds. An isolated bench network is acceptable only when the approved test requires it.
Post-recovery verification
| Check | Pass signal | Fail or escalation signal |
|---|---|---|
| Flash state | Expected factory or approved recovery files are present | Missing image, unexpected files, or storage errors |
| Boot | EOS reaches a normal prompt on the intended image | Boot loop, Aboot return, signature failure, or missing image |
| Configuration | Prior-owner configuration is absent | Old startup configuration or automation settings remain |
| ZTP | Explicitly disabled or handled according to the work order | Device waits for or accepts unknown network automation |
| Evidence | Transcript shows decision, confirmation, and result | Only the erase command was captured |
Record the reset scope, recovery-image decision, final boot image, ZTP state, and pass/fail outcome in the internal asset record. Do not publish raw Aboot output or any file paths, IP addresses, keys, certificates, serials, or customer configuration.
CliDeck workflow
CliDeck can keep the scope decision reviewable:
- Start with a scan and owner-approved work order.
- Capture version, flash, boot, and exception evidence before destructive actions.
- Require the operator to choose configuration wipe or full flash recovery explicitly.
- Gate fullrecover on confirmed image availability and power stability.
- Preserve the console transcript through erase, recovery, and reboot.
- Require a separate ZTP verification step before network connection.
- Attach only sanitized pass/fail evidence to the resale record.
For complementary pre-wipe and version-gate patterns, see the Dell OS10 support-bundle workflow and the Ruckus ICX reset checklist.
Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.
Who this is for
This guide is for ITAD teams, refurbishment teams, network engineers, and operations teams who need to perform an owner-authorized reset, recovery, verification, or documented device-processing workflow on network devices that your team owns or is authorized to process.
When to use this
Use this guide when:
- Your team owns or is authorized to process the device.
- You need to reset, zeroize, recover, reimage, verify, or document a network device.
- The result must be attached to an asset, resale, reuse, refurbishment, or recycling workflow.
When not to use this
Do not use this guide when:
- You do not own or have authorization to work on the device.
- The device is outside your approved change, recovery, or processing scope.
- The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
- You need a certified data destruction procedure and your organization has not provided one.
Quick decision table
| Situation | Better fit | Why |
|---|---|---|
| One authorized engineer needs a quick low-risk task | Factory reset or simpler reset path | It keeps the workflow simple when no shared context, batch work, or durable evidence is required. |
| The work needs verification, handoff, or documentation | Zeroize, reimage, or documented processing workflow | It creates a clearer path for notes, logs, stop conditions, and final checks. |
| Multiple people or devices are involved | Zeroize, reimage, or documented processing workflow | Structured workflows reduce ambiguity and make it easier to prove what happened. |
When option A is enough
The simpler option is usually enough when one authorized engineer is doing a low-risk task locally, the device state is known, and the work does not require shared context, batch processing, or durable evidence.
When option B is better
The more structured option is better when the work needs repeatability, collaboration, verification, logging, asset linkage, or a safer handoff between people or teams.
Workflow
- Confirm ownership, processing scope, device identity, and approved procedure.
- Connect through the console or approved management path and capture the session context.
- Run the reset, zeroize, recovery, reimage, or verification steps required by the article and vendor documentation.
- Reboot or reconnect as needed and verify the expected clean, default, or recovered state.
- Attach logs, verification output, exceptions, and final pass/fail/exception status to the asset record.
Verification checklist
- Device identity matches the asset record.
- Console or session log is attached to the asset.
- The reset, zeroize, recovery, or reimage method is recorded.
- The post-reboot state matches the expected clean or recovered state.
- Verification commands and outputs are captured.
- Exceptions or failures are quarantined instead of marked ready.
Resale and evidence checklist
Before marking the device ready for resale, capture:
- Device model and serial number
- Console transcript or session log
- Reset, zeroize, reimage, or recovery method used
- Any confirmation prompts and operator decisions
- Post-reboot state
- Visible default or clean-state prompt
- Verification commands and outputs
- Hardware alarms or boot errors
- License, entitlement, or customer identifiers handled according to policy
- Exceptions, failures, or quarantine decisions
- Final pass/fail/exception status attached to the asset record
What not to publish
Do not publish raw transcripts that include customer names, public IP addresses, VPN settings, license keys, entitlement IDs, serial numbers that must remain private, passwords, tokens, certificates, or other sensitive identifiers. Keep sensitive evidence in the customer-approved internal system and publish only sanitized examples.
Common mistakes
- Processing a device without owner authorization or the correct asset record.
- Treating a factory reset as certified data destruction.
- Failing to capture confirmation prompts, reboot state, verification output, or exceptions.
- Publishing raw logs that contain customer identifiers, licenses, keys, passwords, or configuration remnants.
CliDeck workflow fit
CliDeck can help turn this procedure into a repeatable workflow. Console Server Go is useful for portable rack-side console access and shared remote support. Net Controller is better for ITAD, refurbishment, and batch processing where multiple devices need barcode tracking, approved scripts, logs, API updates, and evidence-style results.
Net Controller can help operators connect devices, scan assets, run approved workflows, capture console logs, require verification steps, and attach the result to the asset record.
FAQ
Is this a certified data destruction procedure?
No. This article describes a practical, owner-authorized workflow and verification approach. Certification depends on your organization’s process, evidence requirements, customer contract, and any formal certification program that applies.
Does CliDeck provide vendor OS images?
No. CliDeck does not distribute vendor operating system images. Recovery or reimage workflows can use images already present on the device or images provided by the customer where the customer has appropriate rights and licenses.
Should I publish the full console log?
Usually no. Keep complete evidence in the approved internal system and publish only sanitized examples. Console logs can contain serial numbers, license details, customer names, IP addresses, keys, passwords, or configuration remnants.
Can CliDeck help with this workflow?
Yes. Console Server Go helps with portable rack-side console access and shared remote support. Net Controller is better for batch ITAD, refurbishment, recovery, provisioning, barcode/API tracking, and evidence-style results.
Related guides
- NIST SP 800-88 Rev. 2: A Defensible Media Sanitization Process - Build an asset-level sanitization workflow with method selection, execution evidence, verification, validation and clear exception handling.
- Aruba Instant AP Factory Reset: Isolate the Device and Verify the Fresh Baseline - For an owned Aruba Instant AOS-8 access point, use the supported factory-reset procedure for the exact model and software.
- Palo Alto ZTP After Factory Reset: Keep Refurbishment on a Controlled Bench - After resetting an owned Palo Alto firewall, inspect its Zero Touch Provisioning state before connecting it to an unrestricted uplink.
- Cisco IOS XE Smart Licensing at Decommission: A Separate Checklist from Factory Reset - Before decommissioning an owned IOS XE device, identify its licensing model and coordinate license handling with the authorized Smart Account administrator.
- FortiGate USB Auto-Install Before Resale: Prevent Old Configuration from Returning - Remove unreviewed USB media before resetting an owned FortiGate and inspect USB auto-install settings on supported models.