Setting up an Ethereum archive node: Erigon, Reth, Arbitrum

Why an Ethereum archive node stops responding to requests

An Ethereum archive node responds to historical requests to the blockchain for any block — the state at a specific height, the balance of an address before its first movement, the result of a contract call that no longer exists.

Auditing, analytics, and transaction reconciliation are built on this. But it stops being an archive node quietly: the access point is open, the node is on the network, and requests to old blocks return an error about a missing state node.

The first cause is the storage mode. By default, the client treats state as derivative and deletes historical branches so as not to grow indefinitely. The node synchronizes, responds to fresh requests, and looks healthy until someone requests a block from the past.

A related issue is a break in node synchronization: an interrupted process, when connections are lost or the node is restarted, does not continue from where it left off but rolls back.

The second cause is disk. An archive configuration turns the load into a stream of random reads by state keys, and disk I/O degradation shows up before space runs out.

The node is formally running, but response latency grows, requests time out — and transaction archive unavailability occurs without a single error in the logs.

The third is planning: the history turns out to be larger than planned, disk goes to zero, and the service falls exactly when reindexing takes days.

We look at how this is addressed: which storage profile to choose for Erigon and Reth, how to separate an archive node from a regular one, and what to monitor so that failure is visible in advance rather than from an analyst's complaint.

What changes after correct archive synchronization

An archive node differs from a full node not in disk volume, but in that state is retained for every block. If synchronization was done incorrectly, requests to old blocks go through rollback and re-execution instead of reading from disk.

Hence tens of seconds per call, timeouts at the indexer, and a queue that grows faster than traffic arrives.

After correct archive assembly, three measurable things change. Historical request response speed reaches single-digit seconds on the first warm-up and fractions of a second on repeated accesses — state is read directly.

Under parallel load, the latency profile is even: the tail does not spread when analytics, a block explorer, and internal services access the node simultaneously.

Restart stops being an event. The node comes up on already assembled state and catches up only the latest blocks rather than replaying history from scratch. We build archives on Erigon and run exactly this scenario — stop, start, return to service without manual operations.

Transaction history completeness is a separate result: traces, receipts, and internal transfers are available for the entire period, without gaps in block ranges. This is exactly what reports, auditing, and balance recovery for an arbitrary date are built on.

Data storage modes: archive, full, and light

The storage mode determines what part of state history the node serves on request. Archive mode retains state at every block height, a full node keeps current state and block history, and a light node keeps only headers and proofs.

This determines which requests you serve yourself and which ones will require connecting external data sources.

The difference is noticeable not at the "latest block", but at the depth of the request.

Calculating historical balances, reconciling contract events, auditing transactions, and reindexing require state at a specific height — a full node responds to such a request with an error, not outdated data.

That is why the mode is fixed before initial synchronization: switching on a running node means reloading the chain.

The mode and execution client are chosen together: not every client supports archive storage equally fully and serves historical states through the standard interface. We verify this on a test chain before deployment so as not to reload the main one.

Node deployment and synchronization stages

Deploying an archive node is not "download the client and run it", but a sequence where an error at an early step costs weeks of re-synchronization. Below is the order of work we follow for a project from assessment to handover to operation.

1. Assessment. We record the networks and archive depth: whether full historical state is needed, only logs, or also traces. We calculate the load profile — the share of eth_getLogs and debug_trace* requests for historical blocks, and the target number of concurrent connections. This determines both the client and the disk requirements.
2. Design. We choose the execution client for the task: Erigon — when compact storage and deep history matter more, Reth — when catch-up speed and RPC responsiveness are the priority. We design an Arbitrum node separately if access to L2 history is needed. Here we also define the disk layout for data, logs, and snapshots.
3. Storage preparation. Partitioning and mounting with the required block size and headroom for growth, configuring descriptor limits, swap file, and compression policy. We design storage so that the registry does not grow avalanche-like and headroom remains for future blocks.
4. Installation and initial load. We deploy the client in an isolated environment and connect a snapshot instead of synchronizing from scratch — this reduces time to reach the current height from weeks to hours.
5. Archive synchronization. We carry out catch-up to the network head, monitoring block processing speed and lag. At this stage it is clear whether the configuration is limited by disk or network — parameters are adjusted before the final state.
6. Integrity check. We compare the root state with a public source, execute test requests to historical blocks, and compare responses at several heights. We also check restart behavior: the node must come up without re-synchronization.
7. Monitoring and handover. We connect metrics collection and alerts for lag and RPC errors, and restrict access to heavy methods. We hand over access credentials, the client update policy, and snapshot recovery instructions.

Configurations, diagrams, and maintenance policies

An archive node should not remain a "black box" that only the person who built it can maintain.

We hand over to the customer a set of artifacts that allows the node to be raised from scratch, synchronization correctness to be checked, and support to be handed to another team — without retellings from memory.

