Skip to main content
Backing up a WordPress site takes longer than a web request is allowed to last. Every backup plugin has to solve that, and how it solves it determines whether backups work on cheap hosting.

​
Ticks

Snapshotify does the work in ticks: short bursts of roughly twenty seconds, each saving its progress before ending. A backup moves through stages: initialize, dump the database, scan files, archive them, finalize. Each tick advances as far as it can within its budget and writes state to disk. The next tick picks up exactly there.
This is why a backup interrupted by a PHP timeout resumes rather than restarting, and why a very large site completes on hosting that would never allow one long request.
Ticks are lock-guarded, so overlapping attempts cannot corrupt a job. Several things may try to advance the same backup at once, and only one does at a time.

​
Three things drive it

Deliberate redundancy: hosts break these in different ways, so Snapshotify uses all three.
1

Loopback requests

The site makes an HTTP request to itself to trigger the next tick, chaining until the job is done. Fast, and the primary mechanism.
2

A cron watchdog

A WordPress cron event re-arms itself roughly every minute while a job is running, advancing anything that has stalled.
3

Inline ticks from the admin screen

While the Backups page is open, its progress polling also advances the job.
Scheduled backups on Pro add a fourth path: they drive the job to completion inside the cron request itself, within a fifteen-minute budget. That is what makes scheduled backups reliable on hosts where loopback requests do not work.

​
When loopback is blocked

Many hosts, and nearly every local development environment, block a site from making HTTP requests to itself. The visible symptom is a backup that progresses only while the Backups page is open, then appears to stall when you navigate away.
It is not broken. The cron watchdog still advances it, just more slowly, and it will finish. If you want it to go faster, leave the Backups page open.
Local environments using a self-signed certificate or a container that cannot resolve its own hostname are the common case. This is an environment limitation, not a plugin fault, and it does not occur on normal hosting.

​
Why this shape

Two alternatives, and why they are worse. Ticks with saved state give resumability for free. Nothing is lost to an interruption beyond the seconds since the last save.

​
What this means for you

The job continues. Reopen the Backups page to see where it got to.
Different situation. A restore replaces the site underneath itself, and you want to be watching. The plugin says so on screen.
If progress stops, the loopback chain has probably broken. Open the Backups page and leave it open; its polling advances the job.
The job stops and its working files are removed. No notification, since you already know.

​
Where the work happens

Working files live in wp-content/uploads/snapshotify/tmp/{id}/, including the state file that makes resuming possible. They are removed when the job finishes or is cancelled.
Leftover directories in tmp/ after a hard crash are safe to delete. They belong to jobs that will never resume.

​
Tuning it

Developers can extend the completion budget for scheduled backups:
Worth doing on a large site whose scheduled backup does not finish inside the default fifteen minutes, and only if your host allows cron requests to run that long.

Hooks reference

Every filter and action, including the pipeline and storage ones.