Repair fails, database recreate takes a ridiculously long time

Not to justify any issue in repair or recreate, and I know you want to keep your old file versions, but you don’t need database recreation to restore files should you suffer a hard drive crash. Restoring files from a backup gets into this lightly, and Disaster Recovery gets technical, including Restoring files using the Recovery Tool. Backing up the configuration is important because it’s kept locally and a broken disk could take it out as well.

How to test / verify your backups is good occasional practice, and a confidence booster (could be download hungry though), and one can also raise –backup-test-samples on automatic verification done after backups. One thing about both of these is that they focus more on how everything looked recently (including old files). The TEST command does have an option to verify old backup views, but I think you have to ask one-by-one. Sometimes I wonder if recreate trips over old errors. I’m not sure if The REPAIR command takes the –version option, but it might. Newest is probably 0, and I think ranges are accepted. If it works, it should also be faster.

The general topic of repair does not work (or not always, or something) was recently proposed as top priority, so possibly canary will see some more work on improvements (and at some point those will flow into the beta).

For the current slow situation, you might get some insight from About → Show log → Live (adjustable level), however it would probably be more to see what sort of activity is happening than to obtain a detailed analysis.