Corrupt Database: database disk image is malformed

Plex Media Server Desktops & Laptops
1

Server Version#: 1.41.7.9823
Player Version#: Plex Web 4.146.0
OS: Ubuntu 24.04.2

Apparently my Plex server has been failing to backup for months and I didn’t know. Turns out its because my database is corrupt, likely due to some system lockup/kernel panic type crashes on my OS where I have to hard-power-off the system to get it back online. I have tried running through the official Repair a Corrupted Database | Plex Support guide, but whenever I run the PRAGMA integrity_check; command, it errors with the “Database disk image is malformed” error, and VACUUM; and REINDEX; don’t seem to have any effect either.

I’ve also tried the low-level recovery option, but the resulting db-recover.sqlite file winds up being about 85GB, and when reimported into a new DB file, the new DB is 16GB in size when the original DB file was 7GB, and EVEN THEN, if I run a PRAGMA integrity_check; on the NEW database file, I still get a Database disk image is malformed error.

I’ve also tried @ChuckPa’s DBRepair.sh script, and even that isn’t working properly either and errors with the following:

Automatic Check,Repair,Index started.

Checking the PMS databases
Check complete.  PMS main database is damaged.
Check complete.  PMS blobs database is OK.

Exporting current databases using timestamp: 2025-05-26_00.43.18
Exporting Main DB
Exporting Blobs DB
Successfully exported the main and blobs databases.
Start importing into new databases.
Importing Main DB.
Parse error near line 21470035: near "MNTO": syntax error
  INSERT MNTO statistics_bandwidth VALUES(27672728,NULL,1345,1,1746075600,0,6553
         ^--- error here
Parse error near line 21470041: no such table: statistics_bandsidth
Runtime error near line 55932556: UNIQUE constraint failed: statistics_bandwidth.id (19)
Runtime error near line 55932621: UNIQUE constraint failed: statistics_bandwidth.id (19)
Parse error near line 63503718: no such column: NULD
  INSERT INTO statistics_bandwidth VALUES(79812472,NULD,1345,1,1746075600,0,822)
                                     error here ---^
Error 1 from Plex SQLite while importing from './dbtmp/library.plexapp.sql-2025-05-26_00.43.18'
Cannot continue.
Repair failed. Automatic mode cannot continue. Please repair with individual commands

Anyone have any thoughts or ideas? I’d like to get this actually repaired so that Plex backups are working properly without having to completely rebuild my server, or rely on dirty snapshot type backups from something like Veeam.

2

About to go offline for the night but will look in the morning.

I think it can be corrected with Linux command line editing and manual DB reconstruction.

I’m concerned that the exported schema is corrupt. This implies greater damage to the DB than usually found. This is making me suspect of a storage system failure as well. There’s something else wrong.

NOTE: You can also try to turn on the IGNORE option. It may spit errors but will continue.

Check the computer (Memory and storage)

[chuck@lizum ~.2005]$ echo NULL NULD | od -bc
0000000 116 125 114 114 040 116 125 114 104 012
          N   U   L   L       N   U   L   D  \n
0000012
[chuck@lizum ~.2006]$ echo INTO MNTO | od -bc
0000000 111 116 124 117 040 115 116 124 117 012
          I   N   T   O       M   N   T   O  \n
0000012
[chuck@lizum ~.2007]$
5

The result from my system looks same.

root@sblplex01:~ $ echo NULL NULD | od -bc
0000000 116 125 114 114 040 116 125 114 104 012
          N   U   L   L       N   U   L   D  \n
0000012
root@sblplex01:~ $ echo INTO MNTO | od -bc
0000000 111 116 124 117 040 115 116 124 117 012
          I   N   T   O       M   N   T   O  \n
0000012
root@sblplex01:~ $

I’m currently in process of running smartctl -t long /dev/nvme0 to do a SMART Self-Test on the NVMe drive. The short test came back okay and the drive doesn’t show any other errors. Still need to run a memtest86.

All this said, I think I may have corrected it altogether: I did an export of the database using DB Browser for SQLite GUI and choosing to export every table except for the statistics_bandwidth table. That seems to be where everything was breaking down. After I exported the tables, I created a new database and imported the SQL output using the Plex SQLite server (because importing in DB Browser had issues), then I manually recreated the statistics_bandwidth table and indexes using the info I found in the thread about the PM-3483 account_id excessive logging bug here.

That new DB is now back to the rough size of where it was back in December when the last successful backup happened (around 280MB), and my Plex server seems to be running just fine with it and has all the correct media, user, and history information, from what I can tell, and a PRAGMA integrity_check; comes back OK on the new database file.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.