I didn’t read the other thread, but I can certainly relate. I assume you had some entity or entities spamming the database with frequent state changes or some such. Not all that uncommon, unfortunately. Ideally, each new entity should be reviewed for its impact on the database when it’s added, and excluded if you don’t need to keep all the state changes for whatever your keep_days duration is. Unfortunately the UI doesn’t make this easy.
In this case it sounds like your best hope is manually inspecting the database and using SQL to delete the offending records, while leaving the ones you want to keep. Not a simple process, even for those with database administration experience.
I personally think it was a mistake to add “energy” data to the existing Recorder database. Good design practices would suggest keeping archival and short-term data separate, at a minimum. Retention periods should also be more flexible than one keep_days parameter for all entities. But none of that is within my control, so we just have to work within the limitations we’re given.
Yes - there was something weird and newish happening that was increasing the data base size by anything up to a 100MB in a few hours overnight. I had no idea what was going on but wondered if it was a glitch/update/config change so tried rolling back a few days to see if the increase still happened. It didn’t happen last night - db size has been steady ever since the restore - I’m hoping that in due course purge will get rid of whatever ‘rubbish’ has been added and my usual 100MB db size will be restored. If it isn’t then no doubt I’ll be back
Have to say I agree. Nice to know I can get the long term data back if I’m on the ball but in my opinion system should provide an option to preserve the long term data when restoring.
