← Back to Recovery methods

Documenting a Multi-Disk System Before Drives Are Removed

Once drives leave their bays, the link between each disk, the place it sat, the role it held and the history behind it can be lost or become harder to establish; some roles can still be recovered from surviving metadata and logs, but physical context often cannot. Recording it first preserves what might otherwise be lost. A usable record captures those facts as separate, sourced fields from what is already safely available, and states openly what is unknown or contradictory, so that the record stays useful whether or not the drives are eventually removed.

What the record has to preserve

A RAID set, NAS pool or storage enclosure depends on more than the data on each disk. It also depends on which disks belong together, in which roles, from which point in time, and on what else is needed to read them: a controller configuration, a pool or volume layout, an encryption key held somewhere else. While the system stays assembled, much of that is implicit in where each disk sits and what the controller remembers. When disks are moved, re-seated, shipped or attached to another machine, that implicit context can be lost or become harder to establish. Some of it may still be recoverable from surviving metadata or logs, but a record made beforehand does not depend on that.

This page is about recording that context, not about whether to remove drives. Documenting is worthwhile even if the drives stay where they are: the same record supports a remote assessment, a later decision to shut down, or a handover to someone else. What the individual metadata fields mean, and how controllers treat foreign or stale members, is covered in RAID Metadata, Member State and Foreign Configurations; here the focus is on assembling those facts into a record that another person can use without guessing.

Collect what is already safely available

Start with information that can be gathered without changing the system: labels on the enclosure, carriers and disks; photographs; screenshots, logs or configuration exports that already exist or that a healthy running system can show without changes; tickets, purchase or replacement records; and the owner’s account of what happened. Record which of these each fact comes from.

A healthy system that is still running and a system that is switched off or unstable are different situations. On a running, stable system, reading an existing status page or exporting an existing configuration may be reasonable within the administrator’s normal authority. On a system that is off, failing or behaving erratically, do not power it on, restart it, re-seat disks or start a consistency check, patrol read or scrub merely to fill in a field. Each of those can change state or stress a weak component. A missing value with a note on why it could not be read is more useful than a value obtained by an intervention nobody had decided on.

Starting a record also does not decide whether the system should be shut down or the drives removed. That decision needs its own assessment of what a shutdown would lose — for example, a running unlocked state or data that only exists in a live copy, as discussed in Live Systems, Snapshots and Consistent Recovery Copies and Remote NAS Recovery vs. Member-Level Reconstruction.

Tie each disk to its physical place

Give the system itself an identifier first: the enclosure or chassis, its model and serial number or asset tag, its location such as rack and shelf, and the date, time and circumstances of the observation (for example, “running, viewed through the management page” or “powered off by the owner before arrival”). If expansion shelves are attached, record each one and how it is connected.

For every bay, record the bay number as marked on the enclosure, and state the numbering convention and the orientation of any photograph, since the same front view can be read left-to-right or right-to-left, top-down or bottom-up. Then record what is in the bay: the carrier and any label on it, and the disk’s model, serial number and, where printed or already shown, its WWN, plus any asset label. Note disk and carrier separately: a disk may have been moved between carriers during earlier troubleshooting, so a carrier label is evidence about the carrier, not necessarily about the disk inside it.

Do not cover, remove or write over original labels. If additional labels are needed, put them on the carrier or a bag, or on an area of the drive housing away from connectors, the circuit board and ventilation openings, and do not use conductive or metallic marking near electronics.

Operating-system device names are observations, not identities. Red Hat’s RHEL 7 storage guide, for instance, explains that Linux /dev/sd names can change if the order of device detection changes, if a disk fails to respond or a host bus adapter fails to initialize, while it describes the World Wide Identifier as a persistent, system-independent identifier for SCSI devices (RHEL 7 Storage Administration Guide, 25.8). Record a device name or controller port as what was shown at a particular time, next to a stable identifier such as the serial number or WWN.

Keep logical role separate from location

Physical bay, controller-reported address, the role a disk’s own metadata records, any role proposed during later analysis, and the disk’s history are different facts. Linux md is a clear example: its documentation describes a member’s slot as the position the device currently fills in the array, or none for a spare or failed device, and lists per-device states such as in_sync, spare, faulty and replacement (Linux md admin guide, sysfs per-device attributes). That position is a logical role inside the array; nothing in it refers to the bay the disk occupies. Hardware controllers and NAS systems keep their own formats, but the same separation applies.

A disk’s role — current member, hot spare, replacement, former member, cache, log, tier or other special-purpose device — cannot be read from its size, model or appearance. If the role has been read from metadata or a controller screen, record that source; if it comes from the owner, record it as the owner’s statement; if it is not known, write “unknown”.

