Setting up automated MySQL/database backups outside of WordPress
TL;DR: A WordPress backup plugin, while genuinely useful and covered in our dedicated backup and restore testing guide, runs within WordPress's own execution environment, meaning it can fail silently if the site itself is compromised or broken in a way that prevents the plugin from running correctly, precisely the scenario where a backup is most critically needed. A separate, server-level automated database backup, typically implemented via a scheduled cron job running mysqldump (the standard MySQL command-line backup utility) independently of WordPress entirely, provides a genuinely independent layer of protection that does not share this specific failure mode, since it operates outside WordPress's own execution context and continues functioning even if the WordPress application itself is compromised or broken.
Why a WordPress-plugin-only backup has a specific blind spot
A WordPress backup plugin runs as PHP code executed within WordPress's own request-handling cycle, typically triggered by WordPress's own cron system (covered in the context of its reliability limitations in our dedicated WP-Cron guide) or a real server-level cron job calling into WordPress. This means the backup plugin's ability to actually run and complete successfully depends on WordPress itself being in a functioning enough state to execute PHP code at all, which is precisely the assumption that breaks down during the exact scenarios where a backup is most critically needed: an active security compromise (covered in our hacked site guide) where an attacker has specifically disabled or interfered with the backup plugin itself, a severe technical failure (a fatal PHP error, covered across our various WordPress error guides) preventing WordPress from executing normally at all, or a resource exhaustion situation where the site is too degraded to reliably complete a backup operation through its own, already-struggling execution environment.
What mysqldump actually does
mysqldump is the standard, long-established command-line utility for creating a backup of a MySQL (or MariaDB) database, generating a text file containing the SQL commands necessary to fully recreate the database's structure and content from scratch, run directly against the database server itself rather than through WordPress's own application layer at all. This operates entirely independently of WordPress's own code and execution state, meaning it continues to function correctly even if WordPress itself is broken, compromised, or otherwise non-functional, since it interacts directly with the database server, a genuinely separate system from WordPress's own PHP application code.
Setting up an automated mysqldump backup via cron
The standard approach: create a simple shell script that runs mysqldump against your WordPress database with your appropriate database credentials, saves the output to a timestamped file, and ideally compresses it to save space, then schedule this script to run automatically via a genuine server-level cron job (the same underlying mechanism covered in our dedicated WP-Cron guide as the more reliable alternative to WordPress's own page-load-triggered cron), running independently on a schedule (commonly daily) regardless of WordPress's own state or functionality at the time the scheduled backup runs.
A sample backup script
A representative, simplified example of what such a script might contain:
#!/bin/bash
DB_NAME="your_wordpress_db"
DB_USER="your_db_user"
DB_PASS="your_db_password"
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
FILENAME="$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"
mkdir -p $BACKUP_DIR
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $FILENAME
# Delete backups older than 14 days
find $BACKUP_DIR -name "*.sql.gz" -mtime +14 -delete
This creates a timestamped, compressed backup file and automatically cleans up backups older than a configured retention period (14 days in this example), preventing the backup directory itself from growing unbounded, similar in principle to the log rotation concern covered in our dedicated guide. Scheduling this script via a cron entry (crontab -e, adding a line specifying the desired schedule and the script's path) completes the automated setup, running independently of WordPress on whatever schedule you configure.
Getting backups off the server, not just onto it
A backup file saved only to the same server as the live site provides meaningfully less protection than a genuinely off-site copy, for the same reasons covered in our dedicated WordPress backup guide: a full server failure, or a sufficiently deep security compromise affecting the broader server environment beyond just WordPress itself, could affect a locally-stored backup right alongside the live site it was meant to protect. Extending the backup script to also transfer the completed backup file to a genuinely separate location, a cloud storage service, a separate remote server via SCP/rsync, or an object storage service, closes this specific gap, ensuring the backup's protective value survives even a genuine, complete failure of the original server itself.
Retention and log rotation for backup files themselves
Similar to the general log rotation concern covered in our dedicated guide, backup files themselves need a defined retention policy (as shown in the sample script above) to prevent them from silently consuming disk space indefinitely, since an accumulating, never-cleaned set of daily backup files can itself become a disk space exhaustion problem over time if not properly managed. Balancing genuine retention needs (having enough historical backups to recover from a problem that may not be noticed immediately) against reasonable storage consumption is worth deliberately configuring rather than either accumulating backups indefinitely or being too aggressive in deletion and losing the ability to recover from an older, not-immediately-noticed issue.
A checklist
| Step | Why it matters |
|---|---|
| mysqldump script created with correct database credentials | Confirm the script actually runs and produces a valid backup |
| Scheduled via genuine server-level cron, not WordPress's own cron | Ensures independence from WordPress's own execution state |
| Backup files compressed | Reduces storage consumption |
| Retention policy configured (old backups automatically deleted) | Prevents unbounded disk usage over time |
| Backups transferred to genuinely off-site storage | Protects against a full server-level failure or compromise |
| Restore process tested periodically | Confirms the backup is genuinely usable, not just present |
FAQs
Does this replace the need for a WordPress backup plugin entirely?
Not necessarily; a WordPress plugin backup typically also covers your actual files (themes, plugins, uploads), not just the database, so a comprehensive backup strategy generally still benefits from a plugin or equivalent file-backup mechanism alongside this independent, server-level database backup specifically, rather than one fully replacing the other; the value here is specifically in having a genuinely independent layer for the database component that does not share WordPress's own potential failure modes.
How do I test that this backup script is actually working correctly?
Run the script manually first to confirm it produces a valid, non-empty backup file without errors, then verify the scheduled cron job is genuinely executing as expected (checking for the appearance of new, correctly timestamped backup files on the expected schedule), and periodically perform an actual test restore into a separate environment, following the same testing discipline covered in our dedicated WordPress backup guide.
Is it safe to store database credentials directly in this backup script?
This is worth handling carefully, following the same principle covered in our dedicated environment variables guide; ensure the script file itself has appropriately restrictive file permissions (readable only by the specific user account that needs to run it) rather than being broadly readable, and avoid committing this script with real credentials to any version control system.
Does this approach work the same way for MariaDB as for MySQL?
Yes, mysqldump (or the equivalent mariadb-dump command in some current MariaDB distributions, functionally very similar) works the same way for MariaDB, since MariaDB is largely compatible with MySQL's own tooling and command structure for this purpose.
How often should this independent backup run, relative to my WordPress plugin's own backup schedule?
A reasonable approach runs this independent backup on a similar or complementary schedule to your WordPress plugin's own backup (commonly daily), providing genuine redundancy through independence rather than needing to run more frequently than your plugin-based backup; the value is in having two genuinely separate, independent backup mechanisms, not necessarily in one running more often than the other.
Can I automate the off-site transfer step as well, not just the local backup creation?
Yes, this is a reasonable, worthwhile extension of the basic script, using a cloud storage command-line tool or a script leveraging an API (many cloud storage providers offer command-line tools or APIs suitable for this) to automatically upload the completed backup file to off-site storage as an additional step within the same overall automated script, rather than requiring a separate manual transfer step.
Does this require root or special server access to set up?
Generally yes, since it involves creating server-level cron jobs and having direct database access credentials, requiring either root/administrative access to your VPS or, on managed hosting, working with your host's support team or control panel tools if direct server access is not available to you as the account holder.
Conclusion
A WordPress backup plugin, while genuinely useful, shares a specific structural vulnerability with the rest of your WordPress application, its ability to function depends on WordPress itself being in a working enough state to execute, precisely the assumption that can fail during the exact scenarios where a backup matters most. A separate, server-level mysqldump-based backup running via an independent cron job provides genuine redundancy through independence, continuing to function even if WordPress itself is compromised or broken.
Combine this independent database backup layer with your existing WordPress plugin backup covering your actual files, ensure both transfer to genuinely off-site storage, and periodically test an actual restore from each, rather than assuming either backup mechanism alone provides complete, verified protection.
HostCloud's hosting includes server-level database backup infrastructure independent of WordPress's own application layer, providing exactly this kind of genuine redundancy as a standard part of our managed hosting plans. Plans start at ₹99 a month at https://hostcloud.in.