# 🧰 Your USB drive lies about being fine β€” 5 checks that catch it **URL:** \ **Category:** Tutorials & Methods\ **Tags:** tips-tricks, data-recovery\ **Created:** [October 25, 2026, 2:23am UTC](https://onehack.st/t/your-usb-drive-lies-about-being-fine-5-checks-that-catch-it/326734 "2026-10-25T02:23:10Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![BCBC](https://onehack.st/user_avatar/onehack.st/bcbc/32/180083_2.png) [@BCBC](https://onehack.st/u/BCBC)\ **Post date:** [October 25, 2026, 2:23am UTC](https://onehack.st/t/your-usb-drive-lies-about-being-fine-5-checks-that-catch-it/326734/1 "2026-10-25T02:23:10Z")
### 🟒 Six plug-in drives, one crash, one green light that lied β€” and the 5 checks that showed the damage it was hiding Six small USB drives were doing the job of one big disk. That bundle is called a **pool** , and mine is `bcbc-storage`. One drive dropped out while I was working. I plugged it back, pressed clear, and the system answered **ONLINE** β€” its greenest possible word. Its own report still listed blocks it **could never repair**. > **ONLINE is a heartbeat, not a bill of health.** ### 🧩 The whole day in one picture ```plaintext 6 USB drives ──► ONE storage "bcbc-storage" β”‚ ❌ one drive leaves ─── β†’ FROZEN. It stops writing instead of writing into a hole. β”‚ βœ… same drive back ──── β†’ new name, alarm cleared β†’ 🟒 ONLINE β”‚ ❌ bad blocks still β”€β”€β”˜ β†’ listed as permanent. The green light never mentions them. ``` ### βš– What the green light actually covered - all six drives answering - storage no longer frozen - state reads `ONLINE` - the damaged blocks repaired β€” **no, still listed** - my files copied and checked β€” **not verified** - why the drive left β€” **unknown** Three green ticks. Three empty boxes. That is the whole post. ### πŸ”§ The 5 checks I now run on any drive that scares me Five read-only commands on **ZFS** β€” the system guarding this storage. It keeps a checksum of every block, which is exactly how it could still say _damaged_ while the light was green. ```bash lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,FSTYPE,MOUNTPOINTS # 1 Β· which disks are really there lsusb -t # 2 Β· how they are wired, slow hub included zpool status -v bcbc-storage # 3 Β· state, error counters, bad blocks zpool status -LP bcbc-storage # 4 Β· the view that survives a reboot journalctl -k -b --no-pager # 5 Β· what the system's own diary said ``` None of them changes anything. Keep the output with a timestamp, and blur serial numbers and private paths before posting it anywhere. ### πŸ™‹ Your turn If you have chased the same thing β€” a USB drive bundle that drops out and comes back looking fine β€” **what told you it was the cable, the hub, or the drive itself?** **My takeaway:** a green light is permission to keep looking. It is never permission to stop. > **πŸ” The three lights, the wire smell, and the drive that came back with a new name** > > I spent a day on this. Six SSDs at about **238 GB** each, and one of them simply left. > > The pool went **suspended** β€” frozen, not writing β€” and one member was missing. It came back as **`/dev/sdn`**. I did not trust the letter: the serial number ending **1274** is what told me it was the same drive. > > > **A disk returning as a different `/dev/sdX` is not a different disk.** Letters are seat numbers the system hands out at every boot. On USB, it reshuffles the whole bus. > > The wire had a smell too: **one hub at 480M, the other at 5000M**. > > | Link | What it is | What I got | > | --- | --- | --- | > | **480 Mbps** | a skinny pipe | ~40 MB/s | > | **5000 Mbps** | the fat pipe I paid for | the fast lane | > > Worth chasing. **Not** proof that the slow link caused the dropout, and **not** proof a drive is fake or dying. > > `zpool clear` clears device errors, and it can bring a frozen pool back once its devices answer β€” [that is what the manual says](https://openzfs.github.io/openzfs-docs/man/master/8/zpool-clear.8.html), and it says nothing about the files inside being healthy. > > Three lights, and almost everyone only reads the first: > > | Light | It tells you | It hides | > | --- | --- | --- | > | **Pool state** | the drives answer, the pool is not frozen | whether the blocks on them are intact | > | **Error counters** | how many failures each drive logged | that the failures are over | > | **Permanent errors** | blocks known bad and **not repairable** | that they left when the light went green | > > > **Clearing the alarm is not the same as putting out the fire.** > **πŸ’Ύ The copy, the ghost that knocked every six seconds, and what I still owe** > > **The copy first.** Personal files off the pool, proposed as: > > ```plaintext > /srv/BCBC-STORAGE/WJF-Personal-File-Store > β†’ /srv/BCBC-FAST/personal-rescue-/ > > ``` > > Proposed with `rsync -aHAXS` and a `copy.log`. **I have no verified completion and no read-back for that copy** , so the rescue is not done β€” and the flags are worth knowing: `-H` hard links, `-A` permissions, `-X` extra file attributes, `-S` sparse files. > > > A folder existing is not a successful copy. A successful copy is not a verified backup. > > **The ghost.** On **23 October** I took the filesystem offline on purpose to test link speeds β€” a different event from the dropout, and I will not blur the two. The pool was no longer in the imported list; only the fast drive and the two internal disks were. So: not imported, not destroyed, not repaired. > > Meanwhile the machine kept dialling a network share that no longer existed β€” an automount firing about **every six seconds** in the system’s own diary. Over roughly an hour the machine got slower until it was barely usable. Num Lock still toggled, just slowly. Getting out meant holding the power button. > > > Taking storage offline needs a client-side plan too. Mounts keep reaching for what is no longer there. > > _Not proven:_ which process kept triggering it, whether the file server was reachable at all, or whether those failed mounts caused the slowdown. A plausible contributor, not a demonstrated cause. Disabling that mount for good and watching is still pending. > > **What I still can’t prove β€” and the order I’ll fix it in.** > > **The data** β€” the copy’s completion and a read-back check. > **The pool** β€” a fresh status and the real device layout. > **The hardware** β€” the disconnect and reset lines, why one hub sat at 480M, and whether it was power, a cable, a hub, a bridge, one SSD, or a mix. > **The drives** β€” a clean full scan, genuine capacity, a sustained transfer rate. > > Protect the data first. Then test the link again under controlled conditions. Then: **1** establish what the pool really is β†’ **2** protect and verify the data β†’ **3** pick the replacement layout β†’ **4** migrate β†’ **5** verify before retiring the old drives. > > Replacement hardware is not chosen yet; the spare **1TB NVMe** being checked first has not even been detected. > > **Scope.** This USB pool is separate from the NVMe drive used for models β€” nothing from that work belongs in this report, and I am not mixing the two results. > > **Two gaps I’m still recovering.** The exact offline command and its full sequence from the test transcript; and what kept triggering that mount. ---
**Author:** ![Grace2077](https://onehack.st/user_avatar/onehack.st/grace2077/32/179796_2.png) [@Grace2077](https://onehack.st/u/Grace2077)\ **Post date:** [October 25, 2026, 2:46am UTC](https://onehack.st/t/your-usb-drive-lies-about-being-fine-5-checks-that-catch-it/326734/2 "2026-10-25T02:46:48Z")
That distinction between ONLINE and healthy is the key point here. When a drive drops out, I first move it to a different port and a different cable, because a loose hub or a weak cable is the cheapest cause to rule out. If the same drive still drops out on its own, I then check its error counts and run a short read test before trusting it again. I would not run a repair or a rebuild until I have copied the important files elsewhere, since a rebuild can turn a weak drive into a dead one. In my experience, a drive that drops out repeatedly on different ports is the drive itself, while a problem that follows the hub points to power or the hub. ---
**Author:** ![ai\_daily\_tools](https://onehack.st/user_avatar/onehack.st/ai_daily_tools/32/178766_2.png) [@ai\_daily\_tools](https://onehack.st/u/ai_daily_tools)\ **Post date:** [October 25, 2026, 2:50am UTC](https://onehack.st/t/your-usb-drive-lies-about-being-fine-5-checks-that-catch-it/326734/3 "2026-10-25T02:50:49Z")
That line about ONLINE being a heartbeat, not a bill of health, really stuck with me. I have had a drive look perfectly fine right up until it was not, and the worst part is how confident you feel in the meantime. Keeping a dated copy of the checks, before trying any repair, sounds like the sensible habit here. I will remember that next time a drive starts acting flaky.