Base V2 Snapshot Tutorial: Migrate a Base Node Before October 5

Base is ending its V1 node database snapshots on October 5, 2026 at 12:00 UTC. That deadline matters even if your node is otherwise healthy: a recovery script, bootstrap job, or fresh restore that still expects the old snapshot format will stop working once Base removes the V1 files. This Base V2 snapshot tutorial walks through the safer migration path, explains when an in-place conversion is possible, and shows how to verify that the restored node is actually using the Base network.

Why Base is moving node operators to V2 storage

The change is tied to Base's move to Reth V2 storage, rather than being a cosmetic snapshot-format change. Base's July node release introduced Reth V2 snapshots and required operators to update the node software and database storage before using them. The same release documented two migration choices: download a fresh V2 snapshot or convert existing V1 data with base-reth-node db migrate-v2. The second option is restricted to archival nodes and is expected to take substantially longer than downloading a new snapshot.

There is also a separate software-version issue to account for. Base moved its release work from the old base/node repository into the base/base repository with version 1.3.0, while the September 23 v1.4.2 release became the required release for the Cobalt mainnet upgrade. In other words, changing only the database while leaving an outdated node binary in place is not a complete migration strategy.

Choose the migration path before touching your data

There are two fundamentally different situations. If you have a non-archive Base node, the practical route is to stop it, obtain a fresh V2 snapshot, and restore the node from that data. Base's own release notes say the fresh snapshot route is recommended, while the in-place migration command is not supported for non-archival nodes. If you operate an archival node and need to preserve the existing database, base-reth-node db migrate-v2 can convert the data in place, but you should plan for a longer maintenance window.

Do not treat the two methods as interchangeable. A V2 snapshot is a replacement database that you download and unpack, while migrate-v2 transforms an existing archival database. The choice affects downtime, disk usage, and how much temporary storage you need, so make the decision before deleting the old data.

Update the Base node software first

Before restoring anything, make sure the node software you are using supports the current Base network upgrades and V2 storage. The current Base release line is maintained in the base/base repository, and v1.4.2 includes the Cobalt support required for Base Mainnet. That release also includes support for Proofs V2 snapshots for nodes that serve proof requests, although that is a separate snapshot component from the execution database migration covered here.

If your deployment still references the old base/node repository or an older container image, fix that as part of the upgrade rather than treating the V2 database as an isolated change. Base's v1.3.0 release moved public node images to ghcr.io/base/node and deprecated the older base/node-reth image. The repository transition means older tutorials can contain commands and image references that no longer represent the current release structure.

Stop the node before replacing its database

If you are rebuilding from a fresh V2 snapshot, stop the running Base services before modifying their data directory. A typical Docker deployment can be stopped with docker compose down. This prevents the execution client from writing into the directory while the old database is being removed or replaced, which would leave you with a mixed data set rather than a clean V2 restore.

For a replacement restore, clear the contents of the data directory rather than deleting the directory itself if your Compose configuration expects that directory to exist. The snapshot documentation also warns that extraction can require considerably more disk space than the downloaded archive, so check available storage before beginning the restore.

Download a fresh Base V2 snapshot

For a normal Base Mainnet restore, the current snapshot tooling uses base-reth-node. The chain selector for Base Mainnet is base, while Base Sepolia uses base-sepolia. The snapshot documentation provides separate minimal and full presets, allowing an operator to choose the amount of historical data needed instead of automatically downloading the largest available database.

mkdir./reth-data base-reth-node download --minimal --datadir./reth-data --chain base --resumable

The minimal preset is useful when the node's purpose does not require the broader history retained by a full node. If your application or infrastructure depends on more historical transaction and receipt data, use the full preset instead.

base-reth-node download --full --datadir./reth-data --chain base --resumable

The --resumable option matters for large downloads because an interrupted transfer does not necessarily mean starting the entire operation again. Base's snapshot instructions also expose --download-concurrency, which defaults to 8 concurrent downloads; operators with capable hardware and network bandwidth can raise it, but increasing concurrency does not remove the need to have enough disk space for the extracted database.

Use in-place migration only for an archival database

If you deliberately operate an archival node and want to preserve its existing V1 data, the alternative is the database migration command. Run it against the stopped node's existing data rather than simultaneously running the execution client against the same directory.

base-reth-node db migrate-v2

This route is materially different from downloading a snapshot. Base's release notes state that the command is not supported for non-archival nodes and is expected to take much longer than downloading a fresh V2 snapshot. It also does not support the resumable download behavior because it is converting local data rather than fetching snapshot archives.

Start the node only after the V2 data is ready

Once the snapshot has been downloaded and extracted into the directory used by your Compose deployment, start the node again. A Docker-based deployment can use the existing Compose configuration, for example with docker compose up --build. The important point is the order: the V2 database should already be in place before the execution service begins using that directory.

docker compose up --build

Do not assume that a successful container start proves the migration worked. A node can launch while still being configured for the wrong network, an old database, or an incomplete synchronization. The next step is therefore verification rather than immediately exposing the RPC endpoint to applications.

Verify the node is on Base Mainnet and catching up

The first useful check is the Ethereum JSON-RPC method eth_chainId, which reports the network identifier used by the execution client. Base Mainnet uses chain ID 8453, represented as 0x2105 in hexadecimal, while Base Sepolia uses 84532. A different result means the node is not using the network configuration you intended, regardless of whether the process itself appears healthy.

curl -s -X POST \ -H 'Content-Type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \ http://127.0.0.1:8545

Next, inspect the node logs and confirm that the execution and rollup services are progressing rather than repeatedly restarting or remaining at the snapshot height. A snapshot gives the node a large head start, but it still has to process everything that happened after the snapshot was created. Base's current operational guidance recommends checking the logs or sync monitoring after startup instead of treating the snapshot download itself as proof that the node is synchronized.

Update disaster-recovery scripts before October 5

The October 5 cutoff has a second implication that is easy to miss: changing the production node is only half of the job. Any backup restoration procedure, bootstrap script, scheduled rebuild, or infrastructure-as-code workflow that explicitly fetches a V1 snapshot can fail later even if today's node is already running V2. Base's published deadline says V1 snapshots will no longer be published or served after October 5 at 12:00 UTC, so those references need to be changed before the cutoff rather than when the next incident happens.

That makes the safest test a recovery test, not just a version check. Build a disposable restore using the same V2 snapshot workflow your production automation will use, start the node, confirm chain ID 8453, and verify that the node continues syncing. If that procedure succeeds without depending on a V1 snapshot path, your disaster-recovery process is aligned with the storage change rather than merely your live node.

What to do if your old Base node still uses V1

If the node is still on V1 storage on October 4, do not wait for the old snapshots to disappear before planning the migration. For a non-archive node, schedule a fresh V2 restore and account for the download, extraction, startup, and catch-up time. For an archival node, compare the downtime of db migrate-v2 with the storage and bandwidth required for a fresh V2 snapshot, remembering that Base explicitly recommends the fresh snapshot route as the quicker option.

The immediate operational task is therefore straightforward: use a current Base release, choose the correct V2 snapshot profile, replace or migrate the database using the supported path, verify the chain ID and synchronization state, and then test the same restore process used by your recovery automation. After October 5, the important question will no longer be whether V1 worked yesterday; it will be whether your node and every way you rebuild it can operate entirely from the V2 storage path.