A full-site backup should save the WordPress you need to restore, not every cache object, log line, and transient junk folder your stack regenerated five minutes later. Bloated archives take longer, cost more offsite storage, and make “did it finish?” a weekly anxiety. Snapshotify’s Smart File Exclusions let you exclude files by your own criteria so backups skip caches, logs, and other files you do not need, while full-site ZIP+SQL and one-click backup/restore stay the recovery path.
Snapshotify is the DaftPlug backup plugin. This post stays on Smart File Exclusions. For the baseline full snapshot flow, keep WordPress one-click full site backup nearby. Snapshotify’s FAQ also notes you can set exclusions to skip caches, logs, and other files you do not need. This post does not invent glob syntax, regex builders, or exclusion marketplaces beyond “exclude files by your own criteria.”
What Snapshotify actually ships here
Stay inside the real feature set:
- Smart File Exclusions to exclude files by your own criteria
- Practical targets called out in product messaging and FAQ: caches, logs, and other files you do not need
- Full-site snapshots as ZIP + SQL, readable without the plugin
- One-click backup and one-click restore as the surrounding workflow
- Sibling capabilities you will only mention to exclude from this hero: cloud destinations, schedules, retention, database-only backups, migration rewrites
This post does not invent undocumented “exclude presets marketplace,” per-plugin automatic exclusion packs Snapshotify does not list, or promises that exclusions rewrite database rows. Exclusions are about files in the archive. The SQL dump still captures the database unless you chose a database-only backup in a different workflow.
Why smart exclusions matter on real WordPress hosts
Caches are disposable by definition. Object caches, page caches, and optimizer cache directories often rebuild on demand. Backing them up inflates ZIP size and restore time for little recovery value.
Logs grow without helping last week’s restore. Debug logs, server logs copied into the web root, and plugin log directories can dominate disk while adding nothing you want to restore onto a clean host.
Offsite bills follow archive size. Google Drive, Dropbox, and OneDrive destinations (Snapshotify Pro cloud options) store what you send. Smaller, saner archives mean retention policies stretch further.
Large sites already push host limits. Snapshotify batches and chunks so big sites can finish, but you should still avoid packing regenerable junk. Exclusions are the polite partner to batched processing.
Restore clarity improves when noise shrinks. A leaner archive is easier to download, easier to move, and easier to reason about when you are restoring under pressure.
How to set Smart File Exclusions without hurting restores
Assume Snapshotify is installed. Assume you already know how to run a one-click full-site backup (files + database in one archive). If not, run that happy path once before you tune exclusions.
1. Decide what is regenerable versus irreplaceable
Regenerable (typical exclusion candidates): cache directories, log files, temporary optimizer folders, other junk your stack recreates.
Irreplaceable: uploads you care about, theme and plugin code you rely on, wp-config and core files as your process expects, and anything custom that is not rebuilt automatically.
When unsure, exclude less on the first pass. A slightly larger backup beats a restore missing a critical custom directory.
2. Open Snapshotify and find Smart File Exclusions
In wp-admin, open Snapshotify. Locate Smart File Exclusions (exclude files by your own criteria). Set criteria that match caches, logs, and junk you have already identified on disk. Stay inside what the product describes. Do not invent advanced glob dialects in your documentation if you have not verified them in the UI you actually see.
3. Run a full-site backup after exclusions
- Keep the destination you already trust (local download and/or cloud if Pro schedules are in play).
- Run a one-click full-site backup.
- Note duration and archive size versus your last run before exclusions.
- Confirm the archive is still ZIP + SQL in the sense Snapshotify documents (standard formats readable without the plugin).
- Do not delete your previous known-good backup until the new one is verified.
4. Verify with a restore drill (staging if you can)
The only exclusion test that matters is restore:
- Restore onto staging or a disposable copy when possible.
- Confirm the site boots, media that matters is present, and regenerable caches can rebuild.
- Confirm you did not exclude an uploads subdirectory you actually needed.
- If something critical is missing, tighten criteria (exclude less), run again, and repeat the drill.
Production-only shops should still download and inspect archive contents carefully before trusting a new exclusion set.
5. Keep database-only and full-site purposes distinct
Database-only backups are a different Snapshotify feature for update-night speed. Smart File Exclusions tune what goes into file-heavy full snapshots. Do not confuse “I excluded caches” with “I only backed up SQL.” If you need a DB-only snapshot before a plugin update, use that feature intentionally. If you need a full restore later, you need a full snapshot with sensible file exclusions, not a SQL-only file pretending to be everything.
6. Document the exclusion policy
Runbook: “Snapshotify Smart File Exclusions set on [date]. Criteria aim at caches/logs/junk: [describe in plain language]. Last verified restore drill: [date/URL]. Full-site ZIP+SQL still required weekly/monthly as per schedule. Do not widen exclusions before another restore test.”
Who this is for
Sites with aggressive caching or optimization plugins whose cache folders dwarf uploads.
Stores and membership sites where offsite retention matters and archive size hits provider quotas.
Agencies standardizing backup policy across client hosts with different junk directories.
Anyone whose full backups time out or feel endless even though Snapshotify can batch, because the ZIP still includes regenerable bulk.
Teams that already run one-click full-site backups and want the next maturity step without switching products.
This is less urgent for tiny brochure sites with almost no cache footprint. Even then, a log directory can surprise you after a debug weekend. Exclusions remain cheap insurance.
What good looks like
- Smart File Exclusions are set by your own criteria aimed at caches, logs, and junk.
- Full-site backups still produce a usable ZIP + SQL style archive Snapshotify can restore in one click.
- Archive size and duration drop without missing irreplaceable uploads or custom code.
- A restore drill on staging (or careful archive inspection) confirms the site returns.
- Cloud, schedule, and retention settings were not required to validate exclusions, though they benefit from smaller archives.
- You did not invent exclusion syntax beyond what the product describes.
- The related one-click full-site backup flow remains the mental default for recovery.
If the site restores without media you needed, your criteria were too hungry. Put those paths back in the backup, rerun, and re-verify.
Pitfalls (the ones that bite)
Excluding uploads because it is large. Size is not the same as regenerable. User media is usually irreplaceable.
Widening exclusions after one successful backup without a restore drill. Backup success is not restore success.
Thinking exclusions replace offsite copies. They make offsite cheaper. They do not put backups on Drive/Dropbox/OneDrive by themselves.
Mixing database-only night shots with “we excluded enough files” folklore. Different tools for different risks.
Leaving debug logging on forever, then excluding logs, then needing those logs for an incident. Excluding logs from backups is fine. Deleting the only copy of a forensic log is a process mistake. Keep operational awareness separate from backup exclusions.
Never revisiting criteria after a stack change. New cache plugins create new directories. Review exclusions when you change performance stacks.
Inventing fancy patterns you did not test. Plain, verified criteria beat clever untested rules.
Practical checklist before you call it done
- Run and keep one known-good full-site backup before changing exclusions.
- Inventory regenerable caches/logs/junk versus irreplaceable uploads and code.
- In Snapshotify, configure Smart File Exclusions by your own criteria.
- Run a new full-site one-click backup.
- Compare size and duration to the previous archive.
- Restore-drill on staging when you can.
- Confirm critical media and custom files survived.
- Only then let scheduled/cloud jobs adopt the new exclusion set.
- Leave retention, migration, and database-only features as separate documented workflows.
- Revisit exclusions after installing new cache or log-heavy plugins.
- Write the plain-language criteria and last drill date in the runbook.
- Keep the one-click full site backup post linked for teammates who still need the baseline.
Takeaway
Full-site backups should be complete, not obese. Snapshotify Smart File Exclusions exclude files by your own criteria so caches, logs, and junk stop dominating ZIP + SQL archives. One-click backup and restore remain the recovery motion. Smaller archives simply make that motion faster and cheaper to store offsite.
Snapshotify includes Smart File Exclusions beside full-site snapshots, database backups, schedules, and cloud destinations when you need them. Set criteria carefully. Prove a restore. Then let the schedule inherit the leaner archive. Start from a solid one-click full site backup habit, then trim.
One Pro membership unlocks Snapshotify plus Progressify, Lightify, Generatify, and Rankify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when backups should skip regenerable junk and still restore the site you meant to keep.
Exclude the caches and logs. Keep the uploads and code. When the restore still boots clean, the backup finally matches what recovery needs.