Backup Stuck on “Async Backup Started” (Shared Hosting)PRO
If a SiteVault Pro full backup runs forever and the log shows only “Async backup started” with no further entries, your host is silently dropping one of the WP-Cron hooks the async backup engine depends on. This is a known shared-hosting quirk and the fix is one extra cron entry.
Symptoms
You probably have this issue if all of the following are true:
The Telltale Signs
- You clicked “Backup Now” (or a scheduled full backup ran) and the SiteVault dashboard shows status IN_PROGRESS
- The “Last log message” field reads exactly
Async backup startedwith a timestamp from many minutes (or hours) ago - No additional log entries appear no matter how long you wait or how often you refresh the page
- Eventually the row flips to FAILED, or you trigger another backup which cancels and replaces it — same result
- Hourly database-only backups (scheduled, small) do complete normally
Database-only backups complete in a single phase, so they don’t depend on the resumption hook firing repeatedly. Full backups (database + plugins + themes + uploads + zip) need the chunked resumption pattern, which is exactly what the host’s cron filtering is breaking.
How to Verify It’s This Specific Issue
Before applying the fix, confirm the diagnosis with a quick check.
Open the full SiteVault log file
Via cPanel File Manager (show hidden files) navigate to wp-content/uploads/sitevault/logs/ and open today’s log file: royal-backups-YYYY-MM-DD.log
Check the entries after the most recent “Async backup started”
If the next entries are Backup resumption started → Database chunked export completed → Built and cached file list for plugins, your backup is just slow — not stuck. Wait it out.
If the log goes silent after Async backup started and the only later entries are repeated Async backup started from new attempts (or Cancelling previous in-progress backup when you retried), this is the cron-filter issue.
Optional: confirm via WP-CLI
If you have SSH access (or cPanel Terminal), run:
cd /path/to/your/wordpress wp cron event list | grep rb_backup_resume
If you see rb_backup_resume events with next_run_relative column showing “now” (meaning they are due) but they are not firing, that confirms the diagnosis.
The Fix — One Extra Cron Entry
The fix is to add a dedicated system cron job that targets the rb_backup_resume hook by name, bypassing whatever filter the host has on the generic --due-now runner.
Option A: cPanel Cron Jobs (most shared-host customers)
Open cPanel → Cron Jobs
Most shared-host control panels expose this under “Advanced” or “Tools”. If you don’t see Cron Jobs, your host may not allow user-managed cron — contact their support and ask them to add the entry below for you.
Add a new cron job firing every minute
In the “Common Settings” dropdown, choose Once Per Minute (* * * * *). The Minute / Hour / Day / Month / Weekday fields should auto-fill with *.
In the Command field, paste this (replacing /home/USER/path/to/wordpress with your actual WordPress install path):
cd /home/USER/path/to/wordpress && /usr/local/bin/wp cron event run rb_backup_resume --quiet > /dev/null 2>&1
Click Add New Cron Job. The new entry should appear in your “Current Cron Jobs” list.
Trigger a fresh full backup to verify
Wait ~60 seconds for the new cron entry to fire its first cycle, then go back to SiteVault → Backups and click Backup Now. Refresh the page every 30 seconds. Within 1–2 minutes you should see the “Last log message” field advance past Async backup started — new entries will appear like Backup resumption started, Database chunked export completed, etc. The backup should complete in 5–15 minutes depending on site size.
If your hosting provider already configured a wp cron event run --due-now cron entry during onboarding, leave it in place. The new entry runs alongside it, not instead of it. Both contribute to keeping WP-Cron healthy on your site.
Option B: SSH or WP-CLI Terminal (developers)
If you have shell access, you can also fire the hook manually from the command line to unstick a backup that’s already in progress:
cd /path/to/your/wordpress wp cron event run rb_backup_resume
This fires every queued rb_backup_resume event immediately. The same backup chain self-drives from there, but if the chain stalls again (because the next resumption is also queued and the host filters that one out too), repeat the command until the backup completes.
Once you’ve added the system cron entry from Option A, you shouldn’t need to manually fire the hook anymore.
Why Does This Happen?
SiteVault Pro’s full backup engine splits work across many WP-Cron resumptions to avoid PHP timeouts on slow hosts. Each cron tick processes a chunk of files and schedules the next tick a few seconds later. The system cron entry that’s already configured on most shared hosts — wp cron event run --due-now --quiet — is supposed to fire every queued event whose timestamp is now or earlier.
On certain shared hosts, the --due-now evaluator silently skips specific hooks. The exact cause varies — we’ve seen it correlate with mod_security WordPress add-ons, with certain security plugins that filter pre_get_ready_cron_jobs, and with shared hosts running customized WP-CLI builds — but the practical effect is identical: rb_backup_resume sits in the cron queue marked “due”, the runner reports “Executed 0 cron events”, and the backup chain never advances.
Targeting the hook by name with wp cron event run rb_backup_resume bypasses the filter because the named-hook runner doesn’t apply the same pre-flight check. The hook fires, the backup advances, and the chain self-drives to completion.
SiteVault Pro 1.7.10 added diagnostic logging to detect when wp_schedule_single_event fails (1.7.11 extended the same diagnostic to the very first scheduling call) — but the failure mode here is different: the event does get scheduled, the host’s cron runner just refuses to fire it. There’s no plugin-side fix beyond what 1.7.11 already does. The fix has to be at the cron-configuration layer.
Still Stuck After Adding the Cron?
If you’ve added the dedicated cron entry, waited a few minutes, triggered a fresh backup, and the log still stops at “Async backup started”, contact support@royalplugins.com with the following:
Information We’ll Need
- Last 50 lines of
wp-content/uploads/sitevault/logs/royal-backups-YYYY-MM-DD.log - Hosting provider name (HostGator, Bluehost, SiteGround, etc.) so we can check whether we’ve seen this on that host before
- WP-CLI output if you can run it:
wp cron event list | grep rb_ - Output of
wp plugin list --status=active— sometimes a security plugin is the actual filter and we can identify it - Whether your scheduled hourly database backups are completing normally (helps narrow down whether it’s the resumption hook specifically or a broader cron failure)