Ignite Global Support Home Start a conversation Sign in
Start a conversation
  1. Northplains Xinet Support
  2. Articles
  3. Public Articles

Venture Backups Fail with mysqldump Errors on Xinet Server v2025.5.16 (Fixed in v2026.02.27)

Overview

On Xinet Server v2025.5.16, Venture built-in database backups (db_quickbackup/db_fullbackup) can fail with mysqldump-related errors during GUI-initiated and scheduled backups. This was confirmed as a product defect in how the built-in Venture backup flow constructs/invokes mysqldump, and it is resolved by upgrading to Xinet Server v2026.02.27.

Solution

Symptoms / Errors

Review venture.log around the backup time. Common error patterns include:

Quick backup

db_quickbackup: Error (-2) running quick mysqldump!
db_quickbackup: Backup failed err(-5)
dblogd: Error! Quick backup failed! err=[-5]

Full backup (may show errors but later log a misleading “success” line)

db_runmysqldump: mysqldump encountered an error! [2]. (May need to run dbmgr -updatetablesXX.)
db_fullbackup: Error (-2) running <database_name> mysqldump!
...
db_fullbackup: Backup Succeeded in <backup_path>!

Affected / Fixed Versions

  • Affected: Xinet Server v2025.5.16 (confirmed)
  • Fixed in: Xinet Server v2026.02.27
  • Portal: No separate Xinet Portal release is required for this fix (Portal unchanged since v2025.12.19).

What Was Happening (High-Level Cause)

Two behaviors were observed in affected environments:

  1. Manual mysqldump can fail due to MySQL configuration options that are not supported by the installed mysqldump, for example:

    mysqldump: [ERROR] unknown variable 'binary-as-hex=0'.

  2. Even after manual mysqldump succeeds, the built-in Venture backup (GUI/scheduled) may still fail, which indicates a product defect specific to Xinet Server v2025.5.16 in how mysqldump is invoked for db_fullbackup/db_quickbackup.

How to Confirm You Are in the Same Scenario

1) Confirm the errors in venture.log

  • Look for: Error (-2) running quick mysqldump!
  • Look for: mysqldump encountered an error! [2]
  • Look for: Backup failed err(-5) and/or dblogd: Error! Quick backup failed! err=[-5]
  • For full backups, note if the log reports Backup Succeeded ... even though mysqldump errors occurred earlier (this misleading pattern was observed).

2) Confirm Venture table version and schema status

Check the Venture tables version reported by dbmgr and verify whether table updates are actually needed.

  • In the investigated case, the Venture tables version reported by dbmgr was 23.
  • Running /usr/etc/venture/bin/dbmgr -D -updatetables25 returned:
Error: Unknown table version!

If you see “Unknown table version,” it indicates the requested -updatetablesXX does not match a valid/available table version in your environment. In the investigated case, tables were confirmed as not being the immediate cause (table update checks reported “Tables up to date.”).

3) Validate whether MySQL config is breaking mysqldump (manual test)

If manual dumps fail with an unsupported option error, review your MySQL configuration used by Venture, for example:

/usr/etc/venture/var/my.cnf

If present, commenting out the following option was confirmed to allow manual mysqldump to succeed in the investigated environment:

binary-as-hex=0

Another manual-dump failure that was observed was an authentication error logged to /tmp/backup.log:

mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: NO) when trying to connect

4) Important: Manual mysqldump success does not guarantee built-in backup success on v2025.5.16

In the investigated case, even after manual mysqldump succeeded, the built-in (GUI) quick backup still failed. This aligns with the confirmed product defect in Xinet Server v2025.5.16.

Permanent Fix

The permanent fix is to upgrade Xinet Server to v2026.02.27, which includes development changes to improve mysqldump invocation and Venture backup behavior. After upgrading to v2026.02.27, the issue was confirmed resolved (“This seems to be rectified.”).

Internal Tracking (Reference)

This issue was escalated and tracked internally as a core functionality defect (for example: <internal_tracker_id>).

Frequently Asked Questions

1. Which versions are affected, and which version contains the fix?

Xinet Server v2025.5.16 is confirmed affected. The fix is delivered in Xinet Server v2026.02.27.

2. Why does venture.log sometimes say “Backup Succeeded” even when errors appear earlier?

This pattern was observed during investigation: full backups can log mysqldump errors (for example, Error (-2) running <database_name> mysqldump!) and later still log a success message. Treat earlier mysqldump errors as an indicator the backup did not complete cleanly, even if a later “succeeded” line appears.

3. If I comment out binary-as-hex=0 and manual mysqldump works, is the issue solved?

Not necessarily. Commenting out binary-as-hex=0 was confirmed to help manual mysqldump succeed when that option is unsupported. However, the built-in Venture backup workflow can still fail on v2025.5.16 due to a product defect. Upgrading to v2026.02.27 is the permanent fix.

4. Do I need to upgrade Xinet Portal separately for this fix?

No. No separate Portal release is required for this fix; Portal had no changes since v2025.12.19 for this issue.

5. What does “Error: Unknown table version!” mean when running dbmgr -updatetablesXX?

It indicates the specific -updatetablesXX value you supplied is not recognized/available in your environment. In the investigated case, dbmgr reported Venture tables version 23, and attempting -updatetables25 returned “Unknown table version.” Tables were also verified as “up to date,” so schema updates were not the immediate cause of the backup failures.

Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted

Comments