ADR technical library

Technical notes for understanding a failed storage or database system.

These notes explain specific RAID, controller, database, and application-storage behaviors. Use them to identify the mechanism behind a warning or failure—not as permission to rebuild, initialize, force online, rewrite parity, or repair the only remaining source.

Choose a technical-note group Choose a failure symptom

A warning or technical question is not automatically a recovery emergency. The boundary changes when required data is inaccessible, an attempted intervention has failed, or the next write may reduce the remaining recovery options.

Choose the system or failure layer

One library, organized by the evidence you are evaluating.

The RAID 5 and RAID 6 collections have dedicated indexes. The remaining notes address nested arrays, controller behavior, SQL damage, and healthcare application storage.

Eight notesRAID 5 failure and rebuild behaviorParity confidence, latent read errors, drive order, controller automation, repeated rebuilds, and protected reconstruction.Open the RAID 5 notes → Seven notesRAID 6 parity, metadata, and rebuild behaviorDual-parity confidence, member identity, recreation, latent errors, repeated rebuilds, and protected reconstruction.Open the RAID 6 notes → Two notesNested RAID 50 and RAID 60 structuresUnderstand lower-group dependencies before treating the combined virtual disk as one flat array.Review the nested-array notes → Controller referenceController behavior and automationIdentify automatic controller actions that can change member state after a failure or configuration event.Review the controller note → Database layerSQL rebuild damage and file-level evidenceSeparate an accessible file from a consistent, mountable database and preserve both MDF and transaction-log evidence.Review the SQL notes → Six notesHealthcare and dental application storageDistinguish server, RAID, repository, and database failure when patient records or images become unavailable.Review the healthcare notes →

Nested arrays

Evaluate each lower group before reconstructing the upper stripe.

RAID 50 and RAID 60 depend on the condition and geometry of their component groups as well as the relationship joining those groups.

TN-R50-001RAID 50 layout, group dependency, and reconstructionReview the lower RAID 5 groups, upper stripe, member order, and metadata as separate evidence layers.Read the RAID 50 note → TN-R60-001RAID 60 layout, group dependency, and reconstructionEvaluate each lower RAID 6 group before determining how the upper stripe can be assembled.Read the RAID 60 note →

Controller behavior

Understand what controller automation may already have changed.

A controller can write metadata, accept a foreign state, start a rebuild, exclude a member, or present a different virtual disk before the administrator understands the original failure.

TN-C1-001Controller automation after a RAID failureIdentify automatic actions, preserve controller evidence, and determine when another operation would be unsafe.Read the controller note → Platform pathsDell PERC, HPE Smart Array, MegaRAID, QNAP, Synology, and TrueNASChoose the controller or storage platform and then the exact condition it is reporting.Open controller and system triage →

SQL evidence

Recovering database files is not the same as returning a working database.

These notes address damage introduced by array intervention and the different evidence carried by the primary data file and transaction log.

TN-SQL-002Why a RAID rebuild can damage recoverable SQL dataUnderstand how write-based reconstruction can turn storage inconsistency into database-page damage.Read the rebuild-damage note → TN-SQL-004Transaction-log damage compared with MDF damageDetermine which database structures are affected before choosing repair, extraction, or reconstruction.Read the SQL file-damage note → Recovery pathsSQL database recovery after RAID or storage failureChoose the condition that matches the database state, including Recovery Pending, Suspect, missing files, and failed attach.Open SQL recovery paths →

Healthcare and dental systems

Locate the failure layer behind inaccessible records, images, or schedules.

The application may be unavailable because of its server, RAID, database, image repository, or an intervention that changed the source. These notes keep those layers distinct.

TN-HC-001Why patient records become inaccessible after RAID failureFollow the dependency from storage members through the volume, database, repository, and application.Read the record-access note → TN-HC-002Healthcare SQL corruption compared with storage corruptionSeparate damage within database structures from corruption introduced below the database layer.Read the corruption note → TN-HC-003Why rebuild attempts can worsen healthcare recoveryRecognize when a write intended to restore service may alter the best remaining source state.Read the rebuild note → TN-HC-004EMR database failure compared with server failureDetermine whether the application host, database service, or data repository is actually unavailable.Read the EMR failure-layer note → TN-HC-005Why inaccessible patient records may still be recoverableDistinguish failure of the normal access path from loss of the underlying record data.Read the recoverability note → TN-HC-006Healthcare recovery while drives remain onsiteUnderstand the controlled client-custody path when policy or risk makes shipment undesirable.Read the onsite-custody note →

The recovery boundary

When the question is no longer “what does this mean?”

If required data is inaccessible, a rebuild or repair has failed, multiple members are unavailable, or the next operation may overwrite evidence, move from technical explanation to the recovery path that names the actual failure.

RAID crisis pathsChoose what failed and what is now inaccessibleUse the operational consequence—not merely the RAID level—to choose the recovery path.Open the RAID failure center → Database crisis pathsChoose the SQL state that normal administration cannot resolve safelyRecovery Pending, Suspect, failed attach, missing files, and structural corruption require different evidence.Open SQL recovery paths → Healthcare crisis pathsChoose what the practice or care team can no longer accessRoute from inaccessible records, images, schedules, or databases to the correct recovery condition.Open healthcare recovery paths →

Required data is inaccessible now?

Tell ADR what failed and what has already been attempted.

Include the system or controller model, member count and sizes, current messages, original order if known, replacements or rebuild history, and the business data that must be recovered first.

Call 1-800-228-8800 Start emergency triage