# Backup Stuck on “Async Backup Started” (Shared Hosting)
> SiteVault Pro backup stuck on 'Async backup started' on shared hosting means the host is filtering the rb_backup_resume cron hook. Here is the cron fix.
- Canonical:
- HTML version:
---
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.
### Most Common Shared Hosts Affected
HostGator, Bluehost, SiteGround entry tier, GoDaddy, and other budget shared hosts that run mod\_security or aggressive WP-Cron filtering. Premium managed hosts (WPEngine, Kinsta, Cloudways) are typically not affected because they run dedicated cron daemons.
## 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 started` with 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
Why DB backups still work
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.
Don’t remove your existing cron entries
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.
This is a host-level issue, not a SiteVault bug
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? Email Priority Support
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”, email **[support@royalplugins.com](mailto:support@royalplugins.com)** with the diagnostic info below. Priority email support is included with your SiteVault Pro license — typical response time is within 24 hours.
#### 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)
[Back to SiteVault Support](https://royalplugins.com/support/sitevault/)
[Disaster Recovery Guide](https://royalplugins.com/support/sitevault/disaster-recovery/)