The scheduled backup runs at 3am. Files and database package fine. Then Google Drive returns a blip, Dropbox rate-limits, or OneDrive needs a token refresh. Without retries, you wake up to a green “local only” story and a missing off-site copy. The night you need the cloud archive is the night that gap matters.
Snapshotify Pro sends snapshots to Google Drive, Dropbox, and OneDrive. The product promise is blunt: it reconnects and retries an upload that failed, and backups always complete locally if a cloud upload fails, so a backup is never lost. Off-site is the point. Local completion is the safety net while the cloud side comes back.
Snapshotify is the DaftPlug backup plugin. This post is only about cloud upload retries and local completion when the remote push fails. Not portable ZIP format as the main topic (see yesterday’s angle), not batched restore mechanics, not chunked upload of an existing ZIP as the hero feature, not migration, not email notifications, not retention policies, not database-only backups as the main topic (one sentence of context is fine). Those live elsewhere. For the portable archive story, keep WordPress portable backup ZIP and SQL nearby.
What Snapshotify actually ships here
Stay inside the real feature set:
- Cloud storage destinations: Google Drive, Dropbox, and OneDrive
- Ability to use more than one destination at the same time
- Reconnects and retries an upload that failed
- Backups always complete locally if a cloud upload fails, so a backup is never lost
- Off-site copies as the resilience point (not the same disk as the site)
- Pro territory for scheduled automatic backups and cloud storage (free covers manual backup, upload, restore, and migration)
This post does not invent undocumented retry counts, exponential backoff charts, or claims that every cloud vendor outage is invisible forever. The verified promises are reconnect/retry on failed upload, and local completion so a backup is never lost when the cloud side fails. Stay there.
Why retries and local completion matter
Cloud APIs fail for boring reasons. Auth expiry, rate limits, brief regional incidents, mis-clicked OAuth consents, workspace policy changes. A backup product that treats the first failed PUT as final creates calendar gaps.
Off-site only counts if the file arrives. A local ZIP on the same server that just died is not a recovery plan. Retries exist so temporary cloud errors do not erase the off-site habit you thought you had.
Local completion prevents total loss. If the upload fails hard, you still want the snapshot finished on disk so a human can push it, download it, or wait for reconnect. Snapshotify’s readme-level improvement states backups always complete locally if a cloud upload fails. That is the lifeboat while retries work.
Schedules amplify silence. Nightly jobs fail when nobody is watching. Retries turn many transient failures into successful remote copies before morning. Persistent auth errors still need a human. Retries buy you time. They do not replace reconnecting a revoked app.
Multi-destination reduces single-cloud drama. Snapshotify can send to more than one cloud at once. A Drive blip hurts less when Dropbox still received the twin. Retries still matter for the destination that failed.
Same-server backups remain a trap. Even with perfect retries, keeping the only copy on origin disk fails when the disk fails. Cloud destinations are the point of this post. Local completion is the fallback, not the strategy.
How to trust cloud retries in wp-admin
Assume Snapshotify is installed and Pro cloud destinations are available.
1. Connect at least one real off-site destination
In Snapshotify settings, connect Google Drive, Dropbox, or OneDrive. Prefer two destinations for production sites that cannot tolerate a single vendor bad day. Authorize with an account your team controls. Document which identity owns the OAuth app.
2. Run a manual backup that must reach the cloud
- Start a full snapshot (files plus database) while destinations are connected.
- Confirm the local archive completes.
- Confirm the cloud UI shows the new file (or that Snapshotify reports a successful remote push).
- Note the size and timestamp so you can recognise the object later.
If local completes but remote fails, you are in the exact scenario retries and local-completion exist for. Do not delete the local copy while you fix auth.
3. Rehearse a failure once on purpose
On staging (or a maintenance window):
- Revoke or disconnect a destination briefly.
- Run a backup.
- Confirm the backup still completes locally so nothing is lost.
- Reconnect the destination.
- Confirm Snapshotify reconnects and retries the failed upload (or completes the remote push after auth is healthy again).
Seeing retry behaviour once teaches the team what “failed upload” looks like before an outage teaches them the hard way.
4. Keep schedules honest
Daily, weekly, or monthly schedules only help if destinations stay authorized. After password resets or Google Workspace policy changes, re-check cloud connections. Retries recover transient errors. They will not forever bypass a permanently revoked token without a human reconnect.
5. Remember what this post is not solving
Portable ZIP/SQL readability, chunked upload of an existing archive, migration URL rewrite, email notifications, retention pruning, and database-only snapshots are valuable. They are not today’s hero. One sentence of context: a database-only run before a plugin update is fine, and it should still enjoy the same cloud retry story when Pro destinations are attached. Then return focus to failed upload recovery.
6. Verify restore paths from the cloud copy
A retried upload is only useful if you can restore from that remote object. Spot-check download or dashboard restore from the cloud on staging. Off-site storage earns its keep when the bad day starts in the cloud list, not in a forgotten local directory.
What good looks like
- At least one of Google Drive, Dropbox, or OneDrive is connected (two is better).
- Snapshotify reconnects and retries failed uploads rather than abandoning the remote copy after one blip.
- When a cloud upload fails, the backup still completes locally so a copy is never lost.
- Schedules produce remote objects you can see in the vendor UI.
- Portable ZIP deep-dives, batched restore essays, migration runbooks, email notification setup, and retention tuning were not required for this win.
- A teammate can explain: local finishes even if cloud flakes; retries push the off-site copy when the destination is healthy again.
- You did not invent retry SLAs the product page does not state.
If every run fails remote and local disks fill with archives, fix the OAuth connection and retention. Retries are not a substitute for a connected destination.
Pitfalls (the ones that bite)
Calling a same-server ZIP “off-site.” It is not. Cloud destinations are the bar.
Assuming retry means ignore red jobs forever. Persistent auth failures need a human reconnect.
Deleting local archives immediately when cloud is configured. Keep enough local history to survive a retry window, within disk sense and retention policy.
One destination only on a critical store. Multi-destination exists for a reason.
Never rehearsing disconnect/reconnect. First production failure is a bad training environment.
Mixing migration day with retry day. Move hosts with a clean, verified archive. Debug OAuth separately.
Forgetting vendor quotas. Retries cannot fix a full Drive. Watch storage.
Treating email notifications as optional forever. They are a separate feature, but ops teams still need some alert path. This post does not make notifications the topic. Just do not fly blind.
Practical checklist before you call it done
- Connect Google Drive, Dropbox, or OneDrive in Snapshotify Pro (ideally two).
- Run a manual full backup and confirm the object appears in the cloud UI.
- Disconnect a destination on staging, run a backup, and confirm local completion.
- Reconnect and confirm retry / successful remote push afterward.
- Enable a schedule that matches how often you can tolerate data loss.
- Confirm disk space can hold local completion during cloud incidents.
- Document which team account owns each OAuth connection.
- Spot-check restore or download from a cloud copy on staging.
- Leave portable-format essays, migration, retention deep-dives, and notification setup for their own checklists.
- Re-verify cloud auth after any password or workspace policy change.
What a failed upload should look like in practice
A healthy failure is noisy enough to notice and safe enough to survive. Local status shows a completed archive. Cloud status shows a retry, a pending push, or an error you can fix with reconnect. The vendor folder either gains the file after retry or clearly lacks it until auth is healthy. That clarity beats a silent gap in the calendar.
Train one other person on the reconnect click. Retries help at 3am. Humans still own OAuth. If your only operator is on holiday when Google revokes the app, the local completion promise is what keeps you from having zero copies, and the second destination is what keeps off-site alive.
Takeaway
A WordPress backup that dies on the first failed cloud PUT is not an off-site strategy. Snapshotify Pro pushes snapshots to Google Drive, Dropbox, and OneDrive, reconnects and retries an upload that failed, and still completes the backup locally if the cloud upload fails, so a backup is never lost. Off-site remains the point. Local completion and retries are how you survive flaky APIs without waking up empty-handed.
Snapshotify is built for that loop: package the site, push off-server, retry when the pipe flakes, keep a local finish when it must. Connect destinations. Rehearse a failure once. Keep restore practice on the calendar.
One Pro membership unlocks Snapshotify plus Progressify, Lightify, Generatify, and Rankify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when failed cloud uploads should retry instead of quietly leaving you without an off-site copy.
Connect a destination. Break auth once on staging. When local still finishes and the retry lands after reconnect, your backup plan finally matches how clouds actually behave at 3am.