A (relatively) recent update to v2.1.1.0_experimental_2025-07-17 brought a lot of great updates including improved error detection, which caused some issues for my long-running backups ( Release: 2.1.1.0 (Experimental) 2025-07-17 - #8 by JonMikelV ).
After years of no issues (thanks!) both my primary & secondary backups on the same file set started throwing “volumes with missing filesets” errors. My attempts to fix it resulted in some “compressed using an unsupported compression method” errors which a Database Repair resolved on one of the backups, but not the other one.
The remaining failing job dies with “volumes with missing filesets” on backups and “Failed to load compression module” on repairs - and I suspect I know why.
This is my oldest backups set which I believe I originally created (years ago) with 7z compression, then read how that was not recommended so changed it to zip - but only AFTER some backups had happened with 7z, from which I still have 25 .dlist.7z.aes files.
I haven’t read through all of the related code at duplicati/Duplicati/Library/Main/Operation/RepairHandler.cs at master · duplicati/duplicati · GitHub but I’m wondering if it isn’t (or is no longer) designed to handle multiple compression methods thus resulting in “repairing” all 547 .dlist.zip.aes files then simply “not seeing” the 7z-based ones. 
Does anybody have any thoughts on how to recover (or at least if my single-compress-method theory is correct)?
Thanks in advance. 