Automate WordPress Backups with WP-CLI and Cron on Hostinger

WordPress backup plugins have a nasty habit of crashing the second your database crosses 500MB or PHP hits a timeout. Running full-site backups through the admin dashboard ties up active PHP workers, chews through memory, and leaves half-baked zip files lying around when traffic spikes.

You can skip PHP runtime limits entirely by handling backups directly at the server level. Here is how I set up an automated, lightweight backup pipeline on Hostinger using WP-CLI, a short Bash script, and scheduled cron jobs.

Why Backup Plugins Fail on Shared and Cloud Hosting

Most backup plugins (UpdraftPlus, All-in-One WP Migration, BackupBuddy) run inside the PHP web process. When a scheduled backup kicks off, the plugin fires loopback HTTP requests to itself, loads massive database tables into PHP memory, and tries to zip everything on the fly.

That architecture fails in predictable ways:

• Execution timeouts: Hostinger plans cap max_execution_time (typically 60–300s). If your wp_posts or wp_postmeta tables are massive, PHP kills the script mid-dump.
• Out-of-memory crashes: Running SQL dumps through PHP quickly blows past 256MB or 512MB limits, throwing fatal Allowed memory size exhausted errors. If you hit memory ceilings elsewhere, see our walkthrough on how to increase PHP memory limit in WordPress on Hostinger.
• Real visitors get throttled: Archiving files in the background eats web workers, meaning actual site visitors sit in a queue waiting for pages to load.

Using WP-CLI (the official WordPress command-line interface) bypasses all of this. It runs binary-level tools like mysqldump and tar directly against MySQL and the filesystem. It finishes in seconds, uses minimal RAM, and never touches your web server pool.

Step 1: Enable SSH and Locate Your System Paths

You need terminal access to your Hostinger account first. WP-CLI comes pre-installed on Hostinger’s Business and Cloud hosting tiers.

1. Log into hPanel.
2. Head to Websites > Dashboard for your target domain.
3. In the sidebar, jump to Advanced > SSH Access.
4. Toggle SSH to Enabled if it’s off.
5. Grab your SSH IP, Port (Hostinger defaults to 65002), and Username.

Fire up your terminal and connect:

ssh -p 65002 u123456789@195.154.12.34

Once you are in, double-check your paths and ensure WP-CLI is responsive:

which wp
pwd

On Hostinger, WP-CLI lives at /usr/local/bin/wp, and your site files sit at /home/u123456789/domains/yourdomain.com/public_html.

Step 2: Test WP-CLI Database and File Exports

Before scripting anything, let’s run a manual dump to make sure permissions and database connections work as expected. If you have followed our guide on how to migrate large WordPress sites to Hostinger with SSH and WP-CLI, you will recognize these commands.

Navigate into your site root:

cd ~/domains/yourdomain.com/public_html

Run a quick export to a temporary file:

wp db export test-backup.sql --add-drop-table

For a 200MB database, this usually finishes in under 3 seconds. The --add-drop-table flag is critical here—if you ever need to restore, it cleanly drops existing tables first instead of choking on duplicate entries.

Clean up the test file:

rm test-backup.sql

Step 3: Create the Automated Backup Directory Structure

Never keep your backup files inside public_html. Anyone scanning for .sql or .zip files on your domain could download your entire customer database and credentials.

Instead, create a private backups directory up in your home root, outside the web tree:

mkdir -p ~/backups
mkdir -p ~/scripts
chmod 700 ~/backups ~/scripts

Locking permissions to 700 ensures no other system user or web process can peek inside.

Step 4: Build the Bash Backup and Retention Script

We need a script that dumps the database, grabs wp-content, packages them into a compressed .tar.gz archive, and automatically purges archives older than 7 days so disk usage does not spiral.

Create your backup script inside ~/scripts/:

nano ~/scripts/wp-backup.sh

Add the following script. Make sure to update DOMAIN_NAME with your exact folder name under ~/domains/:

#!/bin/bash # Configuration
DOMAIN_NAME="yourdomain.com"
WP_PATH="$HOME/domains/$DOMAIN_NAME/public_html"
BACKUP_DIR="$HOME/backups"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
RETENTION_DAYS=7 # Set paths
DB_FILE="$BACKUP_DIR/db_${DATE}.sql"
ARCHIVE_FILE="$BACKUP_DIR/backup_${DOMAIN_NAME}_${DATE}.tar.gz" # Navigate to WP directory
cd "$WP_PATH" || exit 1 # Export database via WP-CLI
/usr/local/bin/wp db export "$DB_FILE" --add-drop-table --quiet if [ ! -f "$DB_FILE" ]; then echo "Database export failed!" >&2 exit 1
fi # Create compressed archive containing wp-content and the database dump
tar -czf "$ARCHIVE_FILE" -C "$WP_PATH" wp-content -C "$BACKUP_DIR" "db_${DATE}.sql" # Remove uncompressed SQL dump
rm -f "$DB_FILE" # Remove archives older than RETENTION_DAYS
find "$BACKUP_DIR" -type f -name "backup_${DOMAIN_NAME}_*.tar.gz" -mtime +$RETENTION_DAYS -delete echo "Backup completed: $ARCHIVE_FILE"

