Database corrupted - lost 2 weeks of data. Any chance at recovery?

[paul19920801]

Hi all.

Due to the size of my Teldrive account - I have a script that automatically backs up the database, but I later found out that due to a change I made at the time of failure it hadn't backed up for 2 weeks.

This is in part my own fault, and I really should have checked backups before hand, before just making changes

Not really the end of the world as I uploaded very minimal info, and I am happier having lost 2 weeks worth of files vs 2 years worth.

I had issues with Teldrive giving errors, and AI advised me to delete a database entry, which I did - it corrupted my entire database table - and which each "correction" from AI - it just made things worse - and the end result was restoring a backup.

Obviously the files are all still there in Telegram - it's just the database reference to them is not there as this was done after the last backup.

Is it possible to repopulate Teldrive with the missing entry, or am I just clutching at straws here.

Thanks in advance

[iwconfig]

Sorry to hear that. Unfortunately, any files that's greater than your chunk size setting will be split and teldrive needs to know all the message IDs to be able to stitch together the file again.

But for anything unencrypted <= chunk size you can use something like https://github.com/iwconfig/telegram2teldrive (i'm unsure about the teldrive latest version though, as it has introduced an additional column for hashes to the files table, but it's a simple fix)

if you have the "randomize filenames" setting on, while it will work, it will probably be a nightmare to handle unless you have a record of them somewhere, but i assume you don't.

come to think of it, it might be possible to import encrypted files also, or perhaps with some tweaking of telegram2teldrive code it would work (i don't remember), but still, you'd probably end up with the same issue as with the randomized filenames anyway.

in theory as long as you have not shutdown your postgresql instance since you made the mess, you could maybe recover with features within postgresql, but it's difficult and really depends on a lot of factors. i don't know enough to help you with this, but if you'd like to take a stab at it (since your database is broken anyway) you can explain the situation thoroughly to an LLM and include a question on how to restore the lost data within a live postgresql instance without using a dumped db/backup. however, i assume you've already shutdown and/or altered the database by this point. and again, it's complicated and it relies on the WAL which means you're probably doomed as soon as you alter the database in any way. you can also try recovering dead tuples (MVCC), but as i said, i don't know enough and it's complicated.