Synology cache failure

A missing Synology write cache may contain newer blocks than the storage pool.

Synology SSD cache can be read-only or read-write depending on configuration and DSM generation. A failed read cache is mainly an availability issue, while a failed write cache can involve acknowledged data not yet committed to the backing pool.

Understand the symptom

Cache mode determines whether missing SSDs can change the authoritative block state.

WHY

What is happening

Read-only cache can be repopulated from the pool, but read-write cache may hold dirty blocks and uses redundancy to protect them. After power loss or member failure, cache metadata and the backing filesystem may represent different transaction points.

What you may see

Symptoms that change the recovery path.

01

SSD cache shows degraded or crashed

One or more cache members are absent, failing, or not assembling.

02

Volume becomes read-only

DSM restricts writes because cache or storage state cannot be trusted.

03

Packages or VMs fail after outage

Recent writes may not be fully represented on the backing pool.

04

Cache removal option warns of risk

DSM recognizes dependencies or an incomplete cache state.

Protect the source

Actions that can make the situation worse.

01

Removal can discard dirty writes

Write-cache data may not yet exist on the storage pool.

02

Recreation overwrites cache metadata

New setup can erase evidence needed to map prior cache state.

03

Application restarts create divergence

Databases and VMs can issue new writes as soon as the volume returns.

Do this now

Safe steps before evaluation.

01

Stop clients and packages

Pause VMs, containers, databases, sync, backups, and shared-folder access.

02

Export DSM evidence

Save cache mode, RAID type, dirty state, pool status, SMART data, and event logs.

03

Label cache and pool members

Record serials, bays, removal history, and which SSD failed first.

04

Preserve the complete system

Keep chassis, boot media, cache SSDs, pool disks, and power components together.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Cache-mode review

NEPFOSYS identifies read-only versus write-back behavior and member chronology.

02

Layered acquisition

Cache and backing members are preserved before detach, repair, or pool assembly.

03

Consistent-state validation

Candidate views are tested against Btrfs or ext4, databases, VMs, and priority files.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Is a failed read-only cache likely to contain unique data?

Normally it mirrors data from the pool, but the pool and exact DSM state still require evaluation.

Can I click Remove SSD Cache?

Not until cache mode, dirty state, member health, and preservation options are understood.

Should I replace the missing SSD?

Preserve all originals first; a rebuild or recreation changes cache state.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case