cPanel backup error

[glmanager]

Hi guys,

Could you please help me to identify what this error is related to.
I mean I understand it is in general related to backup what exactly generates this error.
Thanks in advance.

The backup process on “cpanel3.company.com” encountered an error.

The system started a separate transport process for remote backup destinations. When the transport completes, the system will send an additional notification with the status of the transport if any errors were encountered.


The backup process encountered the following errors:

---

STDERR: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184

Cpanel::Exception::ProcessFailed::Error/(XID ef7k9n) “/usr/bin/mysqldump” reported error code “3” when it ended: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184

STDERR: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184

Cpanel::Exception::ProcessFailed::Error/(XID nyc7r8) “/usr/bin/mysqldump” reported error code “3” when it ended: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184

[2022-07-14 04:54:24 +1000] Failed after 3 times; last error: STDERR: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184

[2022-07-14 04:54:24 +1000] Cpanel::Exception::ProcessFailed::Error/(XID 9k86mk) “/usr/bin/mysqldump” reported error code “3” when it ended: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184

Review the attached log “/usr/local/cpanel/logs/cpbackup/1657728003.log” for further details.

---
[2022-07-14 20:23:58 +1000] homefiles is: 8010
[2022-07-14 20:23:58 +1000]
[2022-07-14 20:23:58 +1000] mysqlsize is: 46911488
[2022-07-14 20:23:58 +1000] pkgacct completed
[2022-07-14 20:23:59 +1000] info [backup] Successfully backed up account “techni” to “/mnt/backup/2022-07-14/accounts”
[2022-07-14 20:23:59 +1000] info [backup] Adding metadata information for techni to backup at /mnt/backup/2022-07-14
[2022-07-14 20:39:53 +1000] info [backup] Queuing daily backup copy of “techni” for transport of “/mnt/backup/2022-07-14/accounts/techni.tar.gz” to “2022-07-14/accounts/techni.tar.gz”
[2022-07-14 20:39:53 +1000] info [backup] This particular transport will be queued with keep_local = 1 , based on the need to copy weekly () and/or monthly () copies as well.
[2022-07-14 20:54:48 +1000] info [backup] Queuing transport of file: /mnt/backup/2022-07-14/accounts/techni.tar.gz
[2022-07-14 20:54:48 +1000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:78063
[2022-07-14 20:54:49 +1000] info [backup] leaving queue_backup_transport_item
[2022-07-14 20:54:49 +1000] info [backup] Queuing transport of meta file: /mnt/backup/2022-07-14/accounts/.master.meta
[2022-07-14 20:54:49 +1000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:78064
[2022-07-14 20:54:49 +1000] info [backup] leaving queue_backup_transport_item
[2022-07-14 20:54:49 +1000] info [backup] Queuing transport of file: /mnt/backup/2022-07-14/backup_incomplete
[2022-07-14 20:54:49 +1000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:78065
[2022-07-14 20:54:50 +1000] info [backup] leaving queue_backup_transport_item
[2022-07-14 20:54:50 +1000] warn [backup] Pruning of backup files skipped due to errors. at /usr/local/cpanel/bin/backup line 395.
bin::backup::run("bin::backup") called at /usr/local/cpanel/bin/backup line 120
[2022-07-14 20:55:56 +1000] info [backup] Scheduling backup metadata vacuum
[2022-07-14 20:55:58 +1000] info [backup] Queuing transport reporter
[2022-07-14 20:55:58 +1000] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:78066
[2022-07-14 20:55:58 +1000] info [backup] leaving queue_backup_transport_item
[2022-07-14 20:55:58 +1000] info [backup] Completed at Thu Jul 14 20:55:58 2022
[2022-07-14 20:55:58 +1000] info [backup] Final state is Backup::PartialFailure (0)

Start Time: Wednesday, July 13, 2022 at 4:00:03 PM UTC

End Time: Thursday, July 14, 2022 at 10:55:58 AM UTC

Run Time: 18 hours, 55 minutes, and 55 seconds

This notice is the result of a request from “cPanel Backup System”.

The system generated this notice on Thursday, July 14, 2022 at 10:55:58 AM UTC.

“Backup Finished With Partial Failure” notifications are currently configured to have an importance of “Medium”. You can change the importance or disable this type of notification in WHM’s Contact Manager at:https://cpanel3.company.com:2087/scripts2/editcontact?event=Backup::PartialFailure
Do not reply to this automated message.

 

[quietFinn]

What exactly generates that error is this:
"STDERR: mysqldump: Error 1194: Table 'wp_wflogins' is marked as crashed and should be repaired when dumping table `wp_wflogins` at row: 41184"

 

[andrew.n]

As @quietFinn pointed out some of your tables are corrupted hence cpbackup throw this error. You need to repair the database which hopefully fix the corruption. I would run this globally for all databases just to be sure there are no other corruption. You can do so with:

mysqlcheck -rA and mysqlcheck -oA commands (first will repair them, the other one will optimize them)

 

[glmanager]

Hi @quietFinn and @andrew.n

I run mysqlcheck -rA command but for some website I'm getting:
"The storage engine for the table doesn't support repair"
Anything else I should try?

 

[andrew.n]

@glrmanager this is what "mysqlcheck -oA" for. You need to optimize those dbs rather than repair

 

[glmanager]

Hi @andrew.n,

I run mysqlcheck -oA and for some sites getting this.



Can I ask what does that mean.
I mean I understand some tables do not support optimization and instead are recreated.
Just curious what happens during recreation and does it fix the original problem.

 

[andrew.n]

@glmanager: technically speaking this:

MySQL :: MySQL 5.7 Reference Manual :: 13.7.2.4 OPTIMIZE TABLE Statement

dev.mysql.com

more understandably this:

What does "Table does not support optimize, doing recreate + analyze instead" mean?

I am working on MySQL 5.5 and trying to do index rebuild using an OPTIMIZE TABLE query. I am getting the error below: Table does not support optimize, doing recreate + analyze instead What does...

stackoverflow.com

"InnoDB doesn't support the OPTIMIZE the way MyISAM does. It does something different. It creates an empty table, and copies all of the rows from the existing table into it, and essentially deletes the old table and renames the new table, and then runs an ANALYZE to gather statistics. That's the closest that InnoDB can get to doing an OPTIMIZE."

 

[cPRex]

Any databases using InnoDB tables likely can't be repaired or optimized. If you have an older backup, you can try restoring from that to get the site and database into a working state.