Note that it doesn't look like it has ECC, so make sure to have backups. Fancy file systems like ZFS don't remove the need for ECC.
It's OK for corporate systems, but complete overkill for personal setups.
My personal files are ultimately a lot more important to me and much more irreplaceable than any files at work.
I'd never run a NAS without ZFS and ECC.
Both of which are 3-2-1 backed up.
Adding an ECC motherboard to my NAS would cost more than a quarter century of cloud storage for that amount of data.
The rest of my terabytes of data would be inconvenient to lose, but not fatal. In the worst case I'd need to track down a few rare DVDs and re-rip them.
Keep in mind that backups are a solution to a different problem than ECC.
If a file is silently corrupted you could be backing up the corrupt file for years and by the time you discover the problem, it has spread to every available backup.
a) 99%+ (or something) of the servers had zero reported errors for their lifetime. Memory usually works, no problems experienced.
b) Some of the servers reported one error, one time, and then all was well for the rest of their life. If this happens without ECC, and you're lucky, it's in some memory that doesn't really matter and it's no big deal. Or maybe it crashes your kernel because it's in the right spot (flip a bit in a pointer/return address and it's easy to crash). Or maybe it managed to flip a bit in a pending write and your file is stored wrong and the zfs checksum is calculated on the wrong data. If you're really unlucky, you could probably write bad metadata and have a real hard time mounting the filesystem later?
c) some servers reported the same address with a correctable error once a day; probably one bit stuck, any time data transits that address, that bit is still stuck, and that will likely cause trouble. If it's used for kernel memory, you'll probably end up crashing sooner or later.
d) some servers had a lot more ram errors; sometimes a slow ramp to a hundred a day, once or twice a rapid ramp to so many that the system spent most of its time handling machine check exceptions, but did manage to stay online but developed a queue it could never process. Once you're at these levels, you'll probably get crashes, but you might write some bad data first.
Ram testing helps on systems without ECC, but you won't really know if/when the ram has gone from working 100% to working almost 100%. I have a desktop that was running fine for a while, tests fine, but crashes in ways that have to be bad ram, and removing one stick seems to have fixed it.
If it would hugely impact your life if a bit were flipped from a 0 to 1 in your stored data - say you make videos or store your bitcoin wallet key on your NAS - you are running a risk not using ECC.
You may not have had issues or ever have issues with non-ECC. Your car may never be stolen if you leave the keys in either, but it's not a good risk proposition for most people.
I now use ECC EVERYWHERE now. My laptop, my desktop, my little home server. All ECC. Because, ECC is cheap and provides a lot of protection for very little effort on my part.
[1] https://www.lenovo.com/us/en/p/laptops/thinkpad/thinkpadp/th...
There are various trade offs you can make depending on your filesystem, OS tooling and hardware which can mitigate risks in different ways. However non-ECC invites a lot of risk. How often are you checksumming your backups to validate integrity? It seeks unlikely you've had 0 memory corruption over 20 years, more likely you didn't notice it or your run a filesystem with tooling that handles it.
Can you (or someone) suggest a backup scheme? I have a 28TB NAS. Almost everything I've looked into is expensive or intended more for enterprise tier.
Are there options for backup in the "hobbyist" price range?
My home NAS has several roles, so I don't have to backup the full capacity. The family shared drive definitely needs to be backed up. The windows desktop backups probably don't, although if I had a better plan for offsite backups, I would probably include desktop backups in that. TV recordings and ripped optical discs don't need to be backed up for me, I could re-rip them and they're typically commercially available if I had a total loss; not worth the expense to host a copy of that offsite, too; IMHO.
You might do something like mirrored disks on the NAS and single copy on the backup as a cost saver, but that comes with risks too.
Buy the hardware to make a lightweight backup server. Make backups work with it. Take it to your friend's place along with a bottle of scotch, plug it in, and then: Use it.
Disaster recovery is easy: Just drive over there.
Redundancy is easy: Build two, and leave them in different places.
None of this needs to happen on rented hardware in The Clown.
Back in the days of DVDs, I used to backup my 20GB drive onto DVDs. I wonder if you could do something similar today but instead of a bunch of 4GB optical disks, you would use 4 x 8TB drives?
Used it years ago, we rotated disks every week or something and periodically would take one out of commission and get a new one.
I believe you can mix and match storage mediums - like have your monthly snapshot write to tape.
I been using Interserver[1] + borg[2] for the last 3 years. With the 10TB plan comes out to $25/mo, but if you prepay a year there's discounts.
For the OPs use case, they have a 40TB plan for $84/mo. Still pricey, but, cheap compared to most other cloud storages. If you have data you care about, off-site backups are required.
You could also take the awkward route and add one or two large drives to your desktop, mirror there, and back that up to backblaze (not B2).
The other suggestions you got for hot storage strike me as the wrong way to handle this, if you're considering $80 per year per TB for backups then just make another NAS.
Another NAS isn't really a good solution (unless you can place it in a different house) - the goal of a cloud back up is that it's offsite.
The egress is only super high when you compare to how cheap $1 per month is.
And I bet you can find somewhere offsite for a NAS for free or a tiny fraction of $150/month.
Had this setup ~10 years and have had to replace a drive on two occasions but never needed to restore from Glacier.
At this point even if I do need to do a Glacier restore one day it’s still going to work out to be pretty economical.
So this might be on the higher end of the price range if you're using up all 28 TB uncompressed since that's about $168 per month though...
$0.004 Per GB/month
> when they do happen they aren't likely to be a big deal.
But with more sensitive data it might matter to you. Ram can go bad like hdds can, and without ecc you have no chance of telling. Zfs won't help you here if the bit flip happens in the page cache. The file will corrupt in ram and Zfs will happily calculate a checksum for that corrupted data and store that alongside the file.
I'd happened to archive the files to CD-R's incidentally. I was able to compare those archived files to the ones that remained on my file server. There were bit flips randomly in some of the files.
After that happened I started hashing all of my files and comparing hashes when I migrate files during server upgrades. Prior to using ZFS I also periodically verified file hashes with a cheapo Perl script.
You can Google more, but, I'll just leave this from the first page of the openZFS manual:
Misinformation has been circulated that ZFS data integrity features are somehow worse than those of other filesystems when ECC RAM is not used. This is not the case: all software needs ECC RAM for reliable operation and ZFS is no different from any other filesystem in that regard.[1]
I agree that ECC is a damn good idea - I use it on my home server. But, my lappy (i5 thinkpad) doesn't have it.
There aren't that many cases where it actually matters.
When running software RAID, memory errors could also cause data to be replicated erroneously and raise an error the next time it's read. That said if the memory is flaky enough that these errors are common it's highly likely that the operating system will crash very frequently and the user will know something is seriously wrong.
If you want to make sure that files have been copied correctly you can flush all kernel buffers and run diff -r between the source and destination directory to make sure that everything is the same.
It's probably way more likely to experience data loss due to human error or external factors such as a power surge than bad ram. I personally thoroughly test the memory before a computer gets put into service and assume it's okay until something fails or it gets replaced. The only machine I've ever seen that would corrupt random data on a disk was heavily and carelessly overclocked (teenage me cared about getting moar fps in games, and not having a reliable workstation lol)
https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-y...