Lolight

Thanks for the thorough response — this is genuinely useful engagement and I appreciate it. On Duplicati The platform correction on bug #6626 is fair. The specific November 2025 instance was filed from Windows on a canary build — that's a valid distinction worth making. The broader concern though isn't limited to that specific bug. Duplicati's restore reliability problems on Linux Docker deployments are documented independently and significantly predate November 2025. The Duplicati forum has a thread from 2019 titled "Backup valid, but still unrestorable" specifically about Linux deployments — updated through 2022 — with a Duplicati developer acknowledging in 2021 that backup job interruptions causing database desynchronisation "does happen due to the current setup." The SQLite desynchronisation problem is specifically more severe on Linux due to Mono's resource consumption characteristics — which is Unraid's primary deployment environment. The video's June 2025 publication date predating the November 2025 bug is accurate — but these architectural restore reliability problems were documented and available well before the video was produced. On the January 2026 stable release — worth being precise about what it actually contains. The primary change in version 2.2.0.3 is an update to the restore algorithm that limits cache size so restores can complete on systems with limited disk space. That's a specific and useful fix for a specific scenario. It doesn't address SQLite desynchronisation or the database corruption on interrupted backups that the community has documented since 2019. The Mono runtime dependency on Linux that drives resource consumption issues is unchanged. The stable designation is meaningful — but it reflects the developers' assessment that known critical bugs are resolved, not that the architectural characteristics that make restore testing essential have changed. This actually strengthens rather than weakens the case for a pinned comment. Users who configured Duplicati following the June 2025 video don't know about the January 2026 stable release, don't know whether their existing configuration is on the current version, and haven't been told to test their restores. A pinned comment that says — verify you're running the current stable release, test your restores before depending on this for critical data, here's what to check — serves those users directly and costs nothing to add. On hardware guidance Really glad this is being looked into — the acknowledgement that NAND quality considerations aren't unique to USB drives is exactly the right framing. Here's the USB Flash section guide: https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-nvme-hardware-selection/ The NAND type hierarchy, always-on duty thermal characteristics, and the controller workload argument for MLC and 3D TLC over QLC are all there. The NVMe extension is straightforward from that foundation — the same physics apply, the capacity thresholds where QLC becomes likely are different, and the combined boot plus cache failure consequence adds a specific dimension worth covering. The 7.3 release notes' own language — "manufacturers have quietly shifted to cheaper NAND, endurance ratings have dropped" — is the right framing for why this guidance matters before purchasing decisions are made rather than during onboarding after hardware is already installed. Happy to contribute to extending it if that's useful. On the survey gap The population sampling explanation is reasonable as far as it goes — the forum's self-selected technically vocal population does skew toward different priorities than the broader user base. That's a fair methodological point worth acknowledging. The part the population explanation doesn't fully account for is the instrument design. Open-ended feedback analysis compresses backup priority compared to forced-choice feature ranking — users writing freely about pain points tend to describe symptoms rather than features, and backup failures manifest as data loss experiences that don't always get categorized explicitly under "backup" in open-ended analysis. A forced-choice ranking question administered to the same 3,000 respondents would likely produce a meaningfully different figure. That's not a criticism of the survey's overall value — it's a methodological consideration worth factoring into how the 13.9% figure is weighted against other signals. Genuinely looking forward to the boot device guidance development and the conversation with Ed on the pinned comment.

Good call sticking with USB — and not just because of the TPM situation. Those built-in 128GB SSDs in your DXP devices are buried deep inside the PCB — getting to them apparently requires completely dismantling the unit. Ugreen doesn't publish the NAND type which at 128GB in a consumer NAS appliance almost certainly means QLC — optimised for UGOS workloads, not for always-on server boot duty. QLC in that role generates continuous controller heat at idle from managing 16 voltage states constantly. Add cache pool duties on top and if it fails you lose OS config and cached data in one hit — worse than a USB failure which only takes out boot config. Your USB drive has been working reliably for a reason. Whatever's inside it is almost certainly better suited for Unraid boot duty than that buried QLC SSD — TPM or no TPM.

