The environment currently uses a layered backup model rather than a single tool doing everything.
- Primary tool: Unraid Appdata Backup plugin
- Source:
/mnt/user/appdata/
- Destination:
/mnt/backups/Backup/Appdata Backup/
- Schedule: weekly, Monday at 00:00
- Verification: enabled
- Retention: delete after 14 days, keep at least 4 backups
- Extras included: flash backup, VM metadata
- Tool: Duplicacy
- Source: Appdata Backup plugin output at
/mnt/backups/Backup/Appdata Backup/
- Destination: Backblaze B2 bucket Altair-Appdata-Backup
- Cadence: weekly, aligned with the plugin backup set
- Reasoning: Duplicacy is backing up the plugin's backup set, not live appdata directly.
- Tool: Duplicacy
- Primary source:
/arraydrives/Images inside the Duplicacy container
- Local storage:
/backupdrive/Backup/Immich Backup
- Offsite storage: Backblaze B2 bucket Altair-Photo-Backup
- Cadence: daily
The Appdata Backup plugin intentionally skips the Immich stack and subgen:
immich_serverimmich_machine_learningimmich_postgresimmich_redissubgen
That means Immich/photo protection depends on Duplicacy, not the Appdata Backup plugin.
Duplicacy prune policy is:
-a -keep 0:180 -keep 30:30 -keep 7:7
Practical meaning:
- keep all snapshots for 180 days
- then keep one every 30 days
- also keep one every 7 days in the recent retention window
Duplicacy schedules also include check jobs in addition to backup and prune.
live appdata
→ Appdata Backup plugin
→ /mnt/backups/Backup/Appdata Backup/
→ Duplicacy
→ B2 (Altair-Appdata-Backup)
live photo data
→ Duplicacy local storage
→ /backupdrive/Backup/Immich Backup
→ Duplicacy offsite copy
→ B2 (Altair-Photo-Backup)
- Appdata Backup plugin is healthy and scheduled weekly.
- Latest observed local appdata backup set: ab_20260316_000004
- Duplicacy backup plan was rebuilt cleanly in March 2026.
- Wiki/documentation should reference the rebuilt path model, not the old
/backuproot path history.
- If Duplicacy drifts, photo coverage is the first thing to audit.
- Appdata is safer locally because the plugin handles local backup/versioning before Duplicacy touches offsite.
- Any future restore runbook should clearly separate:
- plugin-based appdata restore
- Duplicacy-based photo restore
- Database backups absent: Immich (PostgreSQL) and potentially Nextcloud (MariaDB/PostgreSQL) have no database dump schedules. The backup chain covers files but not the databases that make those files useful.
- Proxmox LXC backups: The 4 Proxmox LXCs (wikijs, homebridge, nginxproxymanager, gitea) have no backup path at all. If Edward disk fails, they are gone.
- Appdata plugin exclusions: Confirm the full exclusion list. Immich and subgen are known exclusions — are there others that should be covered?
- Backup verification: Has anyone actually tested restoring from any of these backups? The documentation says verification is enabled on the plugin, but a test restore is different from a verification check.
- Duplicacy B2 credentials rotation: Confirm Backblaze app key age and whether rotation is needed.
- Cross-host backup: Altair and Edward are independent. There is no cross-host backup between them. If one host is lost, only its own backups can recover it.
- Offsite 3-2-1 compliance: Current model has 2 copies (local + B2). Consider whether a third copy (second offsite or offline) is warranted for critical data like Vaultwarden.
- Backup monitoring/alerting: No automated alert if a backup job fails. Consider n8n or Ntfy integration to alert on Duplicacy or Appdata Backup failures.