Database snapshots
Skip the weeks-to-months cold sync from genesis. Download a compressed Mainnet database snapshot, extract it into the node's output directory, and start the node from a recent height instead of block 0.
Prerequisites
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.
Choosing a snapshot
Snapshots differ by mirror location, storage engine, and included data. Choose one that matches your node's needs.
Snapshot integrityEach snapshot download directory also provides a checksum file named by appending
.md5sumto 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
| Region | Mirror | Engine | Internal transactions | TRX Balance history | Approximate size |
|---|---|---|---|---|---|
| Singapore | 34.143.247.77 | LevelDB | Excluded | Excluded | ~2.9 TB |
| US | 34.86.86.229 | LevelDB | Excluded | Excluded | ~2.9 TB |
| US | 35.197.17.205 | RocksDB | Excluded | Excluded | ~2.9 TB |
| Singapore | 35.247.128.170 | LevelDB | Included | Excluded | ~3.1 TB |
| US | 34.48.6.163 | LevelDB | Excluded | Included | ~3.6 TB |
Sizes shown are recent figures and grow over time. Always check the mirror's directory listing for current snapshot sizes before provisioning storage.
Storage engine compatibilityLevelDB and RocksDB use incompatible data formats. The snapshot's storage engine must match
storage.db.engineinconfig.conf(written asstorage { db.engine = ... }). The x86_64 architecture supportsLEVELDBandROCKSDB; ARM64 supports onlyROCKSDB. Do not start a node configured for one storage engine with a snapshot created by the other, and do not changestorage.db.enginefor 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.
| Region | Mirror | Engine |
|---|---|---|
| Singapore | 34.143.247.77 | LevelDB |
| US | 35.197.17.205 | RocksDB |
Only the two 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.
A Mainnet snapshot exceeds 2 TB. Two strategies handle this size 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
.md5sumfile 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.shThis needs roughly the size of the extracted dataset (~3 TB) on disk — about half the cost of the two-step approach.
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.tgzThis holds both the archive and the extracted files at the same time. Provision two 3 TB+ volumes — one for the archive (release after extraction completes), one for the extracted dataset.
Using the snapshot
-
If the node is running, stop the node process and confirm that it has exited completely.
-
Place the extracted dataset in the node's
output-directorynext toFullNode.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. -
Start the node. By default the node reads
./output-directory; if you placed the dataset elsewhere, add-d <path>:java -jar FullNode.jar -c config.conf -d /custom/path -
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
Updated 3 days ago