Skip to main content
Using a snapshot significantly reduces the initial time required to sync a Base node. Snapshots are updated regularly. If you’re a prospective or current Base node operator, you can restore from a snapshot to speed up your initial sync. Follow the steps below carefully.

​
Restoring from Snapshot

These steps assume you are in the cloned node directory (the one containing docker-compose.yml).
These steps use the base-reth-node CLI to download snapshots. If you don’t already have it, follow the installation instructions to install it first.
  1. Prepare Data Directory:
    • Before running Docker for the first time, create the data directory on your host machine that will be mapped into the Docker container. This directory must match the volumes mapping in the docker-compose.yml file.
    • If you have previously run the node and have an existing data directory, stop the node (docker compose down), remove the contents of the existing directory (e.g. rm -rf ./reth-data/*), and proceed.
  2. Choosing the chain: Use the --chain flag to select the network
  3. Download Snapshot: Choose the appropriate snapshot for your network and client from the table below.
    Ensure you have enough free disk space to download the snapshot and extract its contents. The extracted data will be significantly larger than the archive.
    Alternatively, for archival nodes only, you may run base db migrate-v2. However, this is expected to take much longer than downloading. --resumable is also not supported in migrate-v2.
  4. (Optional) - tuning download concurrency: The --download-concurrency flag controls how many simultaneous HTTP downloads run across the whole snapshot job. It defaults to 8, which is a good baseline for most machines. If you have high-end hardware, you can safely increase it to speed up the download. A good rule of thumb is 2× the number of physical CPU cores:
  5. Start the Node: Now that the snapshot data is in place, return the root of your Base node folder and start the node:
    Your node should begin syncing from the last block in the snapshot.
  6. Verify: Monitor the node logs (docker compose logs -f <service_name>) or use the sync monitoring command to ensure the node starts syncing from the snapshot’s block height.

​
Proofs Snapshots

V2 Proofs Snapshots are coming soon.
If you are running the historical proofs ExEx, snapshots of the proofs database are available to skip the 24-48 hour backfill. Proofs snapshots are still distributed as archives, so you’ll need aria2c, a resumable downloader that handles the periodic connection interruptions imposed by Cloudflare. If you don’t have it installed:
Ensure you have enough free disk space to download the snapshot archive (.tar.gz / .tar.zst file) and extract its contents. The extracted data will be significantly larger than the archive.
Once downloaded, extract the archive. Replace snapshot-filename with the actual downloaded filename:
The extraction process will likely create a reth directory. Move the contents of that directory into the data directory you created in Prepare Data Directory in the section above:
The goal is to have the chain data directories (e.g., chaindata, nodes, segments, etc.) directly inside ./reth-data, not in a nested subfolder. Once confirmed, you can safely delete the downloaded snapshot archive (.tar.gz file) to free up disk space. Then continue from Start the Node in the section above.

​
FAQ

In Reth, a “full” node is just a pruned node with a specific preset rather than a distinct node type. Reth’s --full preset retains the last 10,064 blocks (~1.4 days on Ethereum; ~5-6 hours on Base due to faster block times).Base’s --full snapshot uses a 31-day rolling retention window instead. If a smaller storage footprint is preferred, you can override reth.toml to match the 10,064-block preset.