NAS or cloud
for your backups?

Neither wins in the abstract: the right question is which risk you are exposed to, not in general. If your weak point is human error (a deleted folder, an overwritten version), a NAS with version history gives you the file back in seconds because it never leaves your network. If your weak point is the whole building (burglary, fire, water, or ransomware sweeping through the office), only what's off-site saves you, and that's the cloud. Most businesses face both risks at once, so the honest answer isn't «one is better», it's «both, with different roles»: the NAS as a fast first line, the cloud as the safety net when something bigger than a disk fails. Decide by looking at which scenario has already happened to you, or which one genuinely worries you, not by comparing spec sheets.

No, and it's worth separating from the previous question because it isn't about where the backup is but about how the disks behave together. A mirrored NAS (RAID 1 or similar) writes the same data to two disks at once: if one fails mechanically, the other keeps serving without you noticing, and that's availability, not recovery. The problem is that anything other than a physical disk failure (deleting by mistake, overwriting a file, ransomware encryption) happens on both disks just as fast, because the mirror can't tell a good write from a bad one. For a real backup to exist you need a version separated in time: snapshots, versioning or a copy that doesn't update itself. If your NAS only has mirroring, you're protected against hardware failure and nothing else; the rest of this list is still uncovered.

No fixed figure answers this, because what decides the real cost isn't the price tag but the time horizon and the volume you handle. A NAS concentrates the spending at the start (the device, the disks) and after that only electricity counts and, every few years, replacing a disk that starts to fail; once that initial outlay is made, storing more data costs almost nothing extra. The cloud spreads the cost over a subscription that never ends and usually grows with the volume stored, so the longer you keep it and the more data you accumulate, the more it weighs against the NAS. What almost nobody looks at is the cost of getting the data out: many providers charge for downloads during a large restore, exactly when you least want to look at the bill. Compare over your real horizon (how many years you'll keep the system), not the first month's fee.

Three copies of your data, on two media of different technology, with at least one outside the building where the original is. The three counts the original plus two copies, because with only one copy any failure in it leaves you with nothing; with two, both would have to fail at once, which is far less likely if they're also of a different nature. The «two media» is what the NAS provides (a medium separate from the computer's disk) and the «one off-site» is what the cloud provides, or a physical disk that travels to another address. That's why NAS and cloud don't compete: each solves a different part of the same rule, and anyone with only one of them meets two thirds of it at most. We have a separate article devoted to this rule, with the restore test that completes it; here it's enough to remember the three numbers.

Yes, and it's one of the most common routes precisely because the NAS is usually mapped as a network drive visible from the same computers that get infected. Modern ransomware, once it gets into a computer, doesn't stop at encrypting the local disk: it actively scans the network for drives and shared folders that user has access to, and encrypts them too. If your backup lives in a folder any computer in the office can write to without restriction, that backup is as exposed as the original. Two things genuinely reduce the risk: write permissions limited to whoever really needs them, and a layer of snapshots or versions that the malware itself can't delete or overwrite with an ordinary user account. Without that, a NAS well stocked with data can end up being the place where ransomware finds more to encrypt, not less.

As one of the pieces of the 3-2-1 rule, yes, as long as it's used with discipline and not as an excuse to do nothing else. Its advantage is that it's cheap, portable and doesn't depend on any subscription or your upload speed: you copy and take it with you. Its two weak points are the ones that really matter. First, if it stays plugged in permanently, it stops being an «off-site» copy and becomes just another drive ransomware can reach, like the NAS. Second, without a fixed habit of connecting it, copying and storing it somewhere else, the backup ages without anyone noticing until it's needed and is no longer any use. An external drive that's connected, updated and kept at another address (or rotated with another one that was already off-site) fills the off-site role perfectly well, without any need for the cloud.

What sets the frequency isn't a general rule, it's how much work you're prepared to redo if the failure happens just before the next backup. A practice that invoices daily can't afford to lose a week of invoices; a folder of family photos that barely changes can live with a monthly backup without drama. The second thing that decides frequency is whether the backup is manual or automatic: a manual task done «when I remember» ends up drifting further apart over time, whereas a scheduled one keeps whatever pace you set without depending on anyone. For data that changes every day (sales, email, work documents) the sensible minimum is an automatic daily backup, and something more frequent if what you can't afford to lose is measured in hours. The starting point is always the same: look at how much work you produce between backups, not how much space it takes up.

By actually restoring, not by checking that the backup job «finishes without errors», which is what almost everyone mistakes for it working. A backup job can finish green for months while copying an empty folder, an old version or a disk that filled up long ago, and the interface will keep saying everything is fine. The real test has three parts: pick a file at random, not the most recent or the easiest; restore it somewhere other than the original location, so you're not relying on it «already being there»; and open it to check the content is right and not a version from months ago. Do it on a fixed schedule, not only when something seems off, because silent failure is the rule, not the exception, in backups that have never been tested. If you've never done this exercise, you don't know whether you have a backup or just the feeling of having one.