ARTICLE

DMIT Monitoring and Backup: 3-2-1 Rule and Drills

System monitoring tools, data backup strategies, the 3-2-1 rule, automated scripts and recovery drills.

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:

  1. Restore data from backup in a test environment
  2. Verify data integrity and service availability
  3. Record recovery time and steps
  4. 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

ItemRecommendation
System monitoringhtop/netdata or Prometheus
Service health checkcron + curl script or Uptime Kuma
Log monitoringjournalctl periodic checks
DMIT snapshotCreate before changes
Data backuprsync/tar + database dump
Off-site backuprsync to remote server
Automated backupcron scheduled
Recovery drillAt least quarterly
Alert notificationEmail/Webhook/SMS

For more DMIT guides, see the beginner guide and SSH Hardening.

Checked 2026-08-18. Tools follow their respective official documentation.

NEXT STEP

Ready to pick your DMIT plan?

Filter the official snapshot by budget and network, or check live stock at DMIT.

Disclosure: purchases through this link may earn the referrer a commission at no extra cost to you.