Until recently I’d never given much thought to bit rot where my music was concerned, however, a series of issues I had with drives failing etc. led me to rethink how I’m storing and backing up my music. Having just about completed deduplication and consolidation of all my music I figured it was time to check on the health of the underlying FLAC files. The results are scary and in many cases where I’ve abandoned an old/original backup in favour of a fresh copy of the “production files” I’ve ended up abandoning good files and backing up their corrupted cousins.
Do yourself a favour, periodically check the integrity of your files. Windows users can use dbpoweramp or the free multithreaded audiotester. For Linux users the following script can do the job for you (it assumes that you’re starting in the root directory of your music collection):
Firstly generate a list of flac files you’re wanting to test:
find "." -type f -name "*.flac" > ./flacfiles.list
Now have a script sequentially process the contents:
while [ -s $filelist -a $SECONDS -lt $seconds_to_run ] ; do
file=$(head -1 $filelist)
if ! $flac -t --totally-silent “$file” ; then
echo $file command here >> bad.files
echo Corrupt: $file
fi
# remove current file from list
sed -i.prev ‘1d’ $filelist
done[/code]
Corrupted files will be listed in ./bad.files
Once you’ve a known good state I’d also highly recommend using a tool like SnapRAID to create offline parity files that allow you to detect and recover from bit rot and/or drive failure.
I’m still debating with myself about how to fight Bit Rot… I’m leaning towards a NAS with ZFS (probably FreeNAS), but haven’t really made up my mind yet.
ZFS will certainly address the issue in that all files have a checksum generated as they are stored and the files can be corrected using the checksum if there is an issue. ZFS also allows for a scrub to check individual files and fsck to check/repair the overall file system. I have implemented it using FreeNAS for both music and video files. I also maintain two sets of full backups, one in the house and one off-site. I’m not too worried about data loss or corruption at this point.
On a Windows box or a Mac, you can calculate a hash (SHA1 is a good choice) on each FLAC/ALAC file as you create it. It is pretty easy to then to use a script or batch file to compare that hash with a new one on a daily/weekly/monthly basis.
[quote=“pwright92, post:4, topic:5773”]
On a Windows box or a Mac, you can calculate a hash (SHA1 is a good choice) on each FLAC/ALAC file as you create it. It is pretty easy to then to use a script or batch file to compare that hash with a new one on a daily/weekly/monthly basis.
[/quote]that’ll do nothing to help you recover a corrupted file.
[quote=“fritzg, post:3, topic:5773, full:true”]
Sounds to me like what you are describing is actually “data rot” and not “bit rot”, aka “software rot”.
[/quote]yes, I guess you’re right, albeit the terms are pretty much used interchangeably most places.
It looks like SnapRAID implements ZFS for its file system which is a good thing.
ZFS is native to the BSD operating systems (OpenBSD, FreeBSD) and Solaris and is also implemented in FreeNAS and NAS4Free. You can layer ZFS onto Linux without too much difficulty and, if you are a masochist, onto Windows or OS-X.
No sure it does. SnapRAID is not a real time raid system. Parity is calculated and integrity is checked at user instance. It’s basically offline raid and intended for data that does not often change. There’s also no real pooling of storage like that of a typical raid array.
I’m monitoring my collection with a python script, which i’ve found here:
Basically the script scans the files in a folder recursivly and stores the checksum and modification date of each files in a database. On subsequent scans each file with an altered checksum and unchanged modification date is reported as corrupt.
Alternatives to the ZFS file system are the Btrfs file system (LINUX, available as option on newer Synology NAS systems under DSM 6.1) and the Microsoft ReFS file system (e.g. Windows 10 and other). I think, such a file system should be used for photo files as well as music files to safeguard against data degradation, i.e. bit rot or data rot.
Yes. Until recently, I worked at Microsoft in the group that built ReFS. ReFS and equivalent Unix systems are very valuable.
The risk of bit rot is not huge. The experts I know said one bit per TB, on average. Can be caused by bugs in controller software, hardware problems, cosmic rays and other things. (The risk goes up dramatically if you bring your laptop on an airplane, an extra 10,000 meters of atmosphere is good protection from cosmic rays.) The point is, a single bit flip may be a small error in a single sample that you can’t hear, or it can destroy a directory catalog and make the whole disk unusable.
Raid doesn’t help, most Raid systems return the bad bit, they don’t detect the error and read from the other drive instead. And backup - you may have the error already in the backup.
I use ReFS on my Windows machine (together with Storage Spaces), because I can. But the risk is not huge. It is primarily intended for enterprises with really important data. Compare with the risk of fire and flood and burglary…
Given I am now moving over to a complete flac base music experience and no longer owning any cds. I need to be sure my rips are perfect. I use EAC and the recommended settings. However I am concerned about data rott on the hard drives. What can I do? What filesystem, what technology, etc?
This is where file systems such as ZFS are superior. I use syncthing to keep my copies backed-up. What ever is in my NAS it gets replicated down to Music Server. If a song or even the library gets corrupted it gets re-sent.
Why I chose ZFS? If anything gets corrupted ZFS will detect it and correct it.
Thanks Fernando. I came across this before but it really confused me. I have built windows machines in the past but thats easy. This seems over my head! Can you even install ROon on it?
DelPrado, Why would you? Its a NAS OS. While it has capabilities of installing docker images and you can install the core on an image, I would advice against it. I would keep my core on its own dedicated server.
