Is RAID a backup?

No. A redundancy level keeps an array readable through the failure of a drive, and it does nothing about a file deleted by mistake, a volume encrypted by hostile software, a theft or a fire. Those reach every member at once.

This is the boundary this site does not cross, and it is worth setting out plainly why.

What a redundancy level is built to survive

A level stores enough additional information across the members of an array that the loss of one of them — or of two, at the double-parity levels — can be reconstructed. A drive fails, the array carries on serving, the drive is replaced, and the missing member is rebuilt.

That is the whole of the promise, and it is a good one. It means a failure is an errand rather than an emergency.

What reaches every member at once

A deletion. The file is removed, and it is removed from every copy the array holds, immediately, because they are the same file.

Hostile encryption. Software that encrypts a share writes through the array exactly as any other writing does. The redundancy faithfully preserves the encrypted version.

A mistake in the array itself. A volume deleted, a level changed, a wrong drive pulled during a rebuild. The redundancy has no opinion about which operations were intended.

The enclosure. A power supply that fails destructively, a controller fault, firmware that corrupts. The drives may be fine and the data unreachable.

Theft and fire. One box, one address, one event.

What a backup is, by contrast

A backup is a separate copy, on separate hardware, that can be restored from after the original is gone. Two properties make it one.

It has to be independent — not a second folder on the same array, and not a share that is permanently mounted and writeable, because software that encrypts the first will find the second.

It has to have history. A copy that mirrors the original faithfully will faithfully mirror a deletion the next time it runs. Versions, or a delay between the original and the copy, are what make a mistake recoverable.

The convention most often written down is three copies of anything that matters, on two different kinds of media, with one of them somewhere else. It is a rule of thumb rather than a standard, and it is a good one because each part of it defends against a different failure.

Where the two fit together

They are complementary, not alternatives, and a machine can honestly have both.

Redundancy is for uptime: a failure does not stop the household or the office. Backup is for recovery: something has been lost and has to come back. Buying the first and calling it the second is the mistake this whole page exists to prevent, and the marketing around network storage does very little to discourage it.

The practical version

If the array holds anything that is not held anywhere else, it is not backed up, whatever level it is running. Work out what is on it that exists nowhere else, and decide where the second copy of that is going to live. That decision is a separate purchase, a separate capacity figure and a separate routine — and it is the one that determines whether a bad day is an inconvenience or a loss.

The manufacturer’s own documentation comes first, and this page is not a substitute for it. Every rate, capacity, class figure, endurance rating, port speed and power figure on this page is reported from the manufacturer's own documentation, with its unit written as published, and named as such — none of it is measured here. A stated capacity is reported as the maker counts it, and is never restated in another unit, because the two are not the same figure. And the second statement repeated rather than assumed: a RAID level is not a backup. It keeps an array readable through the failure of a drive, and it does nothing about a file deleted by mistake, an array encrypted by ransomware, a theft or a fire. A second copy somewhere else is a separate decision, and nothing on this site describes a machine as a place where files are safe.