Backup Cleanup: can this happen automatically?

[RogerSik]

I dont often visit Plexcache and see that

Redundant: Original already restored to array - backup can be safely deleted.

I thought when moving from SSD to HDD it would be more clever to name the .plexcached back to normal name and delete the ssd file. So there is no need to copy the file back.

Can this be done? Or at least a setting to say if revert was successfully delete backup automatically?

[Brandon-Haney]

Good question, and the first part is actually already how it works. When a file goes back to the array, PlexCache doesn't copy it. It renames the .plexcached backup back to its original name and then deletes the SSD copy, so no bytes move. That's the case for the scheduled run, the CLI eviction, and the Evict button in the web UI. The only time it copies is when there's no backup to rename, or when the cached file is a different version than the backup (say Sonarr upgraded it while it was on cache), in which case the old backup gets deleted and the newer file is copied over.

That's also why the "Redundant" entries are a bit of a puzzle. Every internal restore path removes the backup in the same step that puts the original back, so PlexCache's own flow shouldn't leave both sitting on the array. What usually produces that state is something else restoring the file: the Unraid mover moving the cache copy back because the exclude list wasn't being honored, the data/ folder or exclude file getting reset so the mover no longer skipped those files, or leftovers from an older version that had some rename bugs in that area.

A couple of things that would help narrow it down:

• Is CA Mover Tuning pointed at plexcache_cached_files.txt, and if the cache path in your docker mapping differs from the host path, is host_cache_path set? The Unraid setup guide has a note about this.
• If you clean them up now, does the count come back over the next few days, or was this a one-time batch?

On the setting itself, I think that's a reasonable ask. The audit already does one automatic action on a schedule (the upgrade transfer, gated by auto_transfer_upgrades), so an opt-in "delete redundant backups automatically" toggle would fit the same pattern. It would only touch the redundant type, where the original is confirmed on the array, and never the orphaned ones since those are the only copy of the file. I'd lean toward having it off by default given it deletes things on a timer, but happy to put a PR together if that sounds right to you.

[RogerSik]

That's also why the "Redundant" entries are a bit of a puzzle. Every internal restore path removes the backup in the same step that puts the original back, so PlexCache's own flow shouldn't leave both sitting on the array. What usually produces that state is something else restoring the file: the Unraid mover moving the cache copy back because the exclude list wasn't being honored, the data/ folder or exclude file getting reset so the mover no longer skipped those files, or leftovers from an older version that had some rename bugs in that area.

Ah I think this is the issue. I moved plexcache to another directory, which also moved the exclude file and I forgot to update in Mover Tune to the new exlucer file path. So every 2 am mover moved to HDD and at 4 am plexcache moved back to Cache and I did'nt noticed it because it worked 😆

I fixed the path now and will report in 2-3 days if this issue is still open.

[RogerSik]

Yes this was the issue.