Database snapshots

📘

Prerequisites

• Nodes overview
• Deploy a node

A database snapshot is a compressed dump of a TRON node's database at a recent block height. Bootstrapping a new node from a snapshot takes hours instead of the weeks-to-months cold sync from genesis. Snapshots are produced periodically by the TRON community and hosted on public download mirrors.

This page lists current snapshot mirrors, explains the download options, and walks through using a snapshot during node start-up.

📘

GreatVoyage-v4.8.2 backup configuration change

java-tron removed the built-in RocksDB backup feature configured by storage.backup.*. For self-managed backups, use a consistent database snapshot or an external backup workflow. Do not remove the still-supported node.backup configuration: it coordinates active and standby roles among multiple block-producing instances for the same SR. Only the instance elected MASTER participates in block production; this configuration does not back up the database.

Choosing a snapshot

Snapshots differ by mirror location, storage engine, and included data. Choose one that matches your node's needs.

⚠️

Snapshot integrity

Each snapshot download directory also provides a checksum file named by appending .md5sum to the archive filename. After downloading the complete archive, verify its integrity as described below before extracting it. Do not extract or use a snapshot that fails verification.

Fullnode snapshots

The table records the displayed size of FullNode_output-directory.tgz provided by each mirror on the date shown; it is not the extracted database size. Archives grow over time, so check the directories and file sizes currently available on each mirror before downloading.

⚠️

Storage engine compatibility

LevelDB and RocksDB use incompatible data formats. The snapshot's storage engine must match storage.db.engine in config.conf (written as storage { db.engine = ... }). The x86_64 architecture supports LEVELDB and ROCKSDB; ARM64 supports only ROCKSDB. Do not start a node configured for one storage engine with a snapshot created by the other, and do not change storage.db.engine for an existing data directory; otherwise, the node may be unable to read the data or the data directory may be corrupted.

Lite Fullnode snapshots

A Lite Fullnode snapshot contains only the current state plus the most recent 65,536 blocks (RECENT_BLKS in DbLite.java) — typically a few percent of a Fullnode dataset. See Lite Fullnode for what's included and how to choose between Fullnode and Lite Fullnode.

📘

The four Lite Fullnode snapshot download locations listed above are currently available.

If download performance is poor, use the Lite Fullnode pruning tool to generate a Lite Fullnode snapshot from a healthy local Fullnode.

Downloading and extracting

⚠️

Note:

Mainnet snapshots are distributed as large single-file archives. To protect mirror availability, the download servers restrict concurrent connections. Use a single-threaded download tool; concurrent segmented downloads may result in a 404 Not Found response.

The current Mainnet Fullnode compressed archives are approximately 3.3–4.4 TB. The extracted database requires additional space. Two download strategies handle this differently:

Streamed download and extract (saves disk space)

Download and extract simultaneously without ever storing the compressed archive on disk:

Streamed download extracts the archive while it is being downloaded, so the complete archive cannot be checked against its .md5sum file before extraction. Use "Full download then extract" when verification must be completed first.

#!/bin/bash
wget -q -O - SNAPSHOT_URL/FullNode_output-directory.tgz | tar -zxvf -

Replace SNAPSHOT_URL with the URL of the directory containing the snapshot file, without the archive filename. Save the script as download_snapshot.sh and run it:

bash download_snapshot.sh

This avoids storing the complete compressed archive, but the destination must still have enough space for the extracted dataset. The table lists compressed archive sizes, not extracted capacity; check available space and leave room for continued database growth before downloading.

Full download then extract (more disk required)

# 1. Download the compressed archive and its MD5 checksum file
wget SNAPSHOT_URL/FullNode_output-directory.tgz
wget SNAPSHOT_URL/FullNode_output-directory.tgz.md5sum

# 2. Verify integrity; continue only if the result is OK
md5sum -c FullNode_output-directory.tgz.md5sum

# 3. Extract
tar -zxvf FullNode_output-directory.tgz

This holds both the archive and the extracted dataset at the same time. Based on the current largest archive of 4,384 GB, provision at least 5 TB for the archive and a separate destination large enough for the complete extracted database plus continued growth. The archive can be deleted after extraction.

Using the snapshot

1. If the node is running, stop the node process and confirm that it has exited completely.

2. Place the extracted dataset in the node's output-directory next to FullNode.jar (or in a custom directory). Before placing the snapshot, make sure that no data directory with the same name exists at the destination; move the old directory elsewhere first if it must be retained. Do not extract a snapshot over an existing data directory or replace database files while the node is running.

3. Start the node. By default the node reads ./output-directory; if you placed the dataset elsewhere, add -d <path>:

   Bash

   java -jar FullNode.jar -c config.conf -d /custom/path

4. The node syncs the gap between the snapshot's height and the current Mainnet head — usually a few hours of catch-up rather than days from genesis.

For the full deployment workflow, see Deploy a node.

Related resources

• Deploy a node — End-to-end deployment, including how to start with a snapshot
• Nodes overview — Fullnode vs Lite Fullnode comparison
• Node maintenance toolkit — Pruning, splitting, and merging databases