• Configuration files — client parameters (Erigon, Reth): state storage mode, cache and connection limits, archive depth. Each value is commented so that edits can be made without us.
• Infrastructure diagram — a map of services, storages, and network zones, failure points and dependencies between them, and role distribution across nodes.
• Access policies — who accesses JSON-RPC and with which key, what is exposed externally, how keys are issued and revoked, and where requests are logged.
• Maintenance policy — frequency of client updates, database integrity checks, re-synchronization procedure when state diverges, and maintenance windows.
• Monitoring and alerts — metrics for network lag, archive depth, and free space, and the thresholds at which the on-call engineer is alerted.
• Standard operating procedures — taking a storage snapshot, switching to a backup node, and rolling back to a previous client version.
• Node documentation — change log, responsible parties, history of incidents and decisions made.

The set remains with the customer and is updated together with the infrastructure: configuration changes, adding a node, or changing the access policy are reflected in the documentation the same day.

After that, the direction can be developed in-house or handed to another contractor — the entry barrier will be low.

Archive migration without service downtime: what changed

The production node kept only current states: history pruning was enabled, so requests deeper than the latest blocks went to external sources or timed out.

Analytics on old contracts and transaction reconciliation waited seconds for a response, and at peaks the node could no longer keep up with the flow. Some checks simply did not run — gaps remained in reporting.

The blockchain node migration was built without a downtime window. We deployed Erigon in archive mode on a separate server: it caught up with the network and collected state snapshots while the production node continued serving traffic.

The switch was done at the load balancer — first history reads were moved, then the remaining requests.

Metrics before and after

Availability during work was preserved: service interruption was zero, and rollback to the previous node remained possible until the end of the switch.

Historical request response time was reduced to fractions of a second, and history depth grew from the latest blocks to the entire chain. External sources no longer participate in responses — the archive is served by the in-house node.

What to do if synchronization has already been running for weeks?

Weeks of synchronization are almost always not "slow internet", but a specific bottleneck. The process should be divided into stages: block catch-up, state recovery, index building, and integrity checking. You can get stuck at any of them, and each is treated differently.

Most often it is limited by disk. An Ethereum archive node simultaneously appends fresh state and reads historical slices, so the load on the storage device grows with chain height.

If state recovery takes days while the network is calm, changing the channel is pointless — we look at the I/O profile.

Acceleration comes from removing resource contention, not from a single flag: more cache for state, more threads for recovery, and during catch-up — dropping unnecessary indexes and external calls to the node.

Erigon and Reth behave differently, so parameters are selected for the chosen implementation rather than copied from someone else's config.

Rebuilding the archive is worth it when state is corrupted, indexes do not match, or the lag is measured in epochs — then it is faster to restore state from a trusted source snapshot and catch up the remainder over the network.

Changing the storage mode is justified when deep history is needed for one-off checks rather than an application: a pruned node plus a separate indexer cover the same task with less volume and come back up much faster after a failure.

We start with diagnostics: we collect metrics by stage, find the bottleneck, and only then propose a rebuild or a mode change. That way, downtime days are not spent on repeated synchronization attempts.

Technical concerns: storage, fault tolerance, access

An archive node stores state at all heights, so the disk grows with the chain and outpaces a regular observer node many times over. Clients like Erigon and Reth differ in storage model: one database is larger but cheaper in disk operations, the other is more compact.

We calculate headroom from the current block-fill rate, not from average figures in the documentation.

What happens to the node in case of failure?

We keep two instances: one synchronizes, the other serves requests. A liveness check removes a crashed process from the load balancing within seconds, and a lagging instance does not return responses until it catches up to the height.

How is access to the node restricted?

The request interface listens only on the private network; a gateway is exposed externally with a restricted set of methods and rate limiting. Debug and admin calls are closed, and the node is not included in public transaction exchange.

How is backup structured?

Copying the database directory on a running node is not allowed — it will produce an inconsistent snapshot.

A volume snapshot with log replay results in a discrepancy of minutes; the last few snapshots are stored on a separate volume, and we test rollback in advance on a test node.

Let's discuss the task: assessment, plan, and work order

An estimate for an archive node is not made by eye: a full archive from genesis and a node with a limited history window have different requirements for disks, initial synchronization time, and the backup scheme. To come back with a plan, not a random range, we need input on the load and infrastructure.

• Load profile: which RPC methods are called, how many concurrent clients, whether history from genesis is needed or a window of recent blocks is enough.
• Where we deploy: own servers, cloud, or hybrid, available storage volume and disk type, network bandwidth.
• Client and synchronization mode: Erigon or Reth for your profile, start from a snapshot or from genesis, acceptable downtime window.
• Access and perimeter: keys, private network, a separate node for RPC traffic, address restrictions.
• Statement of work: scope of work and acceptance criteria — lag from the chain head, request response time, behavior on disk failure.
• Implementation plan: deployment, rehearsal on a test network, switchover window, tested rollback scenario.
• Node maintenance: monitoring with alerts, client updates without downtime, snapshots with recoverability checks, and on-call incident response.

Describe the task and the current setup — we will come back with a stage-by-stage estimate, an implementation plan, and a support option after launch.