A power outage rarely lasts more than a few seconds. That is still enough to render a RAID volume unreadable or corrupt an entire file system on a server or NAS. Contrary to popular belief, the risk does not come from the loss of power itself, but from the abrupt interruption of writes in progress across several layers of volatile memory: the RAID controller cache, system RAM, and the drive’s own cache. Here is what actually happens during those few seconds, and how to reduce the risk before it happens.
What actually happens during a sudden power loss
A running server never writes directly to disk on every operation. Data passes through several buffer layers before it is physically committed: the RAID controller cache, system memory, then the drive’s own internal cache. This architecture significantly improves performance, but it comes at a cost during an outage: anything not yet written to physical media is lost, and the file system is left in an inconsistent state, known as a dirty shutdown.
Modern file systems such as ext4, Btrfs, and ZFS include protection mechanisms (journaling, copy-on-write) designed precisely for this scenario. These protections do have limits, though, particularly when the outage hits during a period of heavy write activity or a RAID rebuild already underway. It is in these windows of heightened exposure that the most serious incidents occur.
The RAID controller cache: a safeguard worth monitoring
On business servers equipped with hardware RAID controllers (Dell PERC, HP Smart Array, Broadcom MegaRAID), the default write mode is often write-back: data is acknowledged as written the moment it reaches the controller cache, before it is physically committed to disk. This mode boosts performance, but it leaves not-yet-written data exposed during an outage, unless it is properly protected.
Two technologies provide that protection:
- A BBU battery, typically rated for 3 to 5 years of service, able to keep the cache powered for 24 to 48 hours depending on the controller model.
- Supercapacitors, which flush the cache contents to flash memory within seconds.
An aging battery gradually loses capacity. When a controller detects a failing BBU, it normally falls back to write-through mode on its own, slower but safe, since every write is only acknowledged once it has actually been committed to disk. Manually forcing write-back mode back on while the battery is flagged as failing is a practice to avoid at all costs: it is exactly the scenario that turns an ordinary outage into a data-loss incident.
Consumer NAS devices (Synology, QNAP, Asustor) work differently: they rely on software RAID, with no dedicated hardware controller and no equivalent BBU protection. Their exposure to an outage follows a different logic, tied more to the state of the file system at the moment of shutdown than to any controller cache.
The UPS: essential, but not foolproof
A UPS (uninterruptible power supply) serves two purposes: providing temporary power during an outage and filtering the surges that often accompany one. On NAS systems, operating systems such as Synology DSM or QNAP QTS can detect the switch to battery power and trigger a clean shutdown of the device before the remaining runtime is exhausted.
The most common problem is not the UPS itself, but its battery. The lead-acid batteries fitted in most UPS units have a service life of 3 to 5 years, shorter in warm environments. A degraded battery may hold a charge for only a few seconds instead of the minutes needed to let the NAS shut down cleanly. A few simple precautions limit this risk:
- Schedule a monthly self-test of the battery.
- Replace the battery every 3 to 5 years, without waiting for a visible sign of weakness.
- Aim for at least 5 minutes of real runtime under load, not just at idle.
It is also worth remembering what a UPS does not do: it does not protect against a failure of the server’s own internal power supply, and it does not replace the BBU protection on a RAID controller. These are two complementary safeguards, not interchangeable ones.
Corruption patterns vary by file system
How a volume behaves after an outage depends directly on the file system in use.
ext4
The transaction journal replays automatically on reboot. Consistency is usually restored, at the cost of the last few seconds of writes before the outage. If the journal itself is corrupted, the e2fsck utility attempts a rebuild, with less predictable results.
Btrfs
Its copy-on-write design makes it more resilient in principle. But an interruption that hits precisely while the superblock is being updated can leave the volume simply unmountable, with no intermediate state.
ZFS
Generally robust thanks to systematic checksums on every block. An outage during a resilver (rebuilding a replaced drive) still remains a genuine window of vulnerability.
RAID level
An outage can trigger a parity inconsistency, a phenomenon known as a write hole. The write-intent bitmap (under mdadm) limits how much resynchronization is needed afterward, avoiding a full re-check of the entire volume.
Three complementary layers of protection
No single safeguard is enough on its own. Reducing the risk relies on three layers working together:
- A properly configured UPS, with automatic shutdown scheduled for the server or NAS, its battery tested monthly and replaced every 3 to 5 years, or sooner if runtime becomes insufficient.
- On a server with a hardware RAID controller: regular checks of the BBU or supercapacitor status through the vendor’s own tools, and an absolute rule against forcing write-back mode when a battery failure is reported.
- A backup following the 3-2-1 rule (three copies, two different media, one copy off-site): the only real guarantee in the event of a major failure, regardless of how resilient the file system is.
What to do right after an outage
What you do in the minutes after the system comes back on matters just as much as the outage itself for the final outcome.
- Do not interrupt an automatic check already underway (journal replay, Btrfs check, RAID resynchronization).
- Do not manually run fsck or btrfs check on a degraded volume: these tools can delete metadata that is still recoverable while trying to “fix” things too quickly.
- Decline any volume reset prompted by a system tool, even if it looks like the fastest way forward.
- If the system still behaves abnormally despite these precautions, shut it down cleanly, note or label the exact drive configuration, and bring in a specialist rather than attempting further fixes yourself.
One point is worth remembering above all else: as long as no rewrite has started on the drives, RAID metadata generally remains recoverable. That is precisely the window you need to preserve by avoiding hasty manipulation.
A power outage on a business server or NAS does not automatically mean data loss, but it does open a window of fragility that is better anticipated than endured. If your volume does not come back online normally after an incident like this, every additional manipulation reduces the chances of a full recovery.