If a migration fails with a message about the source pull, it means the destination couldn’t download a usable backup from your old host. This is one of the more common hiccups and usually has a straightforward fix.
What ‘source pull’ means
After your backup is built on the old host, iWebVault downloads (pulls) it directly. ‘Source pull failed’ means that download didn’t produce a valid backup file — so the restore couldn’t proceed.
Common causes
- The backup wasn’t actually complete when the pull ran — most common on very large accounts
- Credentials or access changed on the old host mid-migration
- The old host blocked or rate-limited the backup access
- A transient network blip between the two servers
How to fix it
- Simply retry — transient issues clear on a second attempt
- For a large account, ask us to raise the per-account time ceiling so the backup has time to finish before the pull
- Re-confirm your old host credentials are still valid
- Check the old host hasn’t disabled backups for the account
Reading the per-account log
The migration’s log shows exactly which step failed. If it shows the backup was still small or building when the pull ran, that confirms a timing issue. If it shows an access error, that’s a credentials or permissions problem on the old host.
Where the source pull sits in the process
The migration runs in stages: connect, build the backup on the old host, pull that backup to iWebVault, then restore. ‘Source pull failed’ means the third stage didn’t produce a valid, complete backup file on the iWebVault side — so the restore couldn’t safely begin. Pinpointing why is usually quick because the per-account log shows the state of the backup at the moment of the pull.
Cause 1 — the backup wasn’t finished
The most frequent cause, especially on large accounts, is that the backup on the old host hadn’t fully completed when the pull ran. The fix is to give the backup more time by raising the per-account time ceiling, then retrying. With more headroom the backup finishes, the pull gets a complete file, and the restore proceeds.
Cause 2 — access changed mid-migration
If the old host credentials were changed, or the account was suspended, partway through, the pull can fail because access was lost. Re-confirm the account is active and the credentials are current on the old side, then retry.
Cause 3 — the old host blocked or throttled access
Some hosts rate-limit or temporarily block repeated backup access. If you’ve retried several times in quick succession, wait a while to let any throttle clear, then try again. If the host is actively blocking external access, that’s something to raise with them or to work around with our help.
Cause 4 — a transient network blip
Occasionally a momentary network issue between the two servers interrupts the pull. These clear on a simple retry — try once more before digging deeper.
Using the log to confirm the cause
Open the per-account log. If it shows the backup was still small or building at pull time, that confirms a timing cause — raise the ceiling. If it shows an authentication or permission error, that’s a credentials/access cause — fix it on the old side. The log turns guesswork into a clear diagnosis.
When to escalate
If you’ve retried, given large accounts more time, and confirmed credentials, but the pull still fails, open a ticket and quote the log’s error. At that point it’s usually something specific to the old host’s configuration that we can identify and work around.
Putting the error in context
The migration runs through connect, build-backup, pull, and restore. ‘Source pull failed’ is specifically the third stage reporting that it couldn’t obtain a complete, valid backup file on the iWebVault side, so the restore couldn’t safely begin. The good news is the per-account log captures the backup’s state at the moment of the pull, which usually makes the cause obvious without guesswork.
The dominant cause: incomplete backup
On large accounts, the most common reason is simply that the backup on the old host hadn’t finished building when the pull attempted to fetch it. The remedy is to give the backup more room by raising the per-account time ceiling, then retrying. With more headroom, the backup completes, the pull retrieves a whole file, and the restore proceeds normally. This single fix resolves the majority of source-pull failures on big accounts.
Access and connectivity causes
- Credentials changed mid-migration — re-confirm they’re current and retry
- Account suspended on the old host — reactivate it, then retry
- Old host rate-limited or blocked access — wait for any throttle to clear, then retry
- Transient network blip — clears on a simple retry
A sensible order of response
Work from simplest to deepest: first retry once for transient issues; if it’s a large account, raise the time ceiling and retry; if access errors persist, re-verify credentials and confirm the account is active on the old host. Following that order resolves nearly every case without unnecessary investigation.
Letting the log guide you
Open the per-account log to confirm the cause rather than guessing. If it shows the backup was still small or building at pull time, that’s a timing cause — raise the ceiling. If it shows an authentication or permission error, that’s a credentials or access cause — fix it on the old side. The log converts a frustrating failure into a clear, addressable diagnosis.
When to escalate
If you’ve retried, given large accounts more time, and confirmed credentials and account status, yet the pull still fails, open a ticket and quote the log’s exact error. At that point the cause is usually something specific to the old host’s configuration — a firewall rule, a backup restriction — that we can identify and work around for you.
What’s next
- Migration Backup Seems Stuck
- Migrating Very Large Accounts
- “Access Denied” Connecting to Your Old Host
Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.
Was this helpful?
Thanks for your feedback!
