Set your NAS to auto-delete backups older than 90 days

A retention policy that prunes anything beyond three months keeps your storage lean, your costs predictable, and your data recoverable when something goes sideways. Whether you run a two-bay Synology in a Brisbane home office or a rack-mounted QNAP in a Melbourne co-working space, automating the cleanup of stale backups removes the daily chore of manual pruning and the risk of forgetting until the volume fills up at 2am.

Most Australian households and small businesses settle on a ninety-day window because it lines up neatly with quarterly reporting cycles, the ACSC's guidance on regular backup rotation, and the practical limits of NBN upload speeds when you're pushing terabytes to the cloud. It also gives you a full season's worth of snapshots - long enough to roll back a corrupted file, short enough that an old 8TB Ironwolf isn't choked with archives nobody has opened since the last Sydney thunderstorm.

Why a ninety-day retention window fits local setups

Storage costs in Australia run higher than in many overseas markets, particularly once you add the GST line item and factor in the limited supply of certain NAS-grade drives. A four-bay chassis populated with 16TB Exos drives can easily blow past four thousand dollars before you've installed a single app, so making that investment last means not letting it become a dumping ground for files that lost their relevance last summer.

There's also a regulatory nudge. The Notifiable Data Breaches scheme under the Privacy Act expects organisations to keep records for reasonable periods, but it doesn't ask you to hoard personal data indefinitely. A three-month rolling backup satisfies operational recovery needs while keeping your exposure window short. For solo operators and small teams in Adelaide or Perth, that balance is usually the deciding factor between aggressive pruning and a "keep everything forever" mindset that inevitably ends in a full disk and a panicked weekend.

Finally, consider the climate. A NAS sitting in a poorly ventilated garage through a Darwin wet season or a Hobart winter is already under thermal stress. Smaller, well-managed volumes put less strain on drives that are working harder than their spec sheets suggest they should.

Planning your storage pool before switching on auto-delete

Before you schedule a single deletion, map out where each backup actually lives. On Synology, that's usually a dedicated volume or shared folder inside Storage Manager; on QNAP, it's a similar arrangement under Storage & Snapshots. Separating your backup target from your live working data is the single most important habit, because it stops a stray retention rule from sweeping through your current projects.

If you are working with a single large capacity drive rather than a multi-bay array, partitioning it into multiple volumes lets you isolate backups on their own logical drive. The walkthrough at https://whichnas.com/news/2026/09/how-to-partition-a-single-large-drive-into-multiple-volumes-on-a-nas covers that process in detail, including the trade-offs around filesystem choice and SHR versus RAID 0 layouts.

Once volumes are separated, note the absolute paths. On DSM these typically look like /volume1/backups/; on QTS you'll see /share/Backups/ or similar. Get those paths right now, because every rule and script you build later depends on them.

Building retention rules in Synology DSM and QNAP QTS

Synology's Hyper Backup lets you set a retention policy directly when you create a backup task. Open the wizard, pick your destination, and under the Backup Rotation section you'll find options for Smart Recycle, GFS-style rotation, or a simple "keep the last N versions" count. Smart Recycle is the closest match for a flat ninety-day window because it tracks age rather than total version count, dropping anything older than the threshold you set.

For users who want stricter behaviour, DSM's Snapshot Replication offers a similar retention slider on each schedule. Set it to ninety days, enable the schedule, and confirm under Task Settings that the system will run the prune step even if the snapshot itself fails - that's the only way to guarantee that a hung backup job doesn't leave yesterday's data forever.

QNAP takes a slightly different path through Hybrid Mount and the Snapshot Manager. Under Snapshot Manager, each volume or LUN gets its own Smart Retention policy where you specify the maximum age in days. Pair that with a scheduled snapshot rule and QTS will automatically retire snapshots as they cross the ninety-day mark. If you back up to an external drive or a remote NAS, the same rule propagates, provided both ends run matching firmware and have the Retention layer enabled in License Manager for replication features.

Using snapshots, versioning, and smart schedules

Snapshots are your safety net when automated deletion goes wrong. A read-only Btrfs or ZFS snapshot taken nightly gives you a point-in-time recovery option independent of your retention script, so even if the deletion rule fires on a Friday afternoon and someone needs last Wednesday's file on Monday morning, the snapshot still has it.

Schedule snapshots to run just before your cleanup window - for most Australian users running jobs overnight, that means triggering a snapshot at 1am AEST and the prune task at 2am. The gap matters because you want the snapshot to be captured before anything gets deleted, otherwise you are pruning the very copy you intended to keep.

If you use Synology Drive or QNAP's similar file sync tools, enable version history with a matching cap. Versioning at ninety days aligns the cloud-style sync experience with the server-side snapshot policy, so users opening a file on their laptop in Canberra see the same recovery horizon as the office in Surfers Paradise.

Writing a custom script when the GUI is not enough

Sometimes the built-in tools don't match your exact needs - perhaps you want to keep monthly archives for seven years while letting daily backups roll off after ninety days, or you need to exclude a specific subfolder from automatic deletion. That's where a small bash script triggered by cron or the Task Scheduler gives you the flexibility the GUI lacks.

A typical script uses find with -mtime +90 to identify files older than the threshold and -delete to remove them, with a dry-run flag for testing. Log the output to a separate text file so you can audit what was actually removed. On DSM, save the script in a dedicated folder, then point Control Panel → Task Scheduler at it with a daily run time.

When building documentation around your NAS automation, drawing on broader references about scheduled maintenance can sharpen your approach. Resources such as this trustmashoil.kz reference occasionally surface patterns that translate surprisingly well to data retention tasks. The point isn't the source itself; it's the discipline of writing down every step so the next person inheriting your NAS setup understands why the rule exists.

Always wrap destructive commands in a confirmation check. Something as simple as verifying the target directory matches an expected path before running -delete can prevent a typo from wiping the wrong folder. Pair the script with a notification rule - email or push notification through Synology Chat or QNAP Notification Center - so you know each run actually completed.

Testing and auditing your deletion policy

Never trust an automated deletion script on production data until you've watched it run on a test volume. Create a temporary share, drop in a handful of files with manipulated timestamps, and let the rule execute. Confirm that exactly the files you expected disappeared and nothing else. Run this test on a non-critical weekend when you're available to intervene, and keep the test share intact for a few weeks so you can rerun after firmware updates.

Audit logs deserve their own routine. DSM's Log Center and QTS's System Logs both record retention events, but the entries are easy to miss in a busy feed. Set up a monthly task that exports the relevant log section to a separate drive or cloud bucket, and review it for unexpected gaps. A policy that silently stopped running two months ago is worse than no policy at all, because it gives you false confidence during an actual recovery.

Finally, document the rule in plain English somewhere accessible - a pinned note in your team chat, a printed page near the NAS, a paragraph in your business continuity plan. When the next person needs to know why backups from April disappeared, they should be able to find the answer without reverse-engineering a cron job at midnight.

Take fifteen minutes this weekend to map your backup folders, set the ninety-day retention policy on each task, and trigger a test run before relying on it. Your future self, knee-deep in a recovery scenario during a Melbourne heatwave, will thank you for the discipline.