Thanks for engaging with this — really appreciate it. Here's the link to the November 2025 GitHub issue on the Duplicati repository: https://github.com/duplicati/duplicati/issues/6626 It documents version 2.2.0.100 canary from November 5, 2025 — a failed dblock upload causing future backups to appear successful while actually being corrupted and unrestorable. Worth noting this isn't an isolated bug — Duplicati's own forum has a thread from 2019 titled "Backup valid, but still unrestorable" documenting the same failure pattern updated through 2022, with a Duplicati developer acknowledging in 2021 that backup job interruptions causing this condition "does happen due to the current setup." The architectural issue predates the November 2025 instance by years. Users in the video's own comment section describe experiencing exactly this — corrupted database errors and missing files discovered only when they actually needed to restore, after months of thinking their backups were fine. On the internal data point regarding backup priority — genuinely curious what that looks like compared to the July 2024 forum poll which had 651 participants and showed integrated backup at 36%. If the internal data tells a different story it would be really useful to understand what it's measuring and how it differs from what the poll captured. On hardware guidance — there are now three separate official Lime Technology documents that together reveal a specific gap worth addressing. The 7.3 release notes state that "manufacturers have quietly shifted to cheaper NAND, endurance ratings have dropped, and flash failures have become more common" — the correct diagnosis of the USB failure cause. The new TPM documentation states that "USB flash devices are becoming less reliable" and that "TPM-based licensing means your license remains valid even if you change boot devices" — correctly identifying the reliability decline and offering licence portability as the response. Neither document addresses the fact that the same NAND quality decline affects the NVMe devices being recommended as replacements. TPM licensing solves the licence management problem after a failure. It doesn't address the hardware quality variable that determines whether that failure happens in the first place — or its consequences. A budget QLC NVMe in always-on boot plus cache duty will fail for the same NAND quality reasons the release notes identify as causing USB failures, with the additional consequence of losing OS config and all cached data simultaneously. The older motherboard guidance compounds this further. Users directed to add an inexpensive TPM header module and switch to internal boot are making a hardware investment based on the reliability premise — without any indication that the NVMe device they select is the variable that actually determines whether that premise holds. The TPM module purchase creates a specific confidence that the NAND quality guidance gap then undermines. The place where this guidance matters most is before purchasing decisions are made — on the unraid.net product pages where people research Unraid, and in pinned community resources on the forum and Reddit. By the time a user reaches the boot device selection screen the hardware is already installed and the choice is already made. The 7.3 release notes already contain the right language. There's already a hardware guide in the USB Flash section that could serve as the foundation. The work is largely done — it just needs official visibility at the right point in the user journey. Looking forward to the follow-up. Thanks again for responding.

@SpencerJ Taking that invitation at face value — two specific points worth raising directly. On hardware guidance Documentation & guides came in at 25.8% in the survey's feedback themes — essentially tied with UI/UX modernization as the top concern. As internal boot gets closer to release this becomes pretty relevant — the same NAND type and controller quality variables that caused years of USB boot drive problems apply directly to NVMe selection too. A budget QLC NVMe pulling double duty as both boot device and cache pool risks losing OS config and all cached data in a single failure — actually a worse scenario than a dead USB drive. There's already a hardware guide in the USB Flash section covering this for USB drives. Would extending that guidance to NVMe selection — specifically NAND type considerations and the risks of QLC in a combined boot/cache role — be part of the documentation commitment? On backup reliability The gap between backup coming in at 13.9% in the survey versus being the top feature request at 36% in a July 2024 forum poll is pretty striking. That's a big difference for what's consistently been the community's most requested feature. More immediately though — there's a specific concern about the Duplicati Complete Guide video published on the Uncast Show YouTube channel in June 2025. Duplicati has well-documented restore reliability problems specifically in Linux Docker deployments — including a confirmed November 2025 bug where failed uploads produced backups that appeared to complete successfully but were actually unrestorable. Users in the video's own comment section describe running into exactly this — corrupted database errors and missing files discovered only when they actually needed to restore, after months of thinking their backups were fine. The video was produced by a Lime Technology employee without mentioning any of these known issues. Would a pinned comment or description update be something the team would consider — just so viewers know to test their restores before depending on it for critical data? Happy to discuss further if useful.

A good question. The official documentation confirms the blacklist is permanent and universal. https://docs.unraid.net/unraid-os/system-administration/maintain-and-update/changing-the-flash-device/ "Cannot be used with Unraid" — not "cannot be used with your specific license." The language is categorical and applies universally. The drive is permanently retired from any Unraid use on any machine with any license including trial. That would be my understanding.

