3

I'm planning to backup my personal file on a NAS (which will use the btrfs filesystem). It's a cheap nas so unfortunately no ECC ram in it. In my backup strategy the will be other copies of the files (online) by using service like Crashplan and Mega (I'll probably use both just in case). For further redundancy the nas itself may be backup externally through USB connection. So what do you think will happen If I notice some data degradation on one on more file.

Will there be a safe/working copy somewhere? I never used Crashplan before but they should keep the original version somehow cause they won't be able to notice any change in the file, right?

I'm a bit confused honestly and I'd like to understand if my strategy may actually work (until one day I'll have a NAS with ECC ram in it).

Many thanks

Improve this question
2
  • 1
    Even though Btrfs is not ZFS, I would strongly encourage you to read through at least the initial post in ECC vs non-ECC RAM and ZFS on the FreeNAS forum.
    – user
    Aug 19, 2015 at 7:20
  • thanks, very interesting reading. I didn't really want to skip on ECC but in my case the price difference was huge: I'm talking about the Netgear NASReady solutions.. ECC ram is being used only from ReadyNAS 516 systems up. But I also know I can save a lot through building my own system, but the only NAS OS available with BTRFS would be then Rockstor :)
    – horizonbrave
    Aug 20, 2015 at 0:10

1 Answer 1

Reset to default
1

Frankly, if you are unwilling or unable to use ECC RAM I would not consider using a self-healing file system such as ZFS (as discussed in the linked forum post) or Btrfs.

The reason is simply that the "self-healing" features quite easily can become "self-destructing" if there is a RAM problem.

Instead, on a non-ECC RAM system, you would probably be better off running a regular file system such as ext4. With Btrfs' state today (starting to become stable, but still a number of rough edges that need smoothing out and has yet to see significant real-world deployments and experience with failures), this would make me feel a lot more comfortable. Even ZFS, which is relatively proven as a file system, still has some glitches on Linux hosts; Btrfs isn't as mature as ZFS.

To detect bit rot on a file system that does not have the ability to natively validate data checksums, you can use any of a number of tools available for that purpose. One such tool, which I am not affiliated with, is hashdeep which can do MD5, SHA1, SHA256, Tiger and Whirlpool hashes. If you run this on a reasonably regular basis (same as you would a ZFS or Btrfs file system scrub), then you can be reasonably certain that you will catch any degredation that might happen. You can then restore the affected files from backups, either on-site or off-site.

I am not familiar with Crashplan, but I suspect they look at file metadata to determine if the file has changed or not, and since the file metadata likely won't be affected (unless it just so happens to be the target of the corruption, which will either be relatively inconsequential or cause any hash validation to also fail) it shouldn't be detecting any changes to the file. Hence, corrupted files shouldn't get backed up. If you want to be sure, configure your backup solutions to keep at least a few old revisions available in case one gets corrupted and backed up in such a state.

Improve this answer
1
  • Thanks Micheal, I'll consider all of your suggestions. Unfortunately Netgear doesn't provide ECC ram on their cheapest NASes (see RN31200) even if they all implemented btrfs (which I prefer being Linux native). I may think about building a NAS on a Atom SOC server board, otherwise the cheapest netgear solution with ECC will set me back a thousand dollars..
    – horizonbrave
    Aug 20, 2015 at 7:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .