Bitcoin node disk full — pruned recovery

Disk pressure is the most common operational failure after “sync looks stuck.” Bitcoin Core will eventually refuse to advance if the filesystem fills. The wrong fix — deleting files under blocks/ — can cost you a full resync. This guide covers safe recovery, what prune= actually does, and how to size home vs VPS storage. Pair with pruned vs full for the trust model.

First response when the disk is full

1. Stop Bitcoin Core cleanly: bitcoin-cli stop or systemctl stop bitcoind
2. Confirm which filesystem holds the datadir: df -h ~/.bitcoin
3. Do not rm block or chainstate files by hand
4. Choose one recovery path: expand volume, move datadir, or enable prune — then restart

$ bitcoin-cli stop
$ df -h ~/.bitcoin
$ du -sh ~/.bitcoin/blocks ~/.bitcoin/chainstate 2>/dev/null
$ journalctl -u bitcoind -n 50 --no-pager

What prune mode really does

With prune=N (target size in MiB for block files), Core validates blocks then deletes older block files while keeping the UTXO set and enough recent blocks. Consequences:

• You still perform IBD bandwidth once
• You cannot serve historical blocks to peers (or rescan arbitrarily old wallet history the same way a full node can)
• You still independently validate consensus rules

For most personal verification use cases, pruned is enough. If you need full history locally, budget ~1TB class storage in mid-2026 and revisit sizes quarterly — chain growth does not stop. Details: pruned vs full.

# Example: keep roughly 550 MiB of block files (plus chainstate/OS)
prune=550

# RPC stays local
rpcallowip=127.0.0.1

After enabling prune on an existing full datadir, Core will prune down on restart as it can. Always stop cleanly before editing conf. Sample configs also live in setup.

Recovery path A — expand the disk

Home: clone to a larger NVMe, or attach a second drive and move the datadir (datadir= in conf or symlink with care). Prefer copying with Core stopped.

VPS: attach a volume, grow the filesystem, or resize the instance disk per provider docs. Budget IBD bandwidth again only if you wipe; expanding in place preserves the datadir. See VPS disk math.

Recovery path B — enable prune

Best when you do not need full history and the volume cannot grow cheaply. Steps:

1. Stop Core
2. Add prune=550 (or higher if you want more recent blocks retained)
3. Ensure free space exists for Core to operate during prune (a completely 100% full disk may need a few GB freed from unrelated files first — logs, old downloads — not chain files)
4. Start Core and monitor getblockchaininfo for pruned: true

$ sudo systemctl start bitcoind
$ bitcoin-cli getblockchaininfo | grep -E 'prune|size_on_disk|verificationprogress'
$ df -h ~/.bitcoin

Recovery path C — move the datadir

When the OS disk is tiny (common on cheap VPS and some appliances):

1. Stop Core
2. Copy ~/.bitcoin to the large volume (preserve permissions/ownership)
3. Point datadir=/path/on/large/disk in bitcoin.conf or adjust your systemd unit
4. Start and verify with getblockchaininfo

Keep RPC localhost-only after the move — security checklist: security basics.

Sizing cheat sheet (mid-2026)

Prices and exact sizes change — check your node’s size_on_disk and vendor storage listings. Hardware picks with real IO notes: hardware.

Prevention

• Weekly df -h on the datadir filesystem — maintenance checklist
• Decide prune vs full before IBD finishes filling the disk
• On VPS, attach the large volume before first sync when possible
• Keep unrelated media/backups off the chain disk

More diagnostics: commands. If progress stalled for reasons other than disk, read sync stuck.

After recovery: verify before you relax

When the node is running again, confirm three things: getblockchaininfo responds, df -h shows comfortable free space, and logs are not spamming write errors. Then add the weekly disk glance to your maintenance habit so the next fill-up is a warning, not an outage.

If you enabled prune under pressure, write down that choice. Future-you may wonder why historical getblock calls fail for old heights. That is expected on pruned nodes — not corruption. Re-read pruned vs full before spending money on a second 2TB drive you might not need.

Snapshots and “fast sync” offers

Third-party chain snapshots can look attractive when the disk is tight and patience is gone. Unsigned or sketchy sources defeat the point of running a node. Even signed AssumeUTXO-style shortcuts are advanced and still need careful verification. When in doubt, expand disk or prune using Core’s own tools, then finish IBD honestly.

FAQ