@sonofdbn Honestly for the Win 11 VM specifically — recreating the VM configuration in the Unraid VM manager from scratch might actually be the cleaner path forward. Your actual Windows installation lives in the vdisk image file and is completely separate from the libvirt configuration. The VM manager settings you'd be recreating are just the wrapper that tells Unraid how to run it — CPU cores, memory allocation, network settings, USB passthrough and so on. Tedious to redo if you had a complex setup, but infinitely less risky than importing a potentially corrupted libvirt database onto a fresh installation.

The "solutions already exist" argument is reasonable on its face — but it assumes the guidance toward those solutions has been adequate, which the community's experience suggests it hasn't been. The most prominently recommended backup solution for Unraid has documented restore reliability problems that were not disclosed to the tens of thousands of users directed toward it. The ask for integrated backup isn't really about the absence of backup software — it's about the absence of a trusted, verified, supported path that matches the accessibility promise the platform makes everywhere else. On resources — a team actively developing internal boot, UI modernisation, Docker Compose support, and Unraid University courses simultaneously is not a team too small to address its most requested feature. It's a team that has made a prioritisation choice. That's entirely Limetech's prerogative — but framing it as a resource constraint rather than a priority decision understates the community's legitimate expectation. One thing worth knowing — HexOS, built by former Limetech employees, has Buddy Backup — peer-to-peer Unraid-style server backup — shipping in version 1.1 immediately after their 1.0 release. They're also sponsoring the ZFS AnyRaid project specifically to address mixed drive size support — a direct architectural move toward Unraid's core differentiator. They're a small team too. They found the resources. The "people will just whine for more features" prediction may be correct. It's also the argument that has been used to justify not building the most requested feature for at least three years running.

Replacing an entire server when it was the boot drive all along... That's genuinely painful to read and I really feel for you on that one. The frustrating thing is how perfectly the Bar Plus thermal failure mimics unstable hardware. It doesn't fail cleanly — it just becomes intermittently unrecognizable at the controller level when it gets too hot, which looks exactly like a flaky PCIe slot, a dodgy memory stick, or an unstable CPU. Nobody thinks to blame the little USB drive that's supposedly just sitting there doing nothing. The failure mode is very counterintuitive — and it's completely absent from any official guidance that might have pointed you there first. That's the real problem. Really glad the Cruzer Blades sorted it out. USB 2.0 power draw is lower so the thermal stress just isn't there — not the ultimate long term solution but clearly good enough to prove what was actually going on. The ATP Nanodura from Mouser is absolutely the right destination — SLC industrial drives are exactly what should have been recommended from day one. Keep the order active though — Mouser stock does move.

Since you're on Linux chipgenius won't run directly — the closest native alternative is lsusb. It won't give you the full Flash ID that chipgenius extracts but it will confirm the controller which is the most important piece. When the drive arrives plug it in and run: lsusb -vLook for the PNY entry in the output. The key things to match against the verified unit are the controller string — should show Phison PS2231 or similar — and the VID/PID values. For the verified China-manufactured unit those are: VID: 0930 PID: 6545 If the Taiwan unit matches those values it's confirmed to be the same controller and almost certainly the same internal specification. The full Toshiba 56nm Flash ID confirmation that chipgenius would give you isn't directly accessible from Linux tools — but a matching VID/PID on a Phison PS2231 controller from a 2007 PNY Attache is strong enough evidence that you can be confident in what you've got. There's a verified chipgenius output for this exact drive posted in the USB Flash section (MLC-based drives) of this forum if you want to cross-reference the full spec sheet once you have your lsusb output.

Probably not, let me search.

Really glad you found it and got the offer in — that's a great result. You're right that day to day it'll feel identical to any other USB drive — that's actually the point. The difference shows up over years of always-on server duty rather than in any immediate way. You've essentially removed a failure mode that most people only discover the hard way. Run chipgenius on it when it arrives just to confirm what's inside — the primer guide in the USB section explains exactly what to look for. And if you can, please post the results in the MLC drives thread (also in the same USB section). If it matches the verified specs it's about as good a boot drive as you can get at any price right now. Good luck with the rest of the server setup.

