Skip to content

Security

Backup before you “clean” anything

Save a full, restorable copy before you delete files, run cleaners, or change permissions in bulk.

Updated Aug 29, 20263 min read15 reads
Backup before you “clean” anything
Take a restore-ready copy before you remove anything

A backup before cleanup means you save a full, restorable copy of the site before you delete files, run a cleaner, or change permissions in bulk. That copy is what lets you undo a bad guess. Without it, a cleanup can leave you with a blank disk and no way back.

Malware tools are often optimistic. They may remove real shells and also remove theme or plugin files that only looked suspicious. A copy from a few minutes earlier is safer than any clever pattern match. If Imunify already quarantined something, mention that in your ticket instead of restoring over it and asking us to chase a missing file.

What counts as a real backup

You need the site files, the database, and anything outside public_html that you still care about, such as cron jobs or mail. A zip of wp-content alone is not a restore plan. On shared hosting, JetBackup is the built-in option we provide. On a VPS, take a snapshot and keep an off-box database dump of your own. If Imunify quarantined files, treat that as helpful context, then still keep a full independent copy of the rest.

Do not leave database dumps inside the document root. Do not name them something obvious like backup.sql.gz. Automated scanners will find and fetch them.

How cleanup goes wrong

One-click harden tools sometimes delete shells and also delete your theme. Security plugins can quarantine wp-config. A recursive delete aimed at “bad” PHP can match WooCommerce or other legitimate code. Running chmod -R 777 before a cleaner makes ownership and intent even harder to judge. Stop and copy first. If you already cleaned and the site is blank, we need the backup date and filename, not a long description of the malware. We cannot reverse a deletion we never saw.

A safe order of steps

  1. Create a JetBackup checkpoint on shared hosting, or a VPS snapshot, plus a database dump stored outside the document root.
  2. Write down what you believe is malware: full path and date, not a vague note about “a hacker.”
  3. Remove or quarantine only that path. Do not run chmod -R 777 across the account.
  4. Load the site in a private window, then check again from a phone on cellular data before you discard the copy.

A restore plan is a filename and time you have already verified, not a hope that JetBackup “should” work. On a VPS, know whether you will revert a snapshot or unpack a tar archive; those are different procedures. Write the backup name and timestamp down before you clean. If a cleaner already ran, tell us which date you restored from and whether you ran the same cleaner again afterward.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Was this article helpful?

Be the first to rate this article.