Backups: Stack Guard Docs

Backups

Make a full copy of the site, its database and files, with one click. Every backup is read back and checked before it counts, so a backup that says it is complete really is.

What it does

A full backup holds every database table of this site, everything in wp-content (plugins, themes, uploads) and the configuration file. A database only backup is quicker and smaller, useful before changing settings or content.

The backup runs in short steps in the background, so it finishes even on hosts with short time limits, and it carries on if you close the page.

When the copy is made, Stack Guard opens every archive again and checks every file and every database row against what it wrote. Only a backup that passes is marked Verified and offered for download and restore. A backup that fails a check is marked Failed, with the reason.

Why it matters

A backup that fails without anyone noticing is worse than none, because everyone believes the site is safe. Checking each backup, and showing when the last good one was made, means you know.

Make a backup

Go to the Backups tab.
Click Back Up Now for a full backup, or Database Only.
Watch the progress, or leave the page; the backup keeps going. It appears in the list when it is done.
To keep a copy somewhere else, click each part in the Download column.

Good to know

Large sites are split into parts of up to about 4 GB or 65,000 files (database.zip, files-001.zip, files-002.zip and so on). Each is an ordinary zip file that opens on any computer. A single file over 4 GB is left out and listed under Details; a database table whose copy is over 4 GB stops the backup with that reason, since backups of tables that large are not supported yet.

Caches, temporary files and other backup plugins' archives are left out, because they would only make backups larger. Add your own under Leave out, one per line: a name such as *.mp4 matches anywhere, a path such as uploads/videos starts from wp-content.

A file that cannot be read, or changes while it is copied, is listed on the backup under Details instead of stopping it.

Linked folders (for example an uploads folder kept on shared storage) are followed, so the files they point to are in the backup. Links that would loop, or point to something already in the backup, are left out. Each one is listed under Details.

Each download uses its own link, made when you click the part. It works only for you, while you are signed in, for one hour, and a dropped download can carry on where it stopped. Every download sends an email to the people who receive Stack Guard alerts, saying who downloaded which backup and from where, so an unexpected download never goes unnoticed.

Before it starts, a backup checks there is enough free disk space and stops with the reason if there is not.

Backups are stored outside the public web folder when the host allows, and otherwise in a folder with a random name and access rules that refuse web requests. Only the account the site runs as can read the files. They download only through this screen, for people with full Stack Guard access. Test Background Running also checks the folder cannot be fetched from the web; on servers that ignore the access rules (some nginx setups) it says so, and you can move the folder with the SMG_BACKUP_DIR constant in wp-config.php.

On a multisite network, backups cover every site, so only a network administrator can use them, from the main site.

If Server checks shows that background running is blocked, or WordPress scheduled tasks are off, ask the host to add the cron job shown there. With this page open, backups still finish either way.

Deleting the Stack Guard plugin keeps finished backups on the server, so a site is never left without its backups by accident.

Which plan includes it

Manual backups, downloads and the health checks are free. Google Drive, scheduled backups, alerts and automatic test restores are coming to Pro.

How it works, for developers

Classes SMG_Backup_Maker (the steps), SMG_Backup_Job (resumable job, row in smg_backup_jobs), SMG_Backup_Runner (drivers and lock), SMG_Backup_Store (folder and smg_backups rows). Steps: preflight, list files, dump the database, archive, verify, finalize; each saves its place at least once a second.
Three drivers move a job forward: a non-blocking request from the site to itself after every step (admin-ajax.php?action=smg_backup_tick, authenticated by a per-job token), a WP-Cron event smg_backup_tick one minute ahead, and the Backups tab polling every 3 seconds. A MySQL named lock lets only one run at a time. A job quiet for 3 minutes is restarted; one that fails or makes no progress 5 times in a row fails with the reason.
Archives are written by Stack Guard's own zip writer, without ZipArchive or shell commands, so they never need rewriting and survive interruption. The database is dumped in plain PHP, one SQL file per table, one statement per line.
Verification: CRC of every entry, every SQL line a complete statement, row counts against the dump, ZipArchive consistency check where available, and SHA-256 and MD5 of each part, stored in manifest.json in the backup folder.
Settings: smg_backup_include_core, smg_backup_exclude. Folder: the SMG_BACKUP_DIR constant when defined, saved in smg_backup_dir.

Quick answers about backups

What does Backups do in Stack Guard?

A full backup holds every database table of this site, everything in wp-content (plugins, themes, uploads) and the configuration file. A database only backup is quicker and smaller, useful before changing settings or content. The backup runs in short steps in the background, so it finishes even on hosts with short time limits, and it carries on if you close the page. When the copy is made, Stack Guard opens every archive again and checks every file and every database row against what it wrote. Only a backup that passes is marked Verified and offered for download and restore. A backup that fails a check is marked Failed, with the reason.

Why use backups on a WordPress site?