Implementing a secure backup strategy for your NAS

Initial considerations for a secure backup strategy

I run a UGREEN DH2300 as my primary NAS in my home lab. I treat it like a live system, not a toy, so the backup routine has to work properly when things go wrong. This is the practical version: what I changed, what I got wrong, and what held up.

Start by deciding what needs protecting. I split data into three classes: critical, important but replaceable, and ephemeral. Financial records and personal documents go in the first group. Photos and media sit in the second. Downloads and temp builds go in the third. That split drives the rest.

Check how much data you have and how quickly it grows. I measured growth over three months on the DH2300 and used that to judge whether nightly or hourly backups made sense. If you add less than 1 GB per day, nightly incremental backups will usually do. If you add tens of gigabytes daily, more frequent snapshots or block-level replication starts to make sense.

I use a hybrid setup:

• Incremental forever snapshots for quick restores and lower transfer cost.
• Weekly full snapshots for a clean restore point.
• Monthly archival copies kept offsite for disaster recovery.

For irreplaceable data, I run hourly snapshots during work hours and a daily repo sync overnight. For media and archives, daily or weekly jobs are enough.

Storage is split across tiers. The DH2300 holds the primary set. I keep a local backup on a second NAS or a RAID array for fast restores. After that I keep an offsite copy, either in an encrypted cloud bucket or on a physical drive rotated to another location. For long-term retention I use cheap cold storage or an encrypted USB SSD kept offsite.

The backup method should match the data. For file shares I prefer file-based snapshots from the NAS OS or rsync with hard-link rotation. For VM images or databases I use application-aware tools, such as database dumps or filesystem snapshots before transfer. For large binary stores I use block-level tools where I can, since they move less data.

Security matters as much as retention. Backup destinations get strong passwords and keys, and the DH2300 uses SSH keys plus an account with limited permissions. Anything that leaves my local network gets encrypted. Backup credentials are separate from day-to-day access.

I set retention before anything else. Keep enough history to recover from a bad week, not just the last convenient restore point. My current retention looks like this:

• Hourly snapshots, last 48 hours.
• Daily snapshots, last 30 days.
• Weekly snapshots, last 6 months.
• Monthly archives, last 2 years.

That uses space. It should. I budget for it and use compression and deduplication where I can.

Implementing your secure backup strategy

Automate it. Manual backups fail at the first awkward evening. On the DH2300 I schedule jobs inside the NAS for snapshots and use cron on a small self-hosted VM to push archives offsite. If you prefer GUI tools, the NAS vendor tools usually work fine as long as they give you scripting hooks for validation.

The setup I actually use is simple enough:

1. Configure local snapshots on the NAS for quick rollbacks.
2. Create an rsync job to a second NAS for daily incremental syncs.
3. Run Borg or restic to push deduplicated, encrypted backup archives to a cloud bucket overnight.
4. Rotate a physical drive weekly and store it offsite monthly.

Set a job up, test it, and break a test file on purpose.

1. Create a test folder with representative files.
2. Run the backup job manually and check that it completes cleanly.
3. Modify or delete a test file.
4. Run the job again and confirm the change is captured.
5. Put the schedule under cron or the NAS scheduler.

Restore tests matter more than green ticks in a dashboard. A backup job that runs is not much use if the data will not come back. I do monthly restores for random files and quarterly full restores. The checks include:

• Restoring a single file and checking its checksum.
• Restoring a home directory and checking for permission issues.
• Restoring a full image to a disposable VM to validate bootable backups.

Monitoring is basic on purpose. I want email on job failure and a daily summary with job runtime and transfer size. On the DH2300 I also watch SMART stats and set thresholds for disk health. I spot-check repository size against expectations and look for odd growth, which can point to corruption or ransomware.

Different data types need different handling. Databases need consistent dumps. For PostgreSQL I use pg_dump or base backups with WAL shipping. For container data, pause or snapshot containers before backup where possible. For large media, rsync with partial transfers and throttling keeps the network from getting flattened.

Keep a recovery playbook. Write step-by-step restore procedures for the common cases: single file, mailbox, VM, and full-site recovery. Store those playbooks with the backups and test them during drills.

Review the setup every six months, or after a change that matters: new services, larger data volumes, or a firmware upgrade on the DH2300. When something changes, run the integrity tests again.

Practical points from the DH2300 setup:

• Use encryption for offsite copies, even if the cloud provider looks trustworthy.
• Use deduplication tools for repositories with lots of similar files; they save space.
• Keep at least one offline copy on removable media for ransomware recovery.
• Log everything, including successful backups. Logs are often the first clue that something has gone wrong.

Before I trust the setup, I check three things: automated jobs run and report success for a week, three random files restore from different retention windows, and offsite archives decrypt and mount.

The result is a backup setup that I can actually recover from. It favours recovery over convenience and treats the NAS as one part of a wider layered setup.