Bitcoin node disk full: how to recover

When the filesystem fills, Bitcoin Core shuts itself down rather than risk a half-written block. The wrong response, deleting files in blocks/, can cost you a full resync. The right one takes a few minutes.

What a full disk looks like

$ journalctl -u bitcoind -n 5 --no-pager
*** Disk space is too low!
Error: Disk space is too low!
systemd[1]: bitcoind.service: Main process exited, code=exited, status=1/FAILURE

If the node is not running, bitcoin-cli fails with Could not connect to the server 127.0.0.1:8332. Check the service and the disk before assuming anything else.

$ df -h /var/lib/bitcoind
$ sudo du -sh /var/lib/bitcoind/blocks /var/lib/bitcoind/chainstate 2>/dev/null
$ systemctl status bitcoind --no-pager

Want to see this failure and the recovery before it happens to you? The lab has a disk-full scenario.

Path A: grow the disk

Home: stop Core, clone to a bigger NVMe or add a drive and move the datadir (path C). VPS: attach a volume or resize the disk per your provider, then grow the filesystem. Resizing in place keeps the datadir, so nothing is re-downloaded.

Path B: switch to pruning

Best when you do not need old blocks and the disk cannot grow. This is one-way: going back to full means re-downloading.

1. Stop Core: sudo systemctl stop bitcoind
2. If the disk is at 100%, free a few GB elsewhere first. Core needs room to start.
3. Add prune=550 to /etc/bitcoin/bitcoin.conf. Remove txindex=1 if present; the two cannot be combined.
4. Start Core and check:

$ sudo systemctl start bitcoind
$ bitcoin-cli getblockchaininfo | grep -E 'pruned|size_on_disk'
  "size_on_disk": 12304711680,
  "pruned": true,
$ df -h /var/lib/bitcoind

Core trims old block files after it starts, so free space may take a few minutes to appear. What pruning does and costs: pruned vs full.

Path C: move the datadir

For a small OS disk with a large second volume. The systemd unit from the setup guide passes -datadir=/var/lib/bitcoind on the command line, and command-line options override bitcoin.conf (doc/init.md), so a datadir= line in the config file is ignored. Mount the new disk at /var/lib/bitcoind instead. The path stays the same, so the unit, the bitcoin-cli alias and Sparrow's cookie path keep working. The disk must already have a filesystem (ext4 here).

$ sudo systemctl stop bitcoind
$ sudo mount /dev/BIGDISK /mnt
$ sudo rsync -a /var/lib/bitcoind/ /mnt/
$ sudo umount /mnt
$ sudo mv /var/lib/bitcoind /var/lib/bitcoind.old
$ sudo mkdir /var/lib/bitcoind
$ sudo blkid /dev/BIGDISK

Put the UUID that blkid printed into /etc/fstab, then mount and start:

UUID=YOUR-UUID  /var/lib/bitcoind  ext4  defaults  0  2

$ sudo systemctl daemon-reload
$ sudo mount /var/lib/bitcoind
$ sudo systemctl start bitcoind
$ bitcoin-cli getblockchaininfo | grep -E 'blocks|headers'
$ df -h /var/lib/bitcoind

Leave out nofail in the fstab line. If the disk is missing at boot you want the boot to stop, because otherwise Core would start a second sync on the OS disk. Delete /var/lib/bitcoind.old only after the node syncs normally. RPC stays local-only after a move; see security basics.

Sizing

These drift. size_on_disk in getblockchaininfo is your real number. For drives, see hardware.

Prevention

• Pick pruned or full before the first sync fills the disk
• Run df -h weekly (maintenance)
• Keep media and backups off the chain disk
• On a VPS, attach the big volume before the first sync

Syncing stalled but the disk has room? See sync stuck. Third-party chain snapshots to "save time" are not a recovery option; see the AssumeUTXO note there.

FAQ