What 36 Months of Running a Bitcoin Full Node Will Do to Your Hardware
Or to be precise, to your storage
On a rainy Singaporean morning three years ago, I set up my first Bitcoin full node. It was a modest setup — a small 1L PC tucked away in my home office, quietly validating transactions and supporting the network. That little machine dutifully processed blocks for about 6 months until I made what seemed like a sensible upgrade: virtualizing the node on one of my XCP-ng hypervisors.
The decision to migrate to a VM made perfect sense at the time. All my hypervisors run on Supermicro hardware with IPMI access on a separate VLAN, making remote management much easier. During maintenance windows, I could live-migrate the VM without downtime. And perhaps most importantly, if hardware failed, high availability would seamlessly transfer the workload to another hypervisor.
Little did I realize that this infrastructure decision would eventually reveal an overlooked aspect of running a Bitcoin node: the relentless wear on storage devices.
The Storage Setup and Unexpected Failure
For nearly two years, my Bitcoin node VM had been consuming storage from a “hybrid” ZFS mirror pool combining one NVMe SSD and one SATA SSD see this previous article.
This wasn’t an enterprise-grade setup by any means, but rather a pragmatic use of leftover drives from the original bare metal build. The performance was more than adequate for a Bitcoin node, which doesn’t demand the consistent IOPS needed for database or VM workloads.
A few weeks ago, however, the SATA SSD failed. This unexpected event prompted me to take a closer look at the remaining NVMe drive’s health.
The Revealing SMART Data
$ sudo smartctl --all /dev/disk/by-id/nvme-CT2000P3PSSD8_2239E66E634E
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-138-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: CT2000P3PSSD8
Serial Number: 2239E66E634E
Firmware Version: P9CR40A
PCI Vendor/Subsystem ID: 0xc0a9
IEEE OUI Identifier: 0x00a075
Controller ID: 1
NVMe Version: 1.4
Number of Namespaces: 1
Namespace 1 Size/Capacity: 2,000,398,934,016 [2.00 TB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 6479a7 6bd0000213
Local Time is: Wed Apr 30 21:09:08 2025 +08
Firmware Updates (0x12): 1 Slot, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005e): Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x06): Cmd_Eff_Lg Ext_Get_Lg
Maximum Data Transfer Size: 64 Pages
Warning Comp. Temp. Threshold: 85 Celsius
Critical Comp. Temp. Threshold: 95 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 6.00W 0.0000W - 0 0 0 0 0 0
1 + 3.00W 0.0000W - 0 0 0 0 0 0
2 + 1.50W 0.0000W - 0 0 0 0 0 0
3 - 0.0250W 0.0000W - 3 3 3 3 5000 1900
4 - 0.0030W - - 4 4 4 4 13000 100000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 1
1 - 4096 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 51 Celsius
Available Spare: 100%
Available Spare Threshold: 5%
Percentage Used: 91%
Data Units Read: 249,544,614 [127 TB]
Data Units Written: 1,197,336,677 [613 TB]
Host Read Commands: 4,181,009,073
Host Write Commands: 22,736,679,377
Controller Busy Time: 183,645
Power Cycles: 101
Power On Hours: 20,527
Unsafe Shutdowns: 43
Media and Data Integrity Errors: 0
Error Information Log Entries: 176
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 51 Celsius
Temperature Sensor 2: 53 Celsius
Temperature Sensor 8: 51 Celsius
Error Information (NVMe Log 0x01, 16 of 16 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 176 0 0x601a 0x4005 0x028 0 0 -
Analyzing the Wear Pattern
The SMART data reveals some remarkable statistics. After 36 months of running a Bitcoin full node, the NVMe drive has:
- Written a staggering 613TB of data
- Read about 127TB of data
- Processed over 22.7 billion write commands
- Consumed 91% of its total write endurance
To put this in perspective, this Crucial P3 NVMe drive has endured an average of 17TB of writes per month or roughly 204TB per year. This is an astonishing amount of write activity for a home server workload.
The write-to-read ratio of nearly 5:1 illustrates the write-intensive nature of running a Bitcoin node. While the blockchain itself grows linearly (currently at ~600GB), the node constantly updates its UTXO set and other database structures, resulting in significantly more write operations than you might initially expect.
The Broader Implications
For comparison, my daily-driver workstations with similar NVMe drives typically see about 15TB of writes per year — less than 10% of what the Bitcoin node generates.
The Crucial P3 spec sheet gives 440TBW of write endurance for the 2TB sku. With 613TB already written, the drive has significantly exceeded its rated endurance of 440TBW. Crucial however seems to integrate a good deal of safety margin, as we can see from the 91% wear indicator.
Clearly, Enterprise SSDs with endurance ratings in the thousands of TBW would be far better suited to this workload - and more economical on the long term.
Lessons Learned and Solutions
This experience has taught me a valuable lesson about running infrastructure at home: not all workloads are created equal. While consumer hardware is perfectly adequate for many homelab applications like Home Assistant or media servers, blockchain nodes present unique challenges due to their constant database updates.
204TB of writes per year is actually well in excess of some of the workloads I see with SMB/SME infrastructures at work.
For sustainable operation, Bitcoin full nodes need more durable storage solutions. I’ve since switched to using “refurbished” enterprise-grade SSDs for my node. These drives offer several advantages:
- Higher endurance ratings: Enterprise SSDs often have 3-10x the write endurance of consumer drives
- Better power loss protection: Critical for preventing blockchain database corruption
- More conservative wear leveling algorithms: Extending practical lifespan
- Cost-effectiveness: Refurbished enterprise SSDs with 90% life remaining can often be found for a fraction of their original price
A “gently used” enterprise SSD with only 10% wear consumed will typically have substantially more write cycles remaining than a brand-new consumer drive. This makes them ideal candidates for write-intensive applications like blockchain nodes.
Conclusion
Running a Bitcoin full node is a rewarding way to support the network and maintain sovereignty over your transaction verification, but it comes with hidden costs. Storage wear is a critical factor that’s easily overlooked when planning such systems.
If you’re running or planning to run a Bitcoin node, consider investing in enterprise-grade storage from the start - even refurbished, or at minimum, budget for 2-year replacement of consumer SSDs. Your future self will thank you when you’re not scrambling to replace failed drives and potentially dealing with node resynchronization.
In a future article, I’ll dive deeper into sourcing and evaluating used enterprise SSDs — because oftentimes, yesterday’s enterprise castoffs make the perfect foundation for today’s home infrastructure or even a DR site.