Security advisorywp2shell: WordPress core vulnerability. Updated August 7, 2026.
Read the advisoryPractical WordPress backup habits: what to copy, offsite storage, retention, and why a tested restore matters more than a folder of old ZIPs.
Topics Hardening & checklists Backups & recovery
Updated Published
Security reduces the chance of a bad day. Backups reduce the cost of one. If malware, a bad deploy, or a deleted database takes the site down, a recent offsite copy you have actually restored is what gets you online again.
Security Ninja is not a backup plugin. Pair prevention with a dedicated backup path. Buyer context: backup and security plugins.
A real backup is a copy of files and the database you can restore without guessing. Themes, plugins, uploads, and wp-config.php matter. So does the database: posts, users, WooCommerce orders, and settings live there.
Without a backup you are rebuilding by hand. That is slow, incomplete, and often impossible for the database.
Think of it like important files in cloud storage. The site deserves the same habit, with one extra rule: prove the restore works before you need it.
Backups are insurance, not permission to skip basics:
If you are already compromised, follow hacked site steps and malware removal. Restoring an infected backup without closing the hole repeats the incident.
Many WordPress-friendly hosts offer automatic server-level backups. Prefer plans where you can trigger or download a restore yourself, not only “open a ticket and hope.”
Host backups count when:
Hosts often expose a full account backup in cPanel or a similar panel. A full backup is usually safer than piecing files and databases by hand when you are in a hurry.
Manual work is slow and easy to get wrong under stress. Fine as a rare export. Poor as your only scheduled strategy.
Plugins are a common way to schedule files + database copies to offsite storage (S3, Backblaze, Drive, Dropbox, and similar). Before you trust one:
wp-content)Public backup ZIPs are a gift to attackers. Keep them off the webroot or lock them down.
A backup that lives only on the same server as the site dies with the server (ransomware, host failure, accidental wipe). Keep at least one recent copy somewhere else.
Cloud storage, a second host, or an encrypted local drive all beat “backup” directories on the production box.
Keeping every backup forever fills disks and confuses restores. Keeping only today’s copy means a quiet infection from last week overwrites your last clean point.
A practical pattern for many sites:
Adjust for how fast the site changes and how long it might take you to notice a problem.
Full site backups are the default restore path. Periodic exports of the database alone (or critical upload trees) can speed partial recovery. Do not skip full backups because you have a SQL dump.
There is no universal schedule. Match frequency to how much data you can afford to lose.
An untested backup is a hope file. Once, on staging or a throwaway environment:
That drill takes an hour. It saves days during an incident.
Back up files and the database on a schedule, store copies offsite, keep enough history to outlast a quiet compromise, and restore once on purpose. Everything else is decoration.
Found this useful? Share it.