Writing Automated Backup Shell Scripts Utilizing Bash and Cron
A manual backup is a single point of failure. To ensure data integrity on your Hovixa VPS, you must implement a Scheduled Backup System. This involves creating a Bash script to handle the logic—dumping databases, archiving files, and managing rotation—and using the cron daemon to execute that script at precise intervals.
1. Anatomy of a Production-Grade Backup Script
A reliable script does more than just copy files; it verifies paths, handles errors, and organizes outputs with timestamps. Below is a boilerplate for a WordPress/Web backup on a LEMP/LAMP stack.
#!/bin/bash
# --- Configuration ---
BACKUP_DIR="/backups/daily"
SITE_ROOT="/var/www/html"
DB_NAME="wordpress_db"
DATE=$(date +%Y-%m-%d_%H%M)
# Create directory if not exists
mkdir -p $BACKUP_DIR
# 1. Backup Database
mysqldump $DB_NAME > $BACKUP_DIR/db_backup_$DATE.sql
# 2. Backup Files (Exclude cache)
tar -czf $BACKUP_DIR/files_$DATE.tar.gz -C $SITE_ROOT --exclude='wp-content/cache' .
# 3. Cleanup: Remove backups older than 7 days
find $BACKUP_DIR -type f -mtime +7 -delete
echo "Backup completed successfully on $DATE"
2. Scheduling with Cron
The cron daemon checks the crontab (cron table) every minute to see if any tasks are scheduled for execution. The syntax consists of five fields representing time, followed by the command.
Common Cron Intervals:
- Every Night at 2 AM:
0 2 * * * /path/to/script.sh - Every Monday at Midnight:
0 0 * * 1 /path/to/script.sh - Every 6 Hours:
0 */6 * * * /path/to/script.sh
# To edit your crontab, run:
crontab -e
3. The Backup Rotation Matrix
Storage on your Hovixa NVMe is finite. Implementing a Grandfather-Father-Son (GFS) rotation ensures you have granular recent backups and long-term historical snapshots without exhausting disk space.
| Type | Frequency | Retention | Purpose |
|---|---|---|---|
| Daily | Every 24h | 7 Days | Recovery from accidental deletion. |
| Weekly | Every Sunday | 4 Weeks | Recovery from undetected site errors. |
| Monthly | 1st of Month | 3 Months | Archival and compliance. |
4. Technical Implementation Details
- Permissions: Ensure your script is executable. Run
chmod +x backup.sh. For security, ensure only the root user (or the backup user) can read the script if it contains database credentials. - Absolute Paths: Cron runs in a limited environment. Always use absolute paths (e.g.,
/usr/bin/mysqldumpinstead of justmysqldump) to prevent "Command not found" errors. - Logging: Capture the output of your cron jobs to identify failures. Append
>> /var/log/backup.log 2>&1to your crontab entry to redirect both standard output and errors to a log file.
5. Off-Server Redundancy
A backup stored on the same disk as the source is not a true backup. After creating the local archive, use rsync or scp within your script to push the data to a remote Hovixa storage server or an S3-compatible bucket.
# Push to remote storage
rsync -avz $BACKUP_DIR remote_user@backup_server:/remote/path/
Sysadmin Advice: Test your restoration process monthly. A backup script is only successful if you can actually use the resulting .tar.gz and .sql files to rebuild a functioning site on a fresh Hovixa VPS instance.
