The RAID Failed, the ERP System Is Down, and the Business Cannot Reach Its Operational Records
This is no longer merely a server outage when accounting cannot post, inventory cannot be trusted, orders cannot move, production cannot schedule, or the warehouse cannot see current records. The ERP database and the storage state that contains it must be protected before another attempt to restore service.
Stop rebuilds, restores, controller changes, database repair, and writes to the affected storage. Preserve every RAID member, VM or volume state, database file, backup, log, and event record.
Tell an ADR technician what the system reports and what has already been attempted. The failed system does not have to be brought online first.
What this condition means
An ERP outage may cross several layers at once: RAID, filesystem, virtual machine, SQL database, transaction log, and the ERP application itself. A database error does not prove that the problem begins or ends in SQL.
The safest recovery order is to establish a coherent storage source first, then evaluate the database and the business records it contains. Repairing a higher layer while the RAID is uncertain can convert a recoverable inconsistency into permanent loss.
What to record
- ERP product, version, database platform, and application architecture
- Business functions stopped and the tables, records, dates, companies, or locations needed first
- Server, controller, RAID level, member count, VM or volume layout, and current drive status
- Exact controller, operating-system, virtualization, database, and application errors
- Locations, versions, sizes, and timestamps of database, transaction-log, backup, and application files
- Every rebuild, repair, restore, controller, drive, VM, or power action already attempted
What not to do
- Restart or repeat a RAID rebuild
- Run database repair with data loss on the only copy
- Import, clear, or recreate controller configuration by trial and error
- Restore onto the affected array as a test
- Write recovered files back to the source storage
How ADR evaluates it
ADR first determines whether the member set can produce a stable, defensible logical volume. Unstable members are protected before the RAID is reconstructed and the filesystem or virtual disk is evaluated.
The ERP database is then examined from protected copies. Candidate results are tested against the companies, tables, dates, relationships, and records required for current operations—not merely whether the application or database starts.
ADR can begin with the storage evidence, member drives, virtual disks or volumes, database files, and error history. The failed server can remain offline while the RAID and database are evaluated in a controlled recovery environment and the business prepares replacement infrastructure.
What happens next
ERP data often remains recoverable even when the array, virtual machine, or database will not start normally. The practical result depends on readable member coverage, prior writes, database consistency, and the evidence preserved before further intervention.