Scheduled backups are useless if they fill the disk and then fail silently. The first week looks fine. By month three, Google Drive is full of 40 nearly identical full-site archives, new runs error out, and nobody notices until the day you need a restore.
Retention is the boring control that keeps backups alive. Not “infinite history.” A policy: keep N copies, or keep anything newer than X days, per destination, and prune the rest on purpose.
Snapshotify is the DaftPlug backup plugin. It lets you set retention by count or by age, per destination. Oldest automatic backups are pruned after every run. You see storage in use before you change anything. Manual and uploaded backups are never auto-deleted. Only automatic scheduled backups are pruned.
What Snapshotify actually ships for retention
Stay inside the real feature set:
- Retention keep by count or by age
- Policies are per destination
- Oldest pruned automatically after every run
- Storage in use shown before you change anything
- Retention only prunes automatic scheduled backups (manual / uploaded never auto-deleted)
Supporting context you can rely on in the same plugin: Google Drive / Dropbox / OneDrive, multiple destinations, scheduled daily / weekly / monthly, full + database-only snapshots, one-click restore, migration URL rewrite, batched large sites, email notifications.
If you still need the reminder that a copy on the same VPS is not offsite safety, read A WordPress backup on the same server is not a backup. Retention assumes you already send archives somewhere that is not the origin disk alone.
Why per-destination retention beats one global number
Different clouds fill at different speeds. A database-only daily on Dropbox is tiny. A weekly full site on Google Drive is huge. One global “keep 30” policy either wastes space on the small destination or deletes history too aggressively on the large one.
Per destination means:
- Drive can keep 8 full weekly archives.
- Dropbox can keep 30 database-only dailies.
- OneDrive can keep a month of mixed runs for a staging clone.
You tune storage where the bill and the quota live. Snapshotify shows storage in use before you tighten or loosen a policy, so you are not guessing from the cloud provider’s UI alone.
How to set retention in WordPress with Snapshotify
1. Connect destinations before you obsess over counts
Connect Google Drive, Dropbox, and/or OneDrive. Use multiple destinations if you want redundancy (for example, weekly full to Drive, daily database-only to Dropbox).
Retention without an offsite destination just manages local pain. Get the cloud links working first. Confirm a test backup lands.
2. Schedule the runs that retention will manage
Pick daily, weekly, or monthly schedules that match risk:
- Daily database-only before you ship content or commerce changes
- Weekly full site for rollback comfort
- Monthly full as a longer floor if storage is tight
Retention prunes automatic scheduled backups. That is the point. Manual backups you trigger before a risky migration stay until you delete them yourself.
3. Open retention and read storage in use
Before changing numbers, look at storage in use for each destination. Snapshotify surfaces that so you can see whether you are already near a quota.
If Drive is at 95%, do not raise keep-count. Lower it, or move full backups to another destination, or switch some runs to database-only.
4. Set keep-by-count or keep-by-age per destination
Choose the model that matches how you think:
- By count: keep the newest 7 automatic backups on this destination, prune older ones after each run
- By age: keep automatic backups newer than 30 days, prune older ones after each run
Set them per destination. A sensible starter for many small shops:
| Destination | Schedule | Retention | | — | — | — | | Google Drive | Weekly full | Keep 6 (about six weeks) | | Dropbox | Daily database-only | Keep 14 days by age | | OneDrive | Monthly full | Keep 4 |
Adjust to your quota and how far back you actually restore. Most restores want last night or last week, not a random archive from 11 months ago.
5. Confirm what never gets auto-deleted
Manual backups and uploaded backups are never auto-deleted by retention. That protects the “I snapped this right before the page builder update” archive.
If you want that safety net forever, leave it. If a manual backup is huge and obsolete, delete it yourself on purpose. Retention will not surprise-delete it.
6. Run once and watch prune behavior
Trigger a scheduled-style run (or wait for the next cron). After the run, Snapshotify should prune oldest automatic backups according to the policy. Confirm:
- Newest backups remain
- Older automatic ones beyond the policy disappear from that destination
- Manual backups remain
Turn on email notifications so failed uploads or permission errors do not stay invisible while retention quietly has nothing new to keep.
7. Remember restore and migration still matter
Retention keeps storage healthy. Restore is why you bother. Use one-click restore in a staging test. If you are moving hosts, migration URL rewrite helps the site boot on the new domain. Batched large sites keep big uploads from dying mid-transfer. None of that replaces retention, but retention without a tested restore is still unfinished work.
What good looks like
A solid retention setup:
- Each cloud destination has an explicit keep-count or keep-age
- Storage in use is checked before policy changes
- Automatic backups prune after runs without filling the drive
- Manual pre-deploy backups remain until you remove them
- You receive email when a scheduled run fails
- You have restored a recent backup on staging at least once this quarter
On WooCommerce, good also means you know whether last night’s database-only is enough for “wrong coupon rule” vs needing a full file restore for a broken theme deploy. Retention policies should match those restore stories.
Pitfalls (the ones that bite)
Infinite retention “just in case.” Quotas fill. The next backup fails. You discover it during an outage.
One policy for every destination. Full-site Drive and tiny DB Dropbox are not the same animal.
Assuming retention deletes manual backups. It does not (for Snapshotify’s automatic-only prune). Do not rely on retention to clean manual clutter.
Never looking at storage in use. Changing keep-count blind is how you delete more history than you meant to, or not enough.
Same-server-only backups. Retention on the origin disk still dies with the server. Offsite destinations first. See the related post linked above.
Skipping notifications. Prune logic cannot help if uploads stopped two weeks ago.
Keeping 90 daily full backups of a 8 GB media library. Use database-only for frequent runs. Full less often. Retention then has less junk to chew.
Practical checklist
- Connect Google Drive / Dropbox / OneDrive (multiple if you want).
- Schedule daily / weekly / monthly jobs (full and/or database-only).
- Read storage in use per destination.
- Set retention by count or age per destination.
- Run a backup and confirm oldest automatic copies prune.
- Confirm a manual backup is left untouched.
- Enable email notifications.
- Test one-click restore on staging.
Takeaway
Backups fail in slow motion when storage fills up. Retention is how you keep the door open for the restore you will need later.
Snapshotify sets retention per cloud destination by count or age, shows storage in use before you change anything, prunes oldest automatic backups after every run, and never auto-deletes manual or uploaded archives. Pair that with Drive/Dropbox/OneDrive, sensible schedules, full plus database-only snapshots, notifications, and a tested one-click restore.
One Pro membership unlocks Snapshotify plus Progressify, Lightify, Generatify, and Rankify. New Pro plugins join existing memberships. See pricing when you want offsite backups that clean up after themselves.
Set the policy before the quota warning. Your future restore will not care about the 87th identical weekly zip. It will care that last night’s run still fits.