Skip to main content
Snapshots provide faster node synchronization and disaster recovery capabilities. This guide covers snapshot management for Sui nodes.

Snapshot Overview

Snapshots are point-in-time copies of the blockchain database that can be used to:
  • Fast sync: Bootstrap new nodes quickly
  • Disaster recovery: Restore from database corruption
  • Testing: Create test environments
  • Migration: Move nodes to new hardware

Official Snapshots

Mysten Labs provides official snapshots for faster node bootstrapping.

Snapshot Locations

Mainnet:
Testnet:

Using Official Snapshots

Configure in fullnode.yaml:
This enables the node to download historical checkpoints from the archive.

Creating Snapshots

Manual Database Snapshot

1

Stop the node

2

Create snapshot directory

3

Copy database

4

Compress snapshot (optional)

5

Start the node

Automated Snapshot Script

Make executable and schedule:

DB Checkpoint Configuration

Sui nodes support automated database checkpoints at epoch boundaries:
Enabling automatic checkpoints increases storage requirements and may impact performance during epoch boundaries.

State Snapshot Configuration

Configure periodic state snapshots:

Restoring from Snapshot

Restore Local Snapshot

1

Stop the node

2

Backup current database (optional)

3

Restore snapshot

4

Start the node

5

Verify restoration

Restore from Official Snapshot

To bootstrap a new fullnode from official snapshots:
1

Configure archive reading

In fullnode.yaml:
2

Start node with empty database

The node will automatically download and sync from the checkpoint archive.
3

Monitor sync progress

Backup Strategies

Cold Backup Strategy

Full node shutdown for backup (safest): Frequency: Weekly Retention: 4 weekly backups Downtime: 10-30 minutes

Hot Backup Strategy

Background copy without stopping node (faster but less consistent): Frequency: Daily Retention: 7 daily backups Downtime: None
Hot backups may capture an inconsistent state. Only use for non-critical environments or as a supplement to cold backups.

Incremental Backup Strategy

Use LVM snapshots or filesystem snapshots:

Offsite Backup

AWS S3 Backup

s3-lifecycle.json:

GCS Backup

Snapshot Verification

Verify snapshot integrity:

Storage Requirements

Plan storage for snapshots:

Database Sizes (Approximate)

Mainnet Validator:
  • authorities_db: 2-3 TB
  • consensus_db: 100-200 GB
  • Total: 2.5-3.5 TB
Testnet Validator:
  • authorities_db: 500 GB - 1 TB
  • consensus_db: 50-100 GB
  • Total: 600 GB - 1.2 TB

Snapshot Storage

Compressed snapshots are typically 60-70% of original size. Example retention strategy:
  • 7 daily snapshots × 2 TB = 14 TB
  • 4 weekly snapshots × 2 TB = 8 TB
  • 12 monthly snapshots × 2 TB = 24 TB
  • Total: ~46 TB
With compression (70%):
  • Total: ~32 TB

Disaster Recovery

Recovery Time Objective (RTO)

Full resync from network: 3-7 days Restore from snapshot: 2-6 hours Restore from official archive: 12-24 hours

Recovery Point Objective (RPO)

Maximum acceptable data loss:
  • Daily snapshots: 24 hours
  • Hourly snapshots: 1 hour
  • Real-time replication: Minutes

DR Checklist

  • Regular snapshot creation
  • Offsite backup storage
  • Tested restore procedures
  • Documented recovery steps
  • Backup verification
  • Monitoring backup success
  • Encryption for sensitive data

Best Practices

  1. Regular backups: Schedule automated daily snapshots
  2. Test restores: Verify backup integrity by performing test restores
  3. Offsite storage: Store backups in geographically separate location
  4. Retention policy: Balance storage costs with recovery requirements
  5. Monitoring: Alert on backup failures
  6. Documentation: Keep restoration procedures up to date
  7. Encryption: Encrypt backups containing sensitive data