Backup path layout changes don't migrate existing local archives (orphaned backups refill disk)

[JimmyMcAttaboy]

Summary

The local backup storage layout has changed twice in recent releases, and neither change migrates existing archives. After each update, backups created before the update sit at the old path. Deletes and rotation from the panel no longer find them, so they are never cleaned up and quietly refill the backup volume. The symptom is new backups failing with no space left on device, which is easy to miss because the panel just shows failed backups.

What we observed (local adapter, Wings in Docker)

1. beta26 → beta27 (Aug 2026): backups moved from per-server subdirectories to flat files in backup_directory (<backup_dir>/<backup_uuid>.tar.gz). The existing per-server subdirectories were left in place. Panel rotation only acted on the new flat path, so ~52 GB of pre-update archives were orphaned. Within about 24 hours the volume filled, and every scheduled backup on the node failed with no space left on device until we found and deleted the old directories by hand.
2. beta27/28 → beta29 (Sep 2026): after fix(backups): Every server has its own backup dir #202 ("Every server has its own backup dir"), the path became <backup_dir>/<server_uuid>/<backup_uuid>.tar.gz. Existing flat archives weren't moved. This time we caught it beforehand from the release notes and migrated manually: we mapped each backups.uuid → servers.uuid from the panel database, then moved each archive into its server directory. After the move, a scheduled backup landed in the new directory and rotation correctly deleted the oldest moved archive, so a one-time move is enough.

Expected

Either:

• On startup, Wings detects archives at the legacy path(s) and moves them to the current layout (Wings knows the server UUID for each backup it handles, or can resolve it the way fix(backups): Every server has its own backup dir #202 constructs paths), or
• A read/delete fallback to the legacy location (as suggested in the review on fix(backups): Every server has its own backup dir #202), and/or
• A prominent release-note callout with manual migration steps whenever the backup path format changes.

Environment

• Wings: Docker Compose deployment, local backup adapter
• Versions: beta26 → beta27 (first change), beta27 → beta29 (second change, fix(backups): Every server has its own backup dir #202)
• Panel: beta36 → beta38 at the time of the second change