Collect the disks that may matter even if they are not in the enclosure: previously replaced disks, spares on a shelf, a disk taken out during troubleshooting. Describe them as found (“one additional disk was lying next to the server, origin not known”) rather than adding them to the array in the record. Whether a former member is still useful, and why a readable member is not necessarily a current one, is explained in Keep every potentially relevant disk and Storage Metadata Generations and Consistency.

Chronology, configuration and dependencies

Write down the sequence of events as far as it is known: when the first problem appeared, which disks were replaced and when, and whether anything later wrote to the array or changed its definition — a rebuild, an import, a re-initialization, a firmware or software update, a volume expansion. Mark each item as coming from a log, a ticket or the owner’s memory. Log timestamps come from the system’s clock, which may have been wrong or set to a different time zone; record the time zone where known and any observed clock offset. Where a date is not known, leave it unknown rather than estimating it into the record.

Record configuration only as far as needed to understand what depends on what: which RAID sets or pools exist, which volumes or LUNs sit on them, and which hosts or applications use them. A full SAN mapping export is not required in the record itself; reference it as an artifact if it exists. Layering in SAN environments is described in SAN Storage Stack Reconstruction.

Controller cache mode, battery or capacitor status, and any reported cache or pinned-data warnings are worth recording when they are already visible, because they affect whether the newest writes reached the disks. Recording them is not an instruction to change the cache mode or flush anything.

Access dependencies belong in the record as references, not as secrets: whether self-encrypting drives, controller-based encryption or volume encryption are in use, which key-management mode or key server is involved, who is authorized to supply credentials and through which channel. Do not write passphrases, PINs, recovery keys or key material into the record. Encryption-specific detail is covered in Self-Encrypting Drives and Controller Encryption in RAID and NAS and Encryption Key Hierarchies and Recovery Metadata. Logs and configuration exports can themselves contain credentials, addresses or personal data, so check what they contain before attaching them or sending them to anyone.

A blank record and an illustrative example

The record below can be copied into a spreadsheet or text file: one system section, then one entry per disk, with every disk that may be relevant listed, including disks found outside the enclosure. Fields can stay empty or say “unknown”; the record should be saved early and extended later rather than held back until it is complete.

Scroll horizontally to see the full table →

The filled example is illustrative only: the system, serial numbers and history are invented to show how gaps and conflicts are written down, not to describe a real case or a typical outcome. The system section would read: four-bay NAS, asset tag recorded, powered off by the owner before the observation, observed on intake with the owner’s note that the NAS clock had been an hour behind; one additional disk handed over separately.

Scroll horizontally to see the full table →

In the example, every disk’s metadata role is still unknown, and that is acceptable for a first record. The recorded bay positions do not establish member order; when order has to be established later, it comes from metadata and data analysis on images, as discussed in RAID Disks Removed and Their Order Is Unknown and RAID Reconstruction Basics.

Labels, handover and the record’s own limits

Give every disk, carrier and separately supplied item one unambiguous label and use the same identifier in the record. When images, logs or other acquisition artifacts are created later, link them to the disk’s stable identity, such as its serial number or WWN, rather than to a bay number or device name; how source, image and working copies relate is described in Recovery Copies: Source, Image, Working Copy and Destination. At each handover, list which labels were missing or unreadable, which fields are still unknown, and what handling has already taken place, including any power-on or connection attempts.

Pack drives according to the handling requirements in the documentation for those specific drives and enclosures, protecting connectors and other static-sensitive parts. As one vendor example, Western Digital’s packaging instructions for returns ask for each internal drive to be placed in an ESD bag, wrapped in bubble wrap, and packed so that multiple drives do not touch each other or move inside the box (Western Digital Packaging and Shipping Instructions, Packaging steps 1–4); other manufacturers’ requirements may differ.

Keep at least one copy of the record and its artifacts outside the affected storage, so that the record does not depend on the system it describes. A hash can show that a record file or image has not changed since it was hashed; it does not show that the role written in the record was correct, or that an acquisition was complete. When someone else picks up the work, the record tells them what was observed, by whom and from which source — and, just as importantly, what nobody knows yet.

Technical references: Linux md admin guide — per-device slot as array position, none for spare or failed; per-device states · RHEL 7 Storage Administration Guide, 25.8 Persistent Naming — why sd names change; WWID as persistent identifier · Western Digital Packaging and Shipping Instructions — ESD bag and separation for internal drives. The md and RHEL documents describe Linux behaviour; the Western Digital page covers returns of that vendor’s products, and other drives, enclosures and controllers have their own handling requirements.

Related: RAID Metadata, Member State and Foreign Configurations · Self-Encrypting Drives and Controller Encryption in RAID and NAS · Storage Metadata Generations and Consistency · Recovery Copies: Source, Image, Working Copy and Destination · Live Systems, Snapshots and Consistent Recovery Copies · SAN Storage Stack Reconstruction · RAID Disks Removed and Their Order Is Unknown · Drives Unreadable After Removal From a Server or NAS