Sync node using snapshots - Polygon Developer Docs

Use snapshots to sync a new node in hours rather than days. This applies to sentry, validator, and full nodes for both Heimdall and Bor.

Community snapshots

Polygon Chain has transitioned to a community-driven model for snapshots. Active community members now contribute to provide snapshots. Some of these members include:

Name	Available snapshots	Note
Stakecraft	Mainnet, Amoy, Erigon	Support for Erigon archive snapshot
PublicNode (by Allnodes)*	Mainnet, Amoy	Support for PBSS + PebbleDB enabled snapshot
Stakepool	Mainnet, Amoy	-
Vaultstaking	Mainnet	-
Girnaar Nodes	Amoy	-

*The PBSS + PebbleDB snapshot provided by PublicNode is currently in the beta phase.

Visit All4nodes.io for a comprehensive list of community snapshots.

Downloading and using client snapshots

To begin, ensure that your node environment meets the prerequisites outlined here. The majority of snapshot providers have also outlined the steps that need to be followed to download and use their respective client snapshots. Navigate to All4nodes to view the snapshot source. In case the steps are unavailable or the procedure is unclear, the following tips will come in handy:

You can use the wget command to download and extract the .tar snapshot files. For example:

wget -O - snapshot_url_here | tar -xvf -C /target/directory

Configure your client’s datadir setting to match the directory where you downloaded and extracted the snapshot data. This ensures the systemd services can correctly register the snapshot data when the client is spun up.
To maintain your client’s default configuration settings, consider using symbolic links (symlinks).

Example

Let’s say you have mounted your block device at ~/snapshots and have downloaded and extracted the chain data into the heimdall_extract directory for Heimdall, and into the bor_extract directory for Bor. Use the following commands to register the extracted data for Heimdall and Bor systemd services:

# remove any existing datadirs for Heimdall and Bor
rm -rf /var/lib/heimdall/data
rm -rf /var/lib/bor/data/bor/chaindata

# rename and setup symlinks to match default client datadir configs
mv ~/snapshots/heimdall_extract ~/snapshots/data
mv ~/snapshots/bor_extract ~/snapshots/chaindata
sudo ln -s ~/snapshots/data /var/lib/heimdall
sudo ln -s ~/snapshots/chaindata /var/lib/bor/data/bor

# bring up clients with all snapshot data properly registered
sudo service heimdalld start
# wait for Heimdall to fully sync then start Bor
sudo service bor start

Ensure that the Bor and Heimdall user files have appropriate permissions to access the datadir. To set correct permissions for Bor, execute sudo chown -R bor:nogroup /var/lib/heimdall/data. Similarly, for Heimdall, run sudo chown -R heimdall:nogroup /var/lib/bor/data/bor

Recommended disk size guidance

Polygon Amoy testnet

Metric	Calculation Breakdown	Value
approx. compressed total	250 GB (Bor) + 35 GB (Heimdall)	285 GB
approx. data growth daily	10 GB (Bor) + 0.5 GB (Heimdall)	10.5 GB
approx. total extracted size	350 GB (Bor) + 50 GB (Heimdall)	400 GB
suggested disk size (2.5x buffer)	400 GB * 2.5 (natural chain growth)	1 TB

Polygon mainnet

Metric	Calculation Breakdown	Value
approx. compressed total	3000 GB (Bor) + 500 GB (Heimdall)	3500 GB
approx. data growth daily	100 GB (Bor) + 5 GB (Heimdall)	105 GB
approx. total extracted size	4 TB (Bor) + 500 GB (Heimdall)	4.5 TB
suggested disk size (2.5x buffer)	4 TB * 2 (natural chain growth)	8 TB

Polygon Amoy Erigon archive

Metric	Calculation Breakdown	Value
approx. compressed total	210 GB (Erigon) + 35 GB (Heimdall)	245 GB
approx. data growth daily	4.5 GB (Erigon) + 0.5 GB (Heimdall)	5 GB
approx. total extracted size	875 GB (Erigon) + 50 GB (Heimdall)	925 GB
suggested disk size (2.5x buffer)	925 GB * 2.5 (natural chain growth)	2.5 TB

Recommended disk type and IOPS guidance

Disk IOPS will affect the speed of downloading/extracting snapshots, getting in sync, and performing LevelDB compaction.
To minimize disk latency, direct-attached storage is ideal.
In AWS, when using gp3 disk types, we recommend provisioning IOPS of 16,000 and throughput of 1,000. This minimizes costs while providing significant performance benefits. io2 EBS volumes with matching IOPS and throughput values offer similar performance.
For GCP, we recommend using performance (SSD) persistent disks (pd-ssd) or extreme persistent disks (pd-extreme) with similar IOPS and throughput values as mentioned above.

​Community snapshots

​Downloading and using client snapshots

​Example

​Recommended disk size guidance

​Polygon Amoy testnet

​Polygon mainnet

​Polygon Amoy Erigon archive

​Recommended disk type and IOPS guidance

Community snapshots

Downloading and using client snapshots

Example

Recommended disk size guidance

Polygon Amoy testnet

Polygon mainnet

Polygon Amoy Erigon archive

Recommended disk type and IOPS guidance