Skip to main content
Snapshotify > Backups

​
The backup list

Every backup shows its title, contents, size, location, and date. Contents appear as badges, so you can see at a glance whether a given archive has your database, your media, or your core files. Per backup you can restore it, download it, delete it, or open its activity log.
The activity log is the first place to look when something is odd. It records each stage of the job and any warning that did not stop it, including the reason a cloud upload fell back to local.

​
Creating one

Select Create Backup.
​
string
Name it for the reason you took it. “Before WooCommerce 9 update” tells you months later whether this is the one you want.
​
toggle
default:"on"
A preset meaning “exclude nothing”. Turning it off reveals the five exclusion checkboxes.
​
checkboxes
WordPress Core, Media Library, Plugins, Themes, Database. Independent, so combinations like “everything except media” are expressible.
​
select
default:"local"
Local, or a connected cloud provider on Pro.
Excluding all five is refused, and the submit button is disabled rather than failing after you click. There would be nothing left to back up.

​
What an archive contains

Always database.sql and manifest.json, plus whatever you did not exclude. The manifest records what is inside, the WordPress version, the site URL, and the table prefix. That is what makes a restore onto a different site possible: the restore reads the manifest rather than assuming.

​
Always excluded

Some things never go in, regardless of your choices, and each has a reason.
.user.ini is the one worth understanding. Security plugins write an auto_prepend_file line into it containing an absolute path on the source server. Restore that onto a different host and every request fatals before WordPress boots, including wp-admin. Excluding it is what makes cross-host restores survivable.
This is why Snapshotify archives are often two to four times smaller than another plugin’s for the same site. Uncompressed formats that include caches and development artifacts are bigger without holding more of your site.

​
Choosing scope

For anything you might actually restore from, take a full site backup. The exclusions exist for size problems, and each one costs you something.
Excluding the database is almost never right. It leaves you with a copy of the files and none of the site.

​
While it runs

Progress is shown live. You can close the tab. The job continues on its own, because the work is done in short ticks that save progress after each one. Cancelling stops the job and cleans up the working files. A cancelled job sends no notification, since you already know.

How backups run

Why a job continues without the page open, and what to do when it stalls.

​
Uploading an archive

Upload Backup takes a Snapshotify archive from elsewhere: another site, or a copy you downloaded before rebuilding a server. It is uploaded in chunks, so large archives work within normal request limits. Once uploaded it behaves like any other backup in the list, and restoring it onto a different domain is a migration.
An archive whose manifest is incomplete still restores. Snapshotify falls back to what is actually present in the extracted tree rather than trusting the manifest alone, which is what stops an odd archive reporting success while restoring nothing.

​
Good practice

1

Back up before anything risky

Updates, theme changes, migrations, and your own experiments. That is when a backup earns its existence.
2

Name backups for the reason, not the date

The date is already in the row.
3

Get at least one copy off the server

Download it, or connect cloud storage.
4

Restore one onto staging, once

It is the only way to know your backups work. Almost nobody does this, which is why broken backups are discovered at the worst moment.