Thank you for the correction — that's exactly the kind of specific knowledge I was lacking and precisely why I flagged that my advice was research-based rather than hands-on experience. So to correct what I posted — VM definitions in Unraid are stored as individual XML files rather than a vm.conf file. The global VM manager settings live in /boot/config/domains.cfg on the flash drive. Could you confirm the exact path where the individual VM XML definition files are stored on the flash drive? That would complete the recovery picture for the poster trying to preserve their Win 11 VM settings — and correct the record properly for anyone finding this thread later.

This forum poll from July 2024 showed integrated backup as the top feature request at 36% Genuinely curious how that maps to 13.9% in the current survey results

Good news on the hardware — a still-packaged Cruzer Blade is a solid interim solution, and catching the corruption with fsck.fat before a crash was exactly the right move. On the recovery — I'm not deeply versed in Unraid's config recovery specifics, but based on what I've read online your instinct about targeting specific config files is exactly right and looks like the cleanest path forward. A fresh 7.0.1 install boots cleanly, which means the OS itself is fine. The problem is restoring your specific configuration without importing corrupted files from the failing drive. The files worth targeting for your VM setup specifically are in the config folder on the flash drive. The key ones appear to be: vm.conf — contains your VM definitions including all the settings you configured for the Win 11 VM. This is the file most worth recovering carefully. domain.cfg — VM global settings. network.cfg — network configuration. shares/ folder — individual share configurations. plugins/ folder — list of installed plugins that auto-reinstall on boot. Your approach of cross-checking the same file across multiple backups is exactly correct. If the vm.conf from your March 2025 backup matches an earlier backup, it's almost certainly clean. The practical workflow based on what I've found — start with the fresh 7.0.1 install that boots cleanly, then copy only the verified config files into the config folder one at a time rather than restoring the entire backup at once. Boot after each addition to confirm stability before adding the next. This isolates any corrupted file immediately. Worth waiting for more expert eyes on the specific recovery steps — but this approach seems to be the right direction based on what I've been able to find.

The 19% hardware guides figure caught my eye — and it connects directly to something worth flagging as internal boot rolls out. The USB boot drive problems that drove the PSA on SanDisk thread and eventually the USB Flash section all came down to one thing — hardware selection. Specifically NAND type and controller quality in always-on 24/7 duty. Those exact same variables apply to whatever NVMe drive someone picks for internal boot. A budget QLC NVMe pulling double duty as both boot device and cache pool is actually a worse failure scenario than a dead USB drive — you lose OS config and all cached data in a single event. There's already a hardware guide in the USB Flash section that covers exactly this kind of thinking for USB drives. As internal boot gets closer to release it seems like a natural opportunity to extend that guidance to NVMe selection — NAND type considerations, why QLC in a combined boot/cache role is risky, the Optane option for boot-only use. The foundation is already there. The 19% asking for hardware guides are going to need this whether they know it yet or not. Getting it in place before the failures start is a lot easier than explaining it afterwards.

Absolutely happy to help with that! The short version of what to look for on eBay — search for USB flash drives from brands like Kingston, PNY, Verbatim, or SanDisk with a copyright or manufacture date of 2007-2010 on the packaging. The older the better within that window. Capacity of 4GB or 8GB is plenty for Unraid and actually works in your favor — drives that small from that era almost certainly contain the good stuff inside. The free tool to verify what you've got when it arrives is called chipgenius — it reads the controller and NAND details directly from the drive. (SanDisk is a notable exception- very difficult to verify its components). The USB guide (Unraid Boot Device Guide in the Boot Devices category) on this forum explains exactly what to look for in the output. To save you the search time — there's currently a specific verified listing on eBay worth looking at: a 4GB PNY Attache Optima Pro from 2007-08 (made in Taiwan), confirmed with a Phison controller and 56nm Toshiba MLC NAND in its Chinese iteration, which is about as good as it gets for an Unraid boot drive at any price point. It's only been listed a few days, already down to around $15 with an offer option active so you could probably get it for $13-14. Item number is 267599196989 Drives from this era do surface on eBay occasionally but finding one with confirmed 56nm NAND in the exact same model, at this price is genuinely uncommon — worth grabbing if you're inclined.

Coming to this a year late — those Cruzer Blades are probably well settled in by now! Just wanted to say your original diagnosis was really sharp. Bar Plus failing to show up at BIOS level until it cools down, across two different servers — that's not bad luck, that's the drive telling you exactly what's wrong with it. And moving to USB 2.0 was the right call, for precisely the reason your experience pointed to. One thing worth keeping in the back of your mind for when those Cruzer Blades eventually need replacing — modern budget drives, even genuine ones ordered direct from SanDisk, are built quite differently inside than the USB 2.0 drives that earned the reliable reputation in the first place. The counterfeit risk is gone which was smart thinking, but what's inside a current production Cruzer Blade is a different story from what was inside one ten years ago.

Your instinct is right — that drive isn't great for this job unfortunately. $10 USB 3.2 drives are built around the cheapest NAND available which generates more heat at idle than you'd expect for something doing almost no work. For a drive that's powered on 24/7 for years that matters more than the transfer speed which Unraid barely uses anyway. The good news is you don't need to spend much to do significantly better. Before buying anything else — do you have any old USB drives lying around from maybe 2008-2013? Anything from a recognisable brand like Kingston, PNY, Verbatim, even an old SanDisk from that era? If so it's genuinely worth checking what's inside before spending money on something new. The guide explains how to do that with a free tool called chipgenius. If you don't have anything suitable in a drawer there are verified options on eBay in the $10-20 range that are actually purpose-built for exactly this kind of always-on low-write application. Happy to point you to a specific one if that's easier than digging through old drives.

Glad you sorted the licence transfer — and that's actually a really useful find that should definitely be in the docs somewhere. On the replacement drive though — "decent" is making me a little nervous! The tricky thing with Unraid boot drives is that newer and shinier isn't actually better for this job. A drive that looks great for general use can be a poor choice for something that's plugged in and powered 24/7 for years on end. There's a guide right here on the forum that goes into exactly why that is — [link]. The conclusion might surprise you — an old USB 2.0 drive from around 2008-2013 from a decent brand is very likely a better choice than anything you'd pick up at a store today. The reasons are explained in the guide but it comes down to how the older drives were built vs what goes into cheap modern ones. What did you end up getting as the replacement? If you let me know I can give you a quick honest take on whether it's a good fit for always-on server duty before you get too settled with it.

Directory Bread Errors indicate active FAT32 filesystem corruption on the boot drive — not something to live with. Flash drives in this state tend to fail abruptly rather than gradually. The server running fine now is not a reliable indicator of how long that will continue. Do this immediately regardless of anything else — Main → Flash → Flash Backup, download the zip, store it somewhere off the server. If the drive fails before you do this, recovery becomes significantly harder. On waiting for internal boot — a drive showing active corruption will not wait for a software feature with no confirmed release date. Replace now, migrate to internal boot when it arrives. On finding a replacement — the situation is better than general forum anxiety suggests. There is a guide posted on this forum https://forums.unraid.net/topic/196967-usb-flash-primer/#comment-1606140 that addresses USB boot drive selection in detail. The short version: a quality USB 2.0 drive from 2008-2013 found in a drawer is likely your best practical option at any price point given current market conditions. If you don't have one, NOS (New Old Stock) drives of exactly this type are currently available on eBay at very reasonable prices — happy to point you to a specific verified listing if useful.

I'd suggest checking the USB Flash Primer - https://forums.unraid.net/topic/196967-usb-flash-primer/ You can do much better than the Samsung Bar. Better options are available.

Given the exceptionally high failure rate, it would be wise to avoid the hassle and invest in a high-quality USB drive. Primer

The fact that your Unraid USB drive has lasted only 5 months is very concerning and speaks volumes about the drive quality. Hope you haven't chosen a similar drive as a replacement.

Marketing fluff.. ECC has been a standard feature in virtually every NAND flash controller for decades — it's not optional, it's a necessity because NAND flash by its nature produces read errors that must be corrected in real time. No USB flash drive ships without it.

ChipGenius is usually the better tool for the Controller info. Could you also please post a report from the Kingston for reference? It is very likely to have either Phison PS2251-03 or PS2251-07 controllers. Though I'm curious about the NAND. The 2016 DT100 G3 is right at the transition point- earlier units got Micron MLC which is decent, but later production runs and higher capacities switched to TLC, which is considerably worse for longevity. ... might explain the errors you see.