Why back up only wp-content and the database? You can re-download core WordPress files (wp-admin, wp-includes, root PHP files) directly from WordPress.org official documentation anytime. Backing up only what is unique to your site cuts archive size by over 50% and speeds up the entire job.

Make the script executable:

chmod +x ~/scripts/wp-backup.sh

Step 5: Test Script Execution and Verify Archive Integrity

Run the script manually to confirm there are no syntax bugs or path typos:

~/scripts/wp-backup.sh

Check the destination folder:

ls -lh ~/backups

You should see a clean .tar.gz file with today’s timestamp. Inspect its contents without unpacking to verify that both the SQL dump and your uploads/plugins made it inside:

tar -ztvf ~/backups/backup_yourdomain.com_*.tar.gz | head -n 20

Step 6: Schedule the Backup in Hostinger hPanel Cron Jobs

Hostinger lets you manage cron jobs directly through hPanel. Using the UI instead of editing crontab -e directly ensures tasks survive container migrations and Hostinger platform updates.

1. In hPanel, go to Advanced > Cron Jobs.
2. Under Manage Cron Jobs, choose Custom.
3. In the Command box, enter the full path to your script:

/bin/bash /home/u123456789/scripts/wp-backup.sh > /dev/null 2>&1

Make sure you swap u123456789 with your actual Hostinger username. The > /dev/null 2>&1 redirection stops standard output from spamming your cron log unless something breaks.

1. Set your schedule. For a daily backup at 3:00 AM server time:
   • Minute: 0
   • Hour: 3
   • Day of Month: *
   • Month: *
   • Day of Week: *
2. Click Save.

If you automate other infrastructure on your host, our guide on how to configure dynamic DNS with Bash and Cron uses this exact scheduling setup.

How to Restore Your Site from This Backup

An untested backup is just wishful thinking. If an update breaks your production site, you can revert everything in under a minute via SSH.

Before doing it live, you should practice the restore somewhere safe. Follow our guide on how to set up a WordPress staging site in Hostinger hPanel to dry-run your recovery workflow.

To restore directly, unpack your archive and import the database dump:

# 1. Create a restore staging temp directory
mkdir -p ~/restore_tmp
tar -xzf ~/backups/backup_yourdomain.com_2025-02-20_03-00-00.tar.gz -C ~/restore_tmp # 2. Restore wp-content directory
cp -r ~/restore_tmp/wp-content/* ~/domains/yourdomain.com/public_html/wp-content/ # 3. Import the database via WP-CLI
cd ~/domains/yourdomain.com/public_html
wp db import ~/restore_tmp/db_2025-02-20_03-00-00.sql # 4. Clean up temporary files
rm -rf ~/restore_tmp

Immediately flush your caches and transients:

wp cache flush
wp transient delete --all

Gotcha: Hostinger Custom PHP CLI Binary Paths

When cron runs non-interactively, it does not always load your full shell environment. If your cron log throws wp: command not found, specify the absolute path to WP-CLI in your script:

/usr/bin/php /usr/local/bin/wp db export "$DB_FILE" --path="$WP_PATH" --add-drop-table --quiet

Passing --path="$WP_PATH" guarantees WP-CLI finds your wp-config.php regardless of which working directory cron defaults to when executing.

Frequently Asked Questions

Does this backup method consume Hostinger inodes?

Barely any. Because everything is packed into a single .tar.gz archive and older archives are automatically pruned with find -mtime +7 -delete, you only consume 7 inodes total for your entire backup retention window.

Can I sync these backups to an offsite server or S3?

Yes. Just append an aws s3 cp or rclone copy command to the bottom of wp-backup.sh. If you have an offsite storage server, add rsync -avz ~/backups/ user@remote:/storage/backups/ to push archives off-host right after creation.

Will this script work during high-traffic hours?

Yes. mysqldump runs directly against MySQL and dumps tables sequentially without occupying LiteSpeed or Apache web workers, so live site visitors won’t feel any slowdowns.

What happens if a database table is locked or crashed?

If a table fails, wp db export exits with an error code. Our script checks for the existence of the SQL file before compressing, preventing an incomplete or broken dump from archiving.