The document discusses recovering a corrupted ZODB database without backups by using a script found online that analyzes the database and recovers usable data by deleting corrupted objects. It was able to recover the entire ZODB from a hardware failure, deleting 1.7GB of corrupted data with no remaining broken objects. An alternative method discussed is commit rebasing, which uses a past known good backup and appends subsequent transactions to restore the database.

1. “We fixed it ourselves”
Re-fixing a corrupted ZODB
@MatthewWilkes

2. “We had a
hardware failure
back in April”

3. “We tried fsrecover -p”

4. “We found this
script online”

5. “This script online”
http://www.derstappen-it.de/tech-blog/zodb-repair
“Some times you have a broken ZODB database because of
hard disk problems and sadly no suitable backup exist.“
“[We can] see what data is [...] can be saved.”

6. “It recovered the
ZODB, and it
deleted 1.7GB”

7. “We need to
delete the
remaining broken
objects”

8. “Yes, we had a
backup, but
there’s new
content now”

9. Commit rebasing
● Script takes two ZODBs
● One known good from some point in the past
● One known bad that has transactions to keep
● If fsrecover.py doesn’t work, this might
● Appends subsequent transactions to the known good, rewriting headers
● About 30 megabytes per second
● Only better than fsrecover if all corruption is in redundant section

10. Recovered with 0
broken or missing
objects

11. git.io/fpTI6