🤔 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-07-16-20-00.tar.gz Wasabi S3 464.7 MiB a4b66b7cc4b120f6f2097103606ce54f
snap_2019-07-16-19-00.tar.gz Wasabi S3 464.65 MiB 7e6f5648d5763615e4c93cab2ccd5c46
snap_2019-07-16-18-00.tar.gz Wasabi S3 464.65 MiB e48d2dc0773ad67acaba830af12d3cea
snap_2019-07-16-17-00.tar.gz Wasabi S3 464.76 MiB 2ebfe154cf3f51f627053b9f51fcc59a
snap_2019-07-16-16-00.tar.gz Wasabi S3 464.55 MiB c740f38303378cc0f698d63cca1b75cd
snap_2019-07-16-15-00.tar.gz Wasabi S3 464.6 MiB e7fd3f215bc7dac7ee404c8f80e56bf5
snap_2019-07-16-14-00.tar.gz Wasabi S3 464.41 MiB 14d44cfbfe9bf8c9eb440d889b7482cb
snap_2019-07-16-13-00.tar.gz Wasabi S3 464.26 MiB 8e8e636e658dbc5c34173a50fac99451
snap_2019-07-16-12-00.tar.gz Wasabi S3 464.37 MiB 9dc309aef9cbf32d4986bf76854fcdb6
snap_2019-07-16-11-00.tar.gz Wasabi S3 464.3 MiB 46b95b4d355640455906f1b3ccc05964
snap_2019-07-16-10-00.tar.gz Wasabi S3 464.25 MiB 94639404a31cbc2886ca80ddb0436534
snap_2019-07-16-09-00.tar.gz Wasabi S3 464.03 MiB f5239fb4ec5e4a7c484c3292fb324f59
snap_2019-07-16-07-00.tar.gz Wasabi S3 463.73 MiB 8fe0c708f23cff02eec070af31d48df1
snap_2019-07-16-06-00.tar.gz Wasabi S3 463.64 MiB 060e6073ec3365006279a9d1bf616475
snap_2019-07-16-05-00.tar.gz Wasabi S3 463.51 MiB 34ce5698e66552c7161e303ecc898196
snap_2019-07-16-04-00.tar.gz Wasabi S3 463.62 MiB f67e6b4a6dd871fa8f3cf9f8eb8daf97
snap_2019-07-16-03-00.tar.gz Wasabi S3 463.44 MiB a2235421015cb5e183dfcf577cfdea6d
snap_2019-07-16-02-00.tar.gz Wasabi S3 463.29 MiB bd24d7eded1c4677268db4d7f1c3faac
snap_2019-07-16-01-00.tar.gz Wasabi S3 463.2 MiB cc311349a829525f3355ec324a26724a
snap_2019-07-16-00-00.tar.gz Wasabi S3 463.14 MiB 26003cd829218624c9edac43e216b100
snap_2019-07-15-23-00.tar.gz Wasabi S3 463.05 MiB e4fd94ead4ba6d1789b086ef8bd5740e
snap_2019-07-15-22-00.tar.gz Wasabi S3 463.26 MiB 276c3c6216dc72839cff0f4b65705731
snap_2019-07-15-21-00.tar.gz Wasabi S3 463.13 MiB e5ce427f52641c1d115c3da4d35932cb
snap_2019-07-15-20-00.tar.gz Wasabi S3 463.18 MiB 9bd146db311ab4e75925c7e029e671f9
snap_2019-07-15-19-00.tar.gz Wasabi S3 463.22 MiB c996bc53cf079c3b02708b746537100f
snap_2019-07-15-18-00.tar.gz Wasabi S3 463.35 MiB 4778f698ca102149bbb1f6869f7b998f
snap_2019-07-15-17-00.tar.gz Wasabi S3 463.3 MiB 8346907f1c90330ea10eb5f34d80759b
snap_2019-07-15-16-00.tar.gz Wasabi S3 463.5 MiB e2461a0d31cf4d9cbd867bb9d97e2598
snap_2019-07-15-15-00.tar.gz Wasabi S3 463.06 MiB e2f405510f82404ebe692665d058dc1b
snap_2019-07-15-12-00.tar.gz Wasabi S3 463.45 MiB 2ed45f3a25d002bd18fc67ce94281d9b
snap_2019-07-15-11-00.tar.gz Wasabi S3 463.4 MiB 71f6821cb135fb4426c10835dbea1bd2

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