🤔 Need blocks and a snapshot? Use the bundle API to always get the latest compatible backups.

Mainnet Snapshots

Hourly snapshots of the EOS mainnet so you can instantly sync with the network.

Title Download Size MD5 Checksum
snap_2019-03-20-07-00.tar.gz Wasabi S3 361.57 MiB c020fe46cfc8e11fd9d03e840a0c3271
snap_2019-03-20-06-00.tar.gz Wasabi S3 361.41 MiB 596a8fb8a1d52890b3743c78f3812f51
snap_2019-03-20-05-00.tar.gz Wasabi S3 361.39 MiB 08d80fb7211c5fb8c9ca51ce1345d4bc
snap_2019-03-20-04-00.tar.gz Wasabi S3 361.31 MiB 9a8b4cfe3d64034aea6e273e3a4e0649
snap_2019-03-20-03-00.tar.gz Wasabi S3 362.62 MiB 4a9fd80af650ba367ebc82df0c8c8e57
snap_2019-03-20-02-00.tar.gz Wasabi S3 362.58 MiB fae7a0c7f275a62224f12dbfdb3accd8
snap_2019-03-20-01-00.tar.gz Wasabi S3 362.67 MiB 223a59edb04b52349aef975b1d2304ee
snap_2019-03-20-00-00.tar.gz Wasabi S3 362.58 MiB b759145be348876be857f478172e57a9
snap_2019-03-19-23-00.tar.gz Wasabi S3 362.57 MiB b0ce1359c619e7bc942cb1fab854347a
snap_2019-03-19-22-00.tar.gz Wasabi S3 362.65 MiB c46bb0ede80d8d29f7d4c2fe7b2ef517
snap_2019-03-19-21-00.tar.gz Wasabi S3 362.56 MiB 69e8778d4d3a7a509fe56af2be8aa865
snap_2019-03-19-20-00.tar.gz Wasabi S3 362.57 MiB c197fb52e84b22e6ff97c8a309d3334a
snap_2019-03-19-19-00.tar.gz Wasabi S3 362.54 MiB 0b072331bb3863dd0a3e2e392537f545
snap_2019-03-19-18-00.tar.gz Wasabi S3 361.37 MiB 8b38c31eebc448d4d5f036cf7a96fe24
snap_2019-03-19-17-00.tar.gz Wasabi S3 361.32 MiB 29632bd74f24ca028b78294eda525d96
snap_2019-03-19-16-00.tar.gz Wasabi S3 361.38 MiB 0068e54c061887556487fffa03a8c01e
snap_2019-03-19-15-00.tar.gz Wasabi S3 361.4 MiB c809802d0b631524a4142f966f1b5cf1
snap_2019-03-19-14-00.tar.gz Wasabi S3 361.18 MiB 28d6d9b2440f604ebd444a716c033796
snap_2019-03-19-13-00.tar.gz Wasabi S3 360.88 MiB 8eb08924396c2ff2d95f25de8b4d8407
snap_2019-03-19-12-00.tar.gz Wasabi S3 360.75 MiB 220dc73f29282ac5443b5546402a65c1
snap_2019-03-19-11-00.tar.gz Wasabi S3 360.42 MiB c80b2508f0d8813688a63df92228538a
snap_2019-03-19-10-00.tar.gz Wasabi S3 360.26 MiB 5ba12f617c6ff5543e73ff84d4a0cbb8
snap_2019-03-19-09-00.tar.gz Wasabi S3 360.13 MiB 903adb6de495d57a4d43fee93d6942e2
snap_2019-03-19-08-00.tar.gz Wasabi S3 359.97 MiB a76c390eade1e9751d2049de692fb34b
snap_2019-03-19-07-00.tar.gz Wasabi S3 359.88 MiB 25eee1d97a435cf1b8e51b572471f01a
snap_2019-03-19-06-00.tar.gz Wasabi S3 359.6 MiB c9f87a93d2e7bec27615d6856bf7ab72
snap_2019-03-19-05-00.tar.gz Wasabi S3 359.34 MiB bf2a89faba6d7c3f10aed8adc19a1a9e
snap_2019-03-19-04-00.tar.gz Wasabi S3 359.16 MiB 56d0ca2c4c2cdb241ac687d337232465
snap_2019-03-19-03-00.tar.gz Wasabi S3 358.94 MiB f92ad1b22d976a849f2799f4df47a1b1
snap_2019-03-19-02-00.tar.gz Wasabi S3 358.38 MiB a4089de0b6c1b86eee6df3b13cd60f95
snap_2019-03-19-01-00.tar.gz Wasabi S3 358.23 MiB 93c4daf014ca7e03b166fca8a56f48a4
snap_2019-03-19-00-00.tar.gz Wasabi S3 358.01 MiB 10efe7c43fe323210ec3d90549582f68

These snapshots are platform agnostic and taken from our own cluster of API nodes.
They can be used with or without a blocks log.

Using Snapshots

This is a great way to get synced to the network within a minute, you can see the original notes on Github. There are a couple of points to be aware of:

  • The snapshots contain all the consensus state required to bootstrap a node at a given head block, so there's no need for long replays to build state from the blocks log.
  • This sync method is intended for producing nodes, however if you don't intend on supporting history data, it will work perfectly for API/full nodes.

What's The Catch?

After being accustomed to long replay times via Block backups, the near instant snapshot sync seems like magic. But the magic comes at a cost:

  • If you want to support retrospective chain data via the RPC API or P2P, then you must provide a blocks log that contains blocks up to the snapshotted block. The blocks log may contain additional blocks, they will be applied as part of the startup process.
  • These snapshots do not support any plugins, so this doesn't support history data.

How To Use

First, you must do some preparation. Remove the state directory if it exists, then you need to make a decision. If you want to support old chain data, then you must have a blocks directory with a block log containing data up to, or past the head block referenced in the snapshot.

Download the snapshot, uncompress it and start nodeos with the snapshot flag pointing to the absolute location of the fresh snapshot.

The example assumes you have used our automation framework to install and configure the EOS application. It includes handy bash helpers to auto dameonise the nodeos process and capture all output into a single log file.

You can use the one-liner in the example to always download the latest snapshot. We also have a Snapshots API which orders the archives in chronological order, newest first.

# Move to your local eos directory, removing the existing state directory (if relevant)
cd /opt/mainnet
rm -rf state

# Download the latest snapshot
wget $(wget --quiet "https://eosnode.tools/api/snapshots?limit=1" -O- | jq -r '.data[0].s3') -O snapshot.tar.gz

# Uncompress
tar xvzf snapshot.tar.gz

# Start the chain and sync from the provided snapshot
./start.sh --snapshot "$(ls -t snapshots/*.bin | head -n1)"

# Tail the logs to watch the sync in all its glory
tail -f log.txt