# Distinguish OpenZFS import discovery from transaction-discarding recovery

> Separate pool discovery from any import option that accepts transaction loss.

- Canonical URL: https://update.dsesecurity.com/updates/distinguish-openzfs-import-discovery-from-transaction-discarding-recovery/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:32:52+00:00
- Modified: 2026-10-15T13:36:15+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Separate pool discovery from any import option that accepts transaction loss.

## Potentially affected

This applies to OpenZFS 2.3 pool import administration. It distinguishes discovery and recovery modes; it is not a recommendation to force an active pool onto another host.

## DSE recommendation

DSE recommends preserving the initial discovery output and selecting the pool by verified identity before any recovery proposal.

## Article

Separate pool discovery from any import option that accepts transaction loss.

## Source facts

OpenZFS 2.3 import can list available pools and their numeric identifiers before importing one. A numeric identifier distinguishes pools that share a name. Its recovery option, uppercase F, is a different action: it attempts to make a non-importable pool usable by discarding recent transactions, whose data is then irretrievably lost. Combining that recovery option with the documented no-operation check evaluates recoverability without performing the recovery. Uppercase N instead imports without mounting filesystems.

Source: [OpenZFS 2.3 — zpool import](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-import.8.html).

## Applicability

This applies to OpenZFS 2.3 pool import administration. It distinguishes discovery and recovery modes; it is not a recommendation to force an active pool onto another host.

## DSE recommendation

DSE recommends preserving the initial discovery output and selecting the pool by verified identity before any recovery proposal. Record whether the intended step is listing, importing without mounts, or accepting a specific data-loss boundary. Have a storage specialist review recovery flags and available copies before modifying an unimportable pool. Keep ordinary troubleshooting instructions free of unexplained force or extreme-recovery options. The operator should be able to describe what the chosen command can change before executing it.

## Verification

Use disposable exported pools, including duplicate names, to verify identification and no-mount handling. Rehearse any transaction-discarding recovery only on an expendable copy with a documented expected loss boundary. Retain command options and resulting status so discovery evidence cannot be confused with a completed repair.

## Official reference

[OpenZFS 2.3 — zpool import](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-import.8.html). Reviewed October 15, 2026.

## Primary reference

- Name: OpenZFS 2.3 — zpool import
- Authority: openzfs.github.io
- URL: https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-import.8.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish OpenZFS import discovery from transaction-discarding recovery,” DSE Security, https://update.dsesecurity.com/updates/distinguish-openzfs-import-discovery-from-transaction-discarding-recovery/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.