🔧 Tronsell Wiki

Full Node Maintenance

Essential guide to keeping your TRON full node healthy, secure, and performant. Covers routine checks, log rotation, database compaction, upgrades, backup, and disaster recovery.

Updated: June 2025 ~11 min read Operations · Intermediate

🔧 Maintenance at a Glance

Routine Checks Daily (automated)

Log Rotation Weekly or 500 MB

Database Compaction Monthly (auto)

Snapshot Backup Weekly

Node Upgrades Per release

RTO Target < 1 hour

📋 Why Maintenance Matters

A TRON full node is a critical piece of infrastructure. Without regular maintenance, your node may fall out of sync, run out of disk space, or suffer from performance degradation. Proactive maintenance ensures:

Reliability — Minimal downtime and consistent API availability.
Performance — Optimized sync speed and low latency.
Security — Up-to-date software with the latest patches.
Recovery — Fast restoration in case of failure.

📌 Maintenance Philosophy

Treat your node like a production service. Automate routine tasks, monitor proactively, and always have a recovery plan. The goal is zero unplanned downtime.

✅ Routine Health Checks

Perform these checks daily to ensure your node is operating normally:

Check	Command / Method	Expected
Block Sync	curl -s localhost:8090/wallet/getnowblock	Within 10 blocks of Tronscan
Disk Usage	df -h /opt/tron-node	< 80% capacity
CPU Load	top -bn1 \| head -10	< 80% sustained
Memory	free -h	No swap usage
Peer Count	curl -s localhost:8090/wallet/listnodes	> 10 active peers
Log Errors	tail -100 /opt/tron-node/logs/tron.log	No ERROR or FATAL

💡 Automate with Scripts

Write a shell script that runs these checks and sends alerts to Slack or email if any condition fails. This reduces manual effort and catches issues early.

                    #!/bin/bash
                    # Quick health check script
                    BLOCK=$(curl -s localhost:8090/wallet/getnowblock | jq '.block_header.raw_data.number')
                    TRONSCAN=$(curl -s https://api.tronscan.org/api/block?limit=1 | jq '.data[0].number')
                    LAG=$((TRONSCAN - BLOCK))
                    if [ $LAG -gt 10 ]; then echo "Node is lagging by $LAG blocks"; fi
                

📝 Log Management & Rotation

Java-Tron generates logs that can grow large over time. Without rotation, log files can fill up your disk and cause the node to crash.

Log Rotation Strategy

Rotate logs weekly or when they reach 500 MB.
Keep 4 weeks of compressed logs for debugging.
Use logback.xml to configure rotation in Java-Tron.

                    # Example logback.xml rotation settings
                    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                      <fileNamePattern>logs/tron.%d{yyyy-MM-dd}.log</fileNamePattern>
                      <maxHistory>30</maxHistory>
                    </rollingPolicy>
                    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
                      <maxFileSize>500MB</maxFileSize>
                    </triggeringPolicy>
                

⚠️ Log Storage

Logs can consume 10–20 GB per month on a busy node. Monitor your log directory size and rotate aggressively to prevent disk exhaustion.

🗄️ Database Maintenance

The RocksDB database requires periodic maintenance to stay performant. Most of this is automatic, but there are manual steps you can take.

Compaction

RocksDB performs background compaction to merge SST files and remove obsolete data. You can force a manual compaction if you notice performance degradation.

                    # Manual compaction via Java-Tron API (HTTP)
                    curl -X POST localhost:8090/wallet/compactdatabase
                

Database Integrity

Periodically check for database corruption. If you suspect issues, run the recovery tool:

                    # Run RocksDB recovery tool
                    java -cp FullNode.jar org.rocksdb.tools.DbRecover -db /opt/tron-node/database
                

📌 Database Health

Monitor RocksDB metrics like rocksdb.live-sst-files-size and rocksdb.estimate-pending-compaction-bytes. High pending compaction bytes indicate I/O bottlenecks.

⬆️ Node Upgrades

TRON's Java-Tron client is regularly updated with new features, performance improvements, and security patches. Keeping your node upgraded is essential.

📦

Check for Updates

Monitor the Java-Tron releases page for new versions.

🔄

Upgrade Process

Stop the node, replace the JAR, review config changes, and restart. Test on testnet first.

⏱️

Downtime

Upgrades typically take 5–10 minutes. Schedule during low-traffic periods.

🔙

Rollback Plan

Keep the previous JAR and config file. If issues arise, revert quickly.

Stop the node

sudo systemctl stop tron-node

Backup current JAR

cp /opt/java-tron/build/libs/FullNode.jar /opt/backup/FullNode.jar.old

Download new JAR

wget -O FullNode.jar https://github.com/tronprotocol/java-tron/releases/latest/download/FullNode.jar

Review config changes

Compare the new config.conf with your current one. Merge any new parameters.

Start and monitor

sudo systemctl start tron-node and check logs for errors.

⚠️ Upgrade Best Practice

Always test new versions on a testnet node before upgrading mainnet. Some upgrades may introduce database schema changes that require a re-sync.

💾 Backup & Disaster Recovery

A robust backup strategy ensures you can recover quickly from disk failure, corruption, or accidental deletion.

Snapshot Backup Strategy

Frequency: Weekly snapshots for production nodes.
Retention: Keep the last 4 weekly snapshots.
Location: Store snapshots on a separate volume or cloud storage (e.g., S3).
Testing: Regularly test restoring from snapshots to ensure they are valid.

                    # Create a compressed snapshot
                    tar -czf /backup/tron-snapshot-$(date +%Y%m%d).tar.gz -C /opt/tron-node database/
                    # Upload to cloud storage (example with aws cli)
                    aws s3 cp /backup/tron-snapshot-*.tar.gz s3://my-tron-backups/
                

Disaster Recovery Plan

📋

RTO

Recovery Time Objective: < 1 hour from snapshot.

📊

RPO

Recovery Point Objective: ≤ 7 days (weekly snapshots).

🔄

Recovery Steps

Provision new server → restore snapshot → start node → catch up.

💡 Automate Backups

Use cron to schedule weekly snapshots and upload them to cloud storage automatically. This removes human error from the backup process.

🔒 Security Maintenance

Regular security maintenance protects your node from attacks and unauthorized access.

OS updates: Run apt update && apt upgrade -y monthly.
Firewall rules: Review open ports regularly. Restrict RPC ports (50051, 8090) to trusted IPs.
SSL/TLS: If exposing APIs, use TLS with valid certificates.
Monitoring: Set up intrusion detection (e.g., Fail2ban) for SSH and RPC endpoints.
Access control: Rotate SSH keys periodically and use strong passwords.

🔑 Security Checklist

✅ Disable root SSH login
✅ Use SSH key authentication
✅ Restrict RPC to localhost or VPN
✅ Enable audit logs
✅ Regularly review /var/log/auth.log

❓ Frequently Asked Questions

How often should I restart my TRON full node?

In normal operation, you should not need to restart your node frequently. Restart only for upgrades, configuration changes, or if the node becomes unresponsive. Frequent restarts can slow down sync and disrupt peers.

What should I do if my node falls out of sync?

First, check logs for errors. If the lag is small (< 1000 blocks), the node will likely catch up automatically. For larger lags, consider restoring a recent snapshot to speed up recovery.

How do I know when to upgrade Java-Tron?

Monitor the official releases page. Upgrade when security patches, performance improvements, or new features are released. Always test on testnet first.

What is the recommended backup frequency?

For production nodes, take a weekly snapshot and store it off-server. If your node handles high-value applications, consider daily snapshots.

Can I perform maintenance without stopping the node?

Some tasks — like log rotation and monitoring — can be done online. However, database upgrades, JAR replacement, and major config changes require a node restart. Schedule downtime during off-peak hours.

⚡ Maintain Your Node, Save on Fees

Keep your TRON full node healthy and pair it with Tronsell Energy to power your dApps and transactions at the lowest cost.

⚡ Get Tron Energy 📞 Contact Support