Why monitoring and backups matter
Cloud servers offer high availability, but data loss, service interruptions or performance degradation can still happen. Proper monitoring helps you spot issues early; reliable backups ensure you can recover quickly when disaster strikes.
This article covers monitoring and backup best practices for DMIT cloud servers, including tool selection, configuration and recovery drills.
Monitoring: know what's happening
System resource monitoring
Basic monitoring should cover CPU, memory, disk and network usage. Lightweight options using built-in tools:
# Real-time
htop # CPU/memory (install required)
iotop # Disk I/O (install required)
iftop # Network (install required)
# Snapshot
free -h # Memory
df -h # Disk
uptime # Load
For long-term trends, lightweight monitoring solutions:
- Netdata: out-of-the-box real-time monitoring, web UI, low resource usage
- Prometheus + Grafana: production-grade monitoring with alerting and history
- Uptime Kuma: service availability monitoring, multiple notification channels
Service health checks
Configure health checks for critical services to get notified when they fail:
#!/bin/bash
response=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:80)
if [ "$response" != "200" ]; then
echo "Service down! HTTP $response" | mail -s "Alert" you@example.com
fi
Schedule with cron or systemd timers.
Log monitoring
Regularly check system logs for anomalies:
# Auth log
journalctl -u sshd --since "1 hour ago"
# System errors
journalctl -p err --since "today"
# Nginx access log analysis
tail -f /var/log/nginx/access.log
grep " 500 " /var/log/nginx/access.log
Backups: ensure data is recoverable
DMIT snapshots
The DMIT control panel supports instance snapshots. Snapshots are suited for:
- Quick rollback before configuration changes
- Full copy during instance migration
- Disaster recovery baseline
Snapshots are instance-level full backups — fast to restore but consume storage. Create one before major changes.
Data-level backups
Snapshots don't replace data-level backups. Critical data needs its own strategy:
# rsync to remote
rsync -avz --delete /var/www/ user@backup-server:/backup/www/
# tar archive
tar czf /backup/www-$(date +%Y%m%d).tar.gz /var/www/
# Database backup
mysqldump -u root -p --all-databases > /backup/db-$(date +%Y%m%d).sql
pg_dump -U postgres -F c dbname > /backup/db-$(date +%Y%m%d).dump
Automated backup script
#!/bin/bash
# /opt/backup.sh
BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d)
KEEP_DAYS=7
# Backup database
mysqldump -u root --all-databases > $BACKUP_DIR/db-$DATE.sql
# Backup website
tar czf $BACKUP_DIR/www-$DATE.tar.gz /var/www/
# Clean old backups
find $BACKUP_DIR -name "*.sql" -mtime +$KEEP_DAYS -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +$KEEP_DAYS -delete
# Sync to remote
rsync -az $BACKUP_DIR/ user@remote:/backup/
Schedule with cron: 0 2 * * * /opt/backup.sh (daily at 2 AM)
The 3-2-1 backup rule
Industry-standard 3-2-1 backup principle:
- 3 copies of data (including the original)
- 2 different storage media (e.g. local disk + remote server)
- 1 off-site backup (different geographic location)
For DMIT users: DMIT snapshot as the first copy, rsync to another server as the second, local download as the third.
Recovery drills
Having backups doesn't mean you can recover — regular drills are essential:
- Restore data from backup in a test environment
- Verify data integrity and service availability
- Record recovery time and steps
- Update recovery documentation so the team knows the process
Drill at least quarterly to ensure backups are valid and the process works.
Alert notifications
When monitoring detects issues, timely notification is needed:
- Email: simplest, using sendmail or msmtp
- Webhook: push to Slack/Discord/Telegram
- SMS: for critical alerts
# Telegram notification example
curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage \
-d chat_id=<CHAT_ID> \
-d text="Server alert: disk usage over 90%"
Checklist
| Item | Recommendation |
|---|---|
| System monitoring | htop/netdata or Prometheus |
| Service health check | cron + curl script or Uptime Kuma |
| Log monitoring | journalctl periodic checks |
| DMIT snapshot | Create before changes |
| Data backup | rsync/tar + database dump |
| Off-site backup | rsync to remote server |
| Automated backup | cron scheduled |
| Recovery drill | At least quarterly |
| Alert notification | Email/Webhook/SMS |
For more DMIT guides, see the beginner guide and SSH Hardening.
Checked 2026-08-18. Tools follow their respective official documentation.