Snapshots

Restoring from a snapshot drastically reduces initial Base node sync time. Snapshots are refreshed regularly.

Whether you’re planning to run a Base node or already operate one, seeding from a snapshot lets you skip most of the initial sync. Work through the steps below carefully.

Restoring from a snapshot

These steps assume you’re working from the cloned node directory — the one that holds docker-compose.yml.

Prepare the data directory.
- Before launching Docker for the first time, create the host directory that will be mapped into the container. The path must match the volumes entry in docker-compose.yml:
  Terminal window
```
mkdir ./reth-data
```
- If a previous run left an existing data directory, stop the node first (docker compose down), wipe the contents (for example, rm -rf ./reth-data/*), then continue.
Choose the chain. Select the network with the --chain flag:

Network --chain value
Base Mainnet base
Base Sepolia base-sepolia

Network	`--chain` value
Base Mainnet	`base`
Base Sepolia	`base-sepolia`

Download the snapshot. V2 snapshots are no longer a single archive — they’re broken into many small, segmented files. The CLI advertises just one archive snapshot because it holds every file; full and minimal simply pull progressively smaller subsets of it. Pick the configuration that fits your node from the table below.

Config	Flag	What you get	Use when
Minimal	`--minimal`	The leanest bootable set: current state and headers, carrying only the history that’s strictly required.	Best when you want the quickest, lightest download and have no need for historical data.
Full	`--full`	Everything a default full node prunes down to — state, headers, and a capped span of recent transactions, receipts, and history.	Best for running an ordinary full node without holding the entire archive.
Archive	`--archive`	The complete dataset — every transaction, receipt, and account/storage record, with nothing pruned.	Best when you need the full history, such as for archive queries or indexing.

These three presets are just the ready-made defaults published at chain.base.org/snapshots. If none of them matches your retention needs, you can still supply custom pruning flags via the pruning flag — but to do so you must pull the archival snapshot first and then apply your own pruning arguments on top of it.

# Minimal node on Base Mainnet
base-reth-node download --minimal --datadir ./reth-data --chain base --resumable

# Full node on Base Sepolia
base-reth-node download --full --datadir ./reth-data --chain base-sepolia --resumable

For archival nodes only, you can alternatively run base db migrate-v2 — but expect it to take much longer than a download, and note that --resumable is not supported by migrate-v2.

(Optional) Tune download concurrency.

The --download-concurrency flag governs how many HTTP downloads the snapshot job runs at once. Its default of 8 is a solid baseline for most machines.

On high-end hardware you can raise it to speed things up. A reasonable rule of thumb is 2× the number of physical CPU cores:
Terminal window
```
# Example: a 16 physical-core machine
base-reth-node download --full --datadir ./reth-data --chain base --download-concurrency 32
```
Start the node. With the snapshot data in place, return to the root of your Base node folder and bring it up:
Terminal window
```
cd ..
docker compose up --build
```
The node should pick up syncing from the last block recorded in the snapshot.
Verify. Tail the logs (docker compose logs -f <service_name>) or use the sync monitoring command to confirm the node starts at the snapshot’s block height.

Proofs snapshots

If you run the historical proofs ExEx, proof database snapshots are available so you can skip the 24-48 hour backfill.

Because proofs snapshots are still packaged as archives, grab aria2c first — it’s a resumable downloader that gracefully recovers from the periodic connection drops Cloudflare imposes on long transfers. If it isn’t already installed:

# macOS
brew install aria2

# Ubuntu / Debian
sudo apt-get install aria2

Network	Download command
Testnet	`aria2c -c -x 16 -s 16 "https://sepolia-reth-proofs-snapshots.base.org/$(curl -s https://sepolia-reth-proofs-snapshots.base.org/latest)"`
Mainnet	`aria2c -c -x 16 -s 16 "https://mainnet-reth-proofs-snapshots.base.org/$(curl -s https://mainnet-reth-proofs-snapshots.base.org/latest)"`

With the download complete, unpack the archive — swap snapshot-filename for the file you actually pulled:

tar -xzvf <snapshot-filename.tar.gz>

# For .tar.zst
tar -I zstd -xvf <snapshot-filename.tar.zst>

Extraction typically produces a reth/ directory. Move its contents into the data directory you created back in Prepare the data directory:

mv ./reth/* ./reth-data/
rm -rf ./reth    # remove the now-empty extracted folder

The chain data subdirectories (chaindata, nodes, segments, etc.) must sit directly under ./reth-data, not in a nested folder. Once that’s confirmed, you can delete the downloaded archive (.tar.gz) to reclaim disk space, then pick back up from Start the node above.

FAQ

How does Base’s Full snapshot retention compare to Reth’s --full preset, and why the difference?

In Reth, “full” is not a separate node type — it is just a pruned node configured with a specific preset. Reth’s --full preset keeps the most recent 10,064 blocks, which is roughly 1.4 days on Ethereum but only about 5-6 hours on Base because of the faster block cadence.

Base’s --full snapshot instead uses a 31-day rolling retention window. If you want a smaller on-disk footprint, you can override reth.toml to match the 10,064-block preset.

I’m seeing “Archive extracted, but output verification failed.” What went wrong?

Almost always this means a fresh snapshot was published while your download was in flight. Stop the download command and start it again — it’s idempotent, so it won’t re-pull files already on disk and will only fetch the delta.