🤔 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-08-25-09-00.tar.gz Wasabi S3 491.6 MiB 74e11b99d8f0e42a00af4355a3a84d4b
snap_2019-08-25-07-00.tar.gz Wasabi S3 491.47 MiB f32315d5b03c0862e879cffcef7d50f4
snap_2019-08-25-06-00.tar.gz Wasabi S3 491.34 MiB d6db65eaf36d90b833dae6d5ac327f78
snap_2019-08-25-05-00.tar.gz Wasabi S3 491.22 MiB b9a020e91f43a20b2b08653981ccff2c
snap_2019-08-25-04-00.tar.gz Wasabi S3 491.16 MiB 1299837a78a8287edb3301d8b68039b0
snap_2019-08-25-03-00.tar.gz Wasabi S3 491.03 MiB e2ea7e99a662c06471e3e07d0d9dafc3
snap_2019-08-25-02-00.tar.gz Wasabi S3 490.76 MiB bc830076bac6970021c6098e68071131
snap_2019-08-25-01-00.tar.gz Wasabi S3 490.81 MiB 699aa220fb60452b2eaaf1095e09a13a
snap_2019-08-25-00-00.tar.gz Wasabi S3 490.81 MiB 97555dc65315cf24a4408b0e2ab67294
snap_2019-08-24-23-00.tar.gz Wasabi S3 490.77 MiB aea3808cafacd4196cc980957905a307
snap_2019-08-24-22-00.tar.gz Wasabi S3 490.83 MiB 3b83258a522cc8421fa3ba1dc7cbb70a
snap_2019-08-24-21-00.tar.gz Wasabi S3 490.79 MiB a0e611dcd6564894bc1651b46af1985e
snap_2019-08-24-20-00.tar.gz Wasabi S3 490.88 MiB e301bc010daa0822660e610963f85d74
snap_2019-08-24-19-00.tar.gz Wasabi S3 490.97 MiB a71dfb36d61f6cd7672d7e7393db8add
snap_2019-08-24-18-00.tar.gz Wasabi S3 491.02 MiB 5fa01519f4ff7123c1dbf8985d6edfab
snap_2019-08-24-17-00.tar.gz Wasabi S3 491.09 MiB d54d3a8aa145246fea49b3e0d78ff54e
snap_2019-08-24-16-00.tar.gz Wasabi S3 491.01 MiB c285a646910fba86e63305e771ca4f6e
snap_2019-08-24-15-00.tar.gz Wasabi S3 490.97 MiB 6f811301484f38bac33e032afe20211e
snap_2019-08-24-14-00.tar.gz Wasabi S3 490.96 MiB 9a4decf81bb1a2ab51a8753d70bdd877
snap_2019-08-24-13-00.tar.gz Wasabi S3 491.03 MiB ef68598f5878743320e4bc2cbd40ea98
snap_2019-08-24-12-00.tar.gz Wasabi S3 491.18 MiB 531bbbf21b34cde5f430d7294e5ddef8
snap_2019-08-24-11-00.tar.gz Wasabi S3 491.29 MiB 18499ee326ad04b9302ae6000b2303e7
snap_2019-08-24-10-00.tar.gz Wasabi S3 491.36 MiB d39772144f622c65f30b8bcad817f962
snap_2019-08-24-09-00.tar.gz Wasabi S3 491.23 MiB 58ff6a20ef4a9777fabf6895a2f6995f
snap_2019-08-24-07-00.tar.gz Wasabi S3 490.97 MiB ca7fd6671c037743769f589469371d48
snap_2019-08-24-06-00.tar.gz Wasabi S3 490.96 MiB fc72dbfcb57f5174b61e95e071a84da6
snap_2019-08-24-05-00.tar.gz Wasabi S3 490.84 MiB 20e6cdff9ea299056b164e0b589f5b6d
snap_2019-08-24-04-00.tar.gz Wasabi S3 490.85 MiB bc89273205fc3d9eef738ce3d5d542c6
snap_2019-08-24-03-00.tar.gz Wasabi S3 490.74 MiB 125142d3fd3834d9caf864dd35f75d0b
snap_2019-08-24-02-00.tar.gz Wasabi S3 490.57 MiB 6e90c706a5b14c6a75524577d80610ab
snap_2019-08-24-01-00.tar.gz Wasabi S3 490.3 MiB 78c5b722f5b41f2146dff0346092cc44
snap_2019-08-24-00-00.tar.gz Wasabi S3 490.09 MiB 02404e71b323d20a8716dfe76f87a196

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