The difference between a disaster and an incident is whether your backups work. Most server operators find out which category they’re in at the worst possible moment — during an active ransomware attack, a botched migration, or a disk failure on a Friday afternoon.A backup strategy for dedicated servers requires more than a nightly cron…
Recovery Time Objective (RTO) is how long your application can be offline before the business impact becomes unacceptable. A SaaS application with enterprise customers might have an RTO of 30 minutes. A marketing website might tolerate 4 hours.
Recovery Point Objective (RPO) is how much data loss is acceptable. An ecommerce store taking 500 orders per hour cannot afford to lose 24 hours of data — each lost order is lost revenue and a customer service problem. That same store might run backups every 15 minutes. A development server might run weekly backups with an RPO of 7 days.
Document both numbers before selecting backup frequency, retention, and tooling. Your backup architecture should be designed to meet defined requirements, not inherited from whatever was configured at provisioning.
The 3-2-1 Rule Applied to Dedicated Servers
The 3-2-1 rule is the foundational framework for production backup strategy:
3 copies of the data
2 different storage media types
1 copy stored offsite (geographically separate from the primary server)
Applied to a dedicated server, this typically looks like:
Primary data: The live production server itself
Local backup: An on-server backup to a separate disk or partition (different from the OS/application disk)
Offsite backup: A copy shipped to object storage (S3-compatible), a secondary dedicated server, or InMotion’s backup storage
A single backup stored on the same server as the data is not a backup strategy. Ransomware encrypts attached storage. Disk failures take down everything on the same controller. A local backup without an offsite copy fails both tests.
InMotion’s Premier Care bundle includes 500GB of backup storage for dedicated server customers, providing the offsite copy component without requiring separate cloud storage accounts.
Restic
Restic is a modern, fast, encrypted backup tool that supports S3, Backblaze B2, SFTP, and local storage as backup destinations. Its deduplication and encryption are built-in, and the repository format is forward-compatible with future restic versions.
Basic backup configuration for a web server:
# Initialize a repository on S3-compatible storage
restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups init
# Set credentials via environment variables
export AWS_ACCESS_KEY_ID=”your_key”
export AWS_SECRET_ACCESS_KEY=”your_secret”
# Backup web root and database dumps
restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups \
backup /var/www /etc /home \
–exclude /var/www/html/cache \
–exclude /var/www/html/tmp
# Apply retention policy (keep 7 daily, 4 weekly, 6 monthly)
restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups \
forget –keep-daily 7 –keep-weekly 4 –keep-monthly 6 –prune
Run via cron hourly or nightly depending on your RPO.
Duplicati
Duplicati provides a web-based management interface, which makes it accessible for server operators who prefer not to manage backup jobs entirely via command line. It supports encryption, compression, and multiple backend storage targets. For cPanel-managed servers, Duplicati can run as a system service backing up specific directories.
Rsync for Incremental Copies
rsync with –link-dest creates efficient incremental backups where unchanged files are hard-linked to the previous backup snapshot rather than duplicated. This provides multiple point-in-time snapshots at storage cost proportional to the data that changed:
#!/bin/bash
BACKUP_DIR=”/backup/web”
DATE=$(date +%Y-%m-%d_%H-%M)
LATEST=”$BACKUP_DIR/latest”
rsync -avz –link-dest=”$LATEST” /var/www/ “$BACKUP_DIR/$DATE/”
# Update the symlink to latest backup
rm -f “$LATEST”
ln -s “$BACKUP_DIR/$DATE” “$LATEST”
Database-Specific Backup
File-system backups of running MySQL databases capture inconsistent states — the database files on disk may be mid-transaction when the backup runs. Database backups must use database-native tools:
MySQL/MariaDB:
# Full logical backup
mysqldump –all-databases –single-transaction –routines –triggers \
-u root -p > /backup/mysql_$(date +%Y%m%d).sql
# Compress to reduce storage
gzip /backup/mysql_$(date +%Y%m%d).sql
For larger databases where mysqldump takes too long, Percona XtraBackup provides physical hot backups that capture consistent state without locking tables and restore significantly faster than logical dump files. Percona XtraBackup documentation covers installation and usage.
PostgreSQL:
pg_dumpall -U postgres | gzip > /backup/postgres_$(date +%Y%m%d).sql.gz
cPanel Backup Manager
If your dedicated server runs cPanel/WHM, the built-in Backup Manager handles account-level backups including files, databases, email, and configuration in a single operation. Configure it in WHM under Backup > Backup Configuration.
Key settings to review:
Backup Type: Full and incremental (not just full — incremental between full backups reduces RPO without proportional storage cost)
Remote Destination: Configure SFTP or S3-compatible remote destination for the offsite copy
Retention: Match to your documented RPO and storage budget
InMotion’s Backup Manager add-on provides an additional 500GB of backup storage accessible directly within cPanel, with no additional server configuration required.
Testing Restores
A backup that has never been tested is a hypothesis, not a protection. Testing should cover three scenarios:
File-level restore: Restore a specific directory from backup and verify the contents match what was backed up. Do this monthly.
Database restore: Restore the most recent database dump to a staging server and verify application function. This catches corruption in the dump file before you need it in production. Do this monthly.
Full server restore drill: Provision a new server, restore everything from backup, and verify the application runs correctly. This is the test that reveals whether your documentation, backup configuration, and restore procedures actually work end-to-end. Do this quarterly.
Document the restore procedure explicitly, including commands, timing, and verification steps. The person performing a restore during an incident may not be the person who wrote the backup configuration.
Automating Backup Verification
Restic provides a built-in integrity check that verifies backup repository consistency without a full restore:
restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups check
Run this weekly via cron and alert on non-zero exit codes. A corrupted backup that’s never checked is indistinguishable from a good backup until you need it.
For file-level verification, add a checksum comparison step to your backup process:
# Store a checksum of the source directory
find /var/www -type f -exec md5sum {} \; | sort > /backup/checksums_$(date +%Y%m%d).txt
# Compare after restore
md5sum -c /backup/checksums_20260227.txt
Disaster Recovery Planning Beyond Backups
Backups restore data. A disaster recovery plan addresses everything else:
DNS failover: If your server is down, can you redirect traffic to a temporary replacement? Cloudflare’s proxied DNS makes IP-level failover a matter of changing an A record.
Documented server configuration: Your backup contains your data, not your Nginx configuration, firewall rules, PHP-FPM pool settings, and application dependencies. Document or automate server configuration so a new server can be provisioned to match the previous one.
Communication plan: Who gets notified when the server goes down? In what order? Who has authority to take the server offline for maintenance during a recovery?
InMotion Hosting’s Premier Care includes access to InMotion Solutions — the consulting team that assists with complex server recovery scenarios. The 1 hour/month of Solutions time is most valuably used to test disaster recovery procedures and document recovery runbooks before they’re needed.