Will NAS data become corrupted if stored for a long time? The first time I went to wash the dishes, I found 3 bad blocks and 2 were repaired on the spot.

Last month I was looking through the photos from 2019 on my hard drive and wanted to make a birthday video for my wife. There is a JPEG whose lower half is blurred into a rainbow bar, and an MP4 shot on a mobile phone that freezes halfway through playback. My first reaction was that the game was about to end, so I quickly went backstage to look at SMART. Everything was green and there was no yellow at all.

I struggled until midnight to figure out one thing: Just because the disk is not damaged does not mean that the data is not damaged. These are two different things. And my Feiniu has been running for three years and has not run through a single data verification - it is equivalent to locking the goods in a warehouse and not counting them once in three years.

Make it clear first: The data will really turn over quietly.

The jargon is called bit attenuation, or bit rot in English. A mechanical disk relies on magnetic domains to store 0s and 1s, and a solid state relies on electric charges. These two things are not carved on stone, and they will flip a few bits on their own if left unmoving. The disk will not alarm when flipping, the system will not report an error, and you will not even know it is done. When you open that file one day, what is read out is wrong - the photo screen is blurry, the video is stuck, the ZIP decompression reports a CRC error, and the document is garbled when it is opened, all of which are revealed at this time.

Why can’t SMART be detected even if it’s all green? Because SMART is the "physical examination list" of the disk, which is in charge of physical aspects such as heads, servo, and remapping. The article about SMART Broken inside: A normal physical examination means you are in good health, but it does not mean that the money in your pocket has not been stolen. The disk itself does not know whether the contents of the data block are correct or not, it must be verified by the file system.

In the file system, ext4 and Btrfs are two different attitudes. Believe whatever you read in ext4, don't tell me if it's wrong. ； Btrfs has a check code for each data block. It is calculated and saved when it is written, and the correct answer is recalculated when it is read (or during inspection). I wrote an article about how I chose between the two. ext4 or Btrfs , at that time it was just a matter of selection, but now I know that the verification is life-saving.

First time washing dishes: The progress bar was so slow that I thought the computer had crashed.

This function in Feiniu is called "Data Verification", which can be found by right-clicking on the storage pool. ； Synology calls "Data Washing" and it's in the "Actions" drop-down menu at the top of the storage pool page. Direct command line party btrfs scrub start /vol1 Okay, the effect is the same.

I picked a Friday night and went down at ten o'clock. I was confused for the first twenty minutes - the progress bar didn't move at all, the page didn't rotate, but the disk array buzzed. It was almost canceled. Then stared at btrfs scrub status Only after looking at it did I understand that its progress statistics are measured in units of several Gs. My 4T pool had to run for a while before the numbers moved. The final run took 6 hours and 40 minutes and ended at 4:50 in the morning.

There are three experiences to inoculate you in advance. First, it is really reading disks. The reading lights of the two disks are basically always on. It sounds a bit ominous at night, which is normal. Second, the speed of the shared folder dropped by more than half during the running process, and all the read bandwidth was consumed by the verification. Don't run it during the day when everyone is watching movies and files. Third, if you are equipped with a hard drive that sleeps, washing the disk will wake up all the sleeping disks. Follow me Hard disk hibernation always fails The secret writing schedule mentioned in that article is based on the same principle, and the schedule is staggered.

There are two columns of numbers in the report, one is good news and the other is critical illness notice.

The report after the run is very simple, but the two columns of numbers are very different. If you don't understand it, you will suffer a hidden loss.:

My report is 3 bad blocks: 2 were repaired on the spot, 1 could not be repaired. The two repaired ones are easy to understand - the one I set up is RAID1. btrfs If you find that the verification of a certain block on disk A does not match, you will go to disk B to read the same block of data and backfill it, while overwriting the bad copy on disk A. This is the value of the mirror pool. Btrfs on a single disk can also detect bad blocks, but it can only report them and cannot repair them.

The one that cannot be repaired is because the copies on both disks are broken. The probability of two disks failing in the same section is low, but the probability is 100%. I later looked through the logs and concluded that the data was written during an abnormal power outage in the summer of 2023. It has not been touched since it was written - it was not equipped with a UPS at the time, which was a disadvantage due to lack of knowledge. Now there is a UPS behind the machine. The account for power outage I've made up for it.

The bad block covered exactly half a minute of the two videos. The file itself is still there, but it can't be opened for half a minute. I reversed the old version from the off-site backup of my mother's old Synology and overwritten it, and the matter was settled - this is why I insisted on off-site backup of the two machines. RAID can save the disk from being damaged, but it cannot save the data itself from being damaged. Snapshots, backups, and migrations each manage what kind of disasters That article is very clear, so don’t expect the wrong person.

How often do you run: My schedule and three rules

Now my dishwashing is set to run automatically at 3 a.m. on the 1st of every month. Just add one to Feiniu's scheduled tasks, and Synology configures it in the task plan. Three rules for your reference:

• Staggered peak: Don’t get stuck with backup tasks. My rsync is to push to my mother's house at five o'clock every morning, and wash dishes at three o'clock in the morning. After running, they should be staggered so that neither party can slow down the other.
• Avoid sleep windows: Do not schedule disk reading tasks during the hard disk sleep period, otherwise hibernation will be in vain. Timer switch The machine needs to put the verification into the power window.
• Don't overlap: Don't run full disk hashing and bad sector scanning at the same time during disk washing. If the two large reads are squeezed together, the speed will be slow and it will easily time out.

Frequency is a matter of discretion. The main pool for saving family photo files, I recommend monthly ； Purely downloadable disks, deleted after downloading and reading, will not be a loss once every quarter or even half a year - anyway, if it breaks, you will have to download it again. The 4T pool can be run in one night. Don’t be put off by 6 hours when it comes to footing before and after sleeping.

In addition, washing dishes and snapshots do not conflict but complement each other.: The snapshot is anti-slip and the dishwasher is anti-turning. The two-layer account is in The snapshot article Calculate it. When the time comes for the pool to be downgraded and it is necessary to replace the disk and rebuild it, you will feel more confident after washing the disk first. Downgrade fix I walked through the five steps of the process.

There is no such thing as dishwashing for ext4 disks. Two dirt roads are enough.

If you have the same machine as my mother's house, and the pool is ext4, then there is no scrub to run - the file system does not store the check code, and there is no evidence to verify it. two dirt roads:

The first one is a full reading test. Synology runs a test on the disk in the storage manager. The command line is smartctl -t long /dev/sda , the essence is to read the entire disk, and the places that cannot be read will be revealed. But it can only catch "cannot be read", but cannot catch "blocks that can be read but the content is wrong" - blocks that are damaged by bit decay, but can be read completely.

Article 2, hash ledger. Create a verification file for important folders: find /vol1/photo -type f -exec md5sum {} + > /vol1/hash2026.txt , recalculate it every six months and reconcile it with the books. md5sum -c . Which file changed quietly, a command found out. The disadvantage is that it is troublesome and you have to keep your own ledgers. I run it once a year and read it in full.

Both methods cost "reading the entire disk", which is much cheaper than Btrfs's set of ready-made functions. So from the day you install the system and choose the file system, you should think about this path, don't wait for the photos to be exhausted and then improvise.

ending: Do it in this order

1. First confirm what file system your pool is, Synology looks at the storage pool properties, Feiniu df -T It's there at a glance.
2. For the Btrfs pool, I will manually run the first disk wash tonight and read the report once, so I have an idea.
3. If there is something "unrepairable" in the report, don't panic yet, go to the backup and look up the old version, and write it down by the way.
4. Set it to be automatic in the early morning of the month and stagger the backup and hibernation periods.
5. The ext4 pool reads the entire disk and adds a hashed ledger at least once a year.

Bit decay has a low probability and a long cycle. It only occurs 3 blocks in three years, which sounds like it is not worth mentioning. But the one thing that can't be repaired is the black screen in half of your wife's birthday video. There is no regret medicine for things like photos. Washing the dishes one night will give you three years of sleep. No matter how you calculate it, it will not be a loss.