Storage recovery: SAN, NAS and RAID

Related links

Storage recovery is the set of procedures used to restore access to data when a ZFS pool, a SAN/NAS volume, or a RAID array fails to mount, becomes degraded, or shows corruption. In practice, it starts by stopping writes to the equipment, preserving the current state, and working on copies — never on the original disks.

When recovery is urgent

Some signs point to storage rather than the application:

• the ZFS pool does not import or shows UNAVAIL/FAULTED;
• the volume does not mount after a power loss, upgrade, or controller swap;
• RAID goes DEGRADED and replacing the disk does not finish the rebuild;
• the filesystem reports corruption, I/O errors, or metadata loss;
• the NAS answers on the network but shares disappear;
• more than one disk in the same array may have failed.

In any of these cases, the first step is to stop operation and avoid rebooting into automatic repair mode. Rebuilds, fsck, and “repair” without diagnosis can turn a recoverable incident into permanent loss.

What Nyverra does

The scope is to restore access to the data and return the environment to a documented operational state:

• Remote triage — logs, zpool status, smartctl, controller events, and array topology.
• Preservation — guidance to power off and, when possible, clone disks or the volume before any intervention.
• Failure analysis — separate logical failure (metadata, filesystem, configuration) from physical failure (disk, controller, cabling, backplane).
• Controlled rebuild — read-only pool import, volume mount, RAID rebuild, or file recovery by priority.
• Validation — integrity checks, read tests, copy to a healthy target, and documentation of what was recovered.

Every decision and disk state is recorded. For sensitive data (healthcare, financial, legal), handling follows the contract and the LGPD.

What is out of scope

• Physical recovery of damaged media (clicking disk, scratched platter, burnt PCB) requires a clean room and a specialized lab. Nyverra performs triage and, when needed, refers the case to a physical recovery partner.
• A guarantee of full recovery. No serious provider guarantees 100% of the data before diagnosis. The commitment is to method, preservation, and transparency about what can be recovered.
• Support for closed proprietary firmware on legacy storage without vendor documentation. These cases are assessed individually.

TrueNAS and ZFS: why treatment differs

ZFS is not “RAID by another name”. A pool combines vdevs, and integrity depends on distributed metadata and checksums. A forced zpool import, a version change, or a zpool clear at the wrong moment can make the failure worse.

• Snapshots are not backups when they live in the same pool: pool failure takes the snapshots with it.
• RAID-Z is not a backup: it protects against disk failure, not deletion, logical corruption, or ransomware.
• The controller matters: an IT-mode HBA is the standard for ZFS; hardware RAID hides disks and changes topology.
• Record the state before acting: zpool status -v, zdb, SMART, and logs must be preserved before any attempt.

SAN, NAS, and DAS: differences that change the diagnosis

RAID is not backup — and that changes priorities

If the environment still lacks a tested, immutable copy, recovery solves the current incident, but the next one remains exposed.

Prevention: avoiding the next incident

• Monitor SMART, zpool status, capacity, and latency before the limit.
• Test restores regularly — an untested backup is a hypothesis, not a guarantee.
• Separate snapshots from backups and keep at least one immutable/offline copy.
• Document topology, versions, and the disk replacement procedure.
• Use an IT-mode HBA with ZFS and keep firmware/hardware compatibility recorded.
• Define RPO and RTO per system, not one generic number for the whole company.