Loading...

Backup Troubleshooting - MySQL iDataAgent

Backup Restore  
Table of Contents

MSQL0001: MySQL instance creation fails

Symptom 1

Invalid username and password error is displayed while configuring the MySQL instance. MySQL commands fail with 'GCC_4.2.0' not found (required by /usr/lib64/libstdc++.so.6) error.

Error Code 87:1
Invalid MySQL User Name and Password.

Cause 1

The instance creation fails if the libgcc_s.so.1 library included with the SnapProtect software is not compatible with the newer operating system version that it is installed on.

Resolution 1

Use the following commands to rename /opt/snapprotect/Base/libgcc_s.so.1:

# cd /opt/snapprotect/Base
# mv /opt/snapprotect/Base/libgcc_s.so.1 /opt/SnapProtect/Base/libgcc_s.so.1.old
# snapprotect restart

Create the instance again.

Symptom 2

MySQL instance creation fails when using older MySQL 5.5.x versions or earlier and displays the following error message.

Port wrong error

Cause 2

The instance creation fails because the Mysqladmin utility crashes as the -defaults- file does not have the required .ini or .cnf file extensions.

Resolution 2

Upgrade the MySQL 5.5.x version to the latest available version.

Create the instance again.

Symptom 3

Invalid username and password error is displayed while creating a new MySQL instance.

Error Code 87:1
Invalid MySQL User Name and Password.

MySqlBrowseAgent.log file on the client displays the following error:

Failed to execute mysql_real_connect

Cause 3

The instance creation fails if MySQL server is not alive.

Resolution 3

Follow the steps give below to resolve this issue.

  1. Run the following commands to check if MySQL server is alive or not.

    Windows

    mysqladmin.exe --defaults-file=""--default-character-set=utf8 -u ping --port=<port_number> -p""

    UNIX

    /usr/bin/mysqladmin --defaults-file= --default-character-set=utf8 -u ping --socket="<socket_file>" -p""

  2. If MySQL server is not alive, you will get the following outputs.

    Windows

    mysqladmin.exe: connect to server at 'localhost' failed
    error: 'Can't connect to MySQL server on 'localhost' (10061)'
    Check that mysqld is running on localhost and that the port is 3306.
    You can check this by doing 'telnet localhost 3306'

    UNIX

    /usr/bin/mysqladmin: connect to server at 'localhost' failed
    error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
    Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!

  3. Start the MySQL server, and then create a new MySQL instance.

Symptom 4

MySQL instance creation fails and displays the following error message.

29814 7476 06/13 18:38:48 140737157420800 GetMySqlInfoExt::LastLogName() - LogName: [ mylogs.066080 ] and LogPrefix: [ mylogs ]
29814 7476 06/13 18:38:48 140737157420800 MySqlBrowseAgent::verifyUser() - mysql log files do not exist in the log directory

Cause 4

The instance creation fails if incorrect Log Directory is specified while creating an instance.

Resolution 4

In the My.cnf file, look for the value of log-bin, as shown in the following example:

long_query_time = 10
slow_query_log = 1
slow_query_log_file = /abc/mysql/slow-queries.log
log-bin = /abc/logs/mylogs
binlog-format = ROW # MIXED

In this example, the value for log-bin is "/abc/logs/mylogs".

Hence, while creating an instance, you can specify the following values:

  • Log Directory value - "/abc/logs"
  • Prefix for binary log file - "/mylogs"

Symptom 5

MySQL instance creation fails when using a third party application with customized MySQL binaries.

MySqlBrowseAgent.log file displays an error message similar to the example error mentioned below:

14100 e7399720 08/04 11:47:04 140736142078960 MySqlBrowseAgent::MySqlBrowse() - verifyUser failed err=[/xxxx/mysql/bin/mysqladmin.bin: unknown variable 'defaults-file=/soft/xxxx/Base/Temp/galaxy_bkp_mycnf_1470304024_1470304024'

Cause 5

The instance creation fails because of using a third party application with customized MySQL binaries.

Resolution 5a

Follow the steps give below to resolve this issue.

  1. From the MySQL official website, download the client-side binaries on your computer. For example, you can download the binaries in the folder /opt/mysql-client-dump.
  2. Extract the contents of the binary file using a command similar to the example mentioned below:

    rpm2cpio MySQL-client-community-5.1.73-1.rhel5.x86_64.rpm | cpio –idmv

  3. Change the binary directory of the MySQL server by pointing it to the directory where the new extracted binaries are saved.
  4. Run the native command that initially failed on the client, similar to the example mentioned below:

    /opt/mysql-client-dump/usr/bin/mysql --defaults-file=/XX/my.cnf --default-character-set=utf8 -u root -p xxxx --socket=/xxxx/mysql.sock -e "show variables like 'datadir';" --batch --skip-column-names

  5. Check if the native command fails or not.
    • If the native command does not fail, from the CommCell Console, change the binary directory to the directory where the new extracted binaries are saved, and then create a new instance.
    • If the native command fails, perform the steps mentioned under Resolution 5b.

Resolution 5b

Follow the steps give below to resolve this issue.

  1. Create a new configuration file my.cnf in the folder /opt/mysql-client-dump.
  2. Copy and paste the following information in the my.cnf file:

    [mysqld]
    basedir=/XXX/mysql
    datadir=/XXXXXXX/data
    port=3306
    socket=/XXXXXXXXXX/mysql.sock
    tmpdir=/XXXXX/tmp
    log_bin=ON
    log-bin=/XXXX/mysql-bin.log
    max_binlog_size=536870912
    binlog_format=MIXED

  3. Change the configuration file location of the MySQL server by pointing it to the newly created configuration file.
  4. Run the native command that initially failed on the client, similar to the example mentioned below:

    /opt/mysql-client-dump/usr/bin/mysql --defaults-file=/XX/my.cnf --default-character-set=utf8 -u root -p xxxx --socket=/xxxx/mysql.sock -e "show variables like 'datadir';" --batch --skip-column-names

  5. On successfully passing the native command, from the CommCell Console, change the binary directory and the configuration file location of the MySQL server.
  6. Create a new MySQL instance.

MSQL0003: MySQL backup operation fails with lost connection error

Symptom 1

MySQL backup operation fails and displays the following error message.

Backup fail with: Mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table.

Cause 1

The backup operation fails if the value that is set for max_allowed_packet variable is insufficient to allow the transfer of packets.

Resolution 1

Set the value for the max_allowed_packet variable as 1GB in the MySQL server.

However, you can set a different value for the client by configuring the value for sAdvancedBackupOptions.

The value set on the client is given priority over the one set on MySQL server.

Cause 2

The backup operation fails if the value set for connect_timeout variable is low. The timeout variable refers to the number of seconds that the MySQL server waits for a connect packet before responding with a bad handshake.

Resolution 2

Increase the value for the connect_timeout variable on the MySQL server to 100.

Cause 3

The backup operation fails if the memory size required to dump the BLOB (Binary Large Object) is less. The memory size depends on the RAM usage of the server.

Resolution 3

Increase the memory size.

MSQL0004: MySQL backup operation fails after upgrading the SnapProtect software from version 9 to the current version

Symptom

MySQL backup operation fails with the following error message.

Please use mysql_upgrade to fix this error. (1558)

Cause

After upgrading the software from version 9 to the current version, the backup operation fails due to the addition of "--routines" flag with mysqldump utility. Earlier versions of the software did not support "--routines" flag with mysqldump utility.

The following entries appear in the backup log file:

/opt/install_dir/iDataAgent/jobResults/2/386/pipe711274_18320 out = err = mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db = 'dci_gateway': Column count of mysql.proc is wrong. Expected 20, found 16. Created with MySQL 50152, now running 50169. Please use mysql_upgrade to fix this error. (1558)

Resolution

Run the following command to fix this issue.

mysql_upgrade -uroot -p

MSQL0005: First, full or log-only backup operation fails

Symptom

MySQL backup operation fails with the following error message.

3932 123c 06/28 13:56:17 1085 mysqlLogBackup:ArchiveLogs() - log file(D:\MySQL\MySQL Server 5.6\data\UC-MYSQL-01-bin.000014) is missing, So converting the log backup to full backup

Cause 1

The backup operation fails after changing the instance properties. Same or different directories may be used for data (datadir) and log file (log data directory) generation. This problem occurs when different directories are set, but the user provides the same datadir path for generating log files.

For example,

datadir = D:/MySQL/MySQL Server 5.6/data

Log Data Directory = D:/MySQL/MySQL Server 5.6/binlog/UC-MYSQL-01-bin.log

Here, different paths are set for data and log file generation. If the user specifies datadir path for Log Data Directory in the instance properties from the CommCell Console, the error is generated.

Resolution 1

From the CommCell Console, change the path for Log Data Directory in the instance properties.

Cause 2

The backup operation fails if the MySQL Server has binary logging enabled with number of days set for expire_log_days. The backup operation fails to back up the log files as they are expired and were deleted from the server (base on the number of days set for expire_log_days).

For example,

In my.ini or my.cnf file, if the number of days set for expire_log_days is 10, then the logs expire after 10 days. If there is a backup operation, then it will fail as there are no logs to back up.

Resolution 2

Use any one of the following methods to resolve this issue:

  • Increase the number of days set for expire_log_days to a value that is adequate to back up the log files.
  • Do not set a value for expire_log_days.

MSQL0007: MySQL backup operation fails if the physical node is uninstalled from the cluster group and then reinstalled

Cause

MySQL backup operation fails because the reinstalled physical node is not added automatically to the cluster group.

Resolution

To run the backup operation successfully, follow these steps to manually add the node and force a synchronization.

  1. From the CommCell Browser, right-click the <Cluster Group Client> node, and then click Properties.
  2. In the Client Computer Properties dialog box, click Advanced.
  3. Click the Cluster Group Configuration tab.
  4. Select the reinstalled physical node from the Available list and click Add > to add it to the Selected list.
  5. Select the Force Sync Configuration on Remote Nodes check box.
  6. Click OK.
  7. Run the backup operation.

MSQL0008: First MySQL job run from the CommCell Console fails with missing InnoDB table error

Symptom

First MySQL job run on the CommCell Console fails with the following error message.

/galaxy_bkp_mycnf_5337_1418761194_1141_1141_1283053 --tz-utc=FALSE  --flush-privileges  --single-transaction   --flush-logs --master-data=2 --create-options -B --default-character-set=utf8  --routines  --max_allowed_packet=1073741824  -u root --socket=/var/lib/mysql/mysql.sock 'mysql' > /opt/install_dir/iDataAgent/jobResults/2/5337/pipe1283053_1141 out =  err = Error: Couldn't read status information for table innodb_index_stats ()

mysqldump: Couldn't execute 'show create table `innodb_index_stats`': Table 'mysql.innodb_index_stats' doesn't exist (1146)
ret = 2

mysql> SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='innodb_index_stats';

Cause

This error message is displayed for MySQL version 5.6.

Resolution

Follow the given steps to resolve this issue:

  1. Drop these five InnoDB tables from MySQL
    • innodb_index_stats
    • innodb_table_stats
    • slave_master_info
    • slave_relay_log_info
    • slave_worker_info
  2. Delete .frm and .ibd from the above mentioned tables located at mysql_data_dir/database_name.
  3. Recreate the above mentioned tables.
  4. Restart the MySQL Server.

MSQL0010: Error Code [87:90] Full or log-only backup operation fails

Symptom

MySQL backup operation fails with the following error message.

Error Code: [87:90]
Description: Backup process could not find log [~/home/mysql2/mysql-bin.000118~] in the given transaction log location. It could be due to binary log is missing or incorrect transaction log location. Please purge and flush the logs manually. The next backup will be converted to FULL. Advice: If transaction log location is correct, please check the missing log number error message and if it is not available physically, purge logs manually to next available log number and submit the next Job as Full for consistent backup.

You can also see the following error in the MySqlBackup.log file:

26817 30024720 10/26 14:30:51 157532 mysqlLogBackup:ArchiveLogs() - log file(/var/lib/mysql/log-bin/binlog.000050) is missing, So converting the log backup to full backup.

Cause

The backup operation fails if the one or more log files in the MySQL Server are deleted or corrupted.

In the following example, log number 50 is missing:

mysql> show master logs;
+---------------+-----------+
| Log_name | File_size |
+---------------+-----------+
| binlog.000049 | 10702 |
| binlog.000050 | 0 |
| binlog.000051 | 15464 |

Resolution

Follow the given steps to resolve this issue:

  1. Purge the binary logs manually to the next sequentially available log file in the log directory.

    For example, if log number 50 is missing, you can purge the binary logs to log number 51 by using the following command:

    mysql>purge binary logs to 'binlog.000051';

  2. Run a full backup job.

Note: After purging the binary logs, always run a full backup as the first backup job.

MSQL0011: Troubleshooting steps to find out the reason for backup operation failure

Symptom

MySQL backup operation fails with an error in the log files.

For example, you can find the following error in the MySqlBackupChild.log file:

MySqlBackupDb::DoBackupDbUsingPipe() - sending command = [/usr/bin/mysqldump --defaults-file=/opt/commvault/Base/Temp/galaxy_bkp_mycnf_7_1465938657_31948_31948_3100 --tz-utc=FALSE  --flush-privileges --lock-tables   --flush-logs --master-data=2 --create-options -B --default-character-set=utf8  --routines  --max_allowed_packet=1073741824  -u root --socket=/var/lib/mysql/mysql.sock --databases mysql]
31948 7ccc 06/14 14:11:04 3100 MySqlChildProcess::Wait() - Child died after receiving signal 2

Cause

In this example, execution of the native MySQL dump command is failing.

Resolution

  1. Run the following command to find out if the error encountered during a backup operation is due to an issue with the MySQL server or with the SnapProtect software:

    /usr/bin/mysqldump --tz-utc=FALSE --flush-privileges --lock-tables --flush-logs --master-data=2 --create-options -B --default-character-set=utf8 --routines --max_allowed_packet=1073741824 -u root --socket=/var/lib/mysql/mysql.sock --databases mysql -p > mysqldb.sql

  2. Enter the password.
  3. If you receive an error as output, there is an issue with the MySQL server.

    For example:

    Error: Couldn't read status information for table innodb_index_stats ()
    mysqldump: Couldn't execute 'show create table `innodb_index_stats`': Table 'mysql.innodb_index_stats' doesn't exist (1146)

MSQL0013: MySQL backup operation fails in the scan phase

Symptom1

MySQL backup operation fails in the scan phase with the following error in the MySqlIfind.log file on the client:

1797 12006400 06/29 19:35:47 19  ::MySqlIfind() - getDBProps failed
1797 12006400 06/29 19:35:47 19  ::main() - MySqlIfind() failed retCode=[-1]

Cause1

MySQL Server is in SQL Mode, and ONLY_FULL_GROUP_BY option is enabled.

Resolution1

If MySQL Server is in SQL Mode, disable the ONLY_FULL_GROUP_BY option, and then run the backup operation.

Symptom 2

MySQL backup operation fails when using a third party application with customized MySQL binaries.

MySqlIfind.log file displays an error message similar to the example error mentioned below:

12339 3033 07/04 11:34:35 21079 GetMySqlInfo::FindAllDatabasePaths() - executeMySqlCommand, command=show variables like 'datadir';, out=/opt/xxx-3.4.a/mysql/bin//mysql.bin: unknown variable 'defaults-file=/opt/commvault/Base/Temp/galaxy_bkp_mycnf_13_1467624875_12339_12339_21079', ret=-1

Cause 2

The backup operation fails because of using a third party application with customized MySQL binaries.

Resolution 2a

Follow the steps give below to resolve this issue.

  1. From the MySQL official website, download the client-side binaries on your computer. For example, you can download the binaries in the folder /opt/mysql-client-dump.
  2. Extract the contents of the binary file using a command similar to the example mentioned below:

    rpm2cpio MySQL-client-community-5.1.73-1.rhel5.x86_64.rpm | cpio –idmv

  3. Change the binary directory of the MySQL server by pointing it to the directory where the new extracted binaries are saved.
  4. Run the native command that initially failed on the client, similar to the example mentioned below:

    /opt/mysql-client-dump/usr/bin/mysql --defaults-file=/XX/my.cnf --default-character-set=utf8 -u root -p xxxx --socket=/xxxx/mysql.sock -e "show variables like 'datadir';" --batch --skip-column-names

  5. Check if the native command fails or not.
    • If the native command does not fail, from the CommCell Console, change the binary directory to the directory where the new extracted binaries are saved, and then run a backup operation.
    • If the native command fails, perform the steps mentioned under Resolution 2b.

Resolution 2b

Follow the steps give below to resolve this issue.

  1. Create a new configuration file my.cnf in the folder /opt/mysql-client-dump.
  2. Copy and paste the following information in the my.cnf file:

    [mysqld]
    basedir=/XXX/mysql
    datadir=/XXXXXXX/data
    port=3306
    socket=/XXXXXXXXXX/mysql.sock
    tmpdir=/XXXXX/tmp
    log_bin=ON
    log-bin=/XXXX/mysql-bin.log
    max_binlog_size=536870912
    binlog_format=MIXED

  3. Change the configuration file location of the MySQL server by pointing it to the newly created configuration file.
  4. Run the native command that initially failed on the client, similar to the example mentioned below:

    /opt/mysql-client-dump/usr/bin/mysql --defaults-file=/XX/my.cnf --default-character-set=utf8 -u root -p xxxx --socket=/xxxx/mysql.sock -e "show variables like 'datadir';" --batch --skip-column-names

  5. On successfully passing the native command, from the CommCell Console, change the binary directory and the configuration file location of the MySQL server.
  6. Run a backup operation.

MSQL0014: Error Code [87:90] MySQL backup operation goes into pending state with MySQL error

Symptom 1

On MariaDB from version 5.5.37 to version 5.5.41, MySQL backup operation goes into pending state in the backup phase with the following error message on the CommCell Console:

Error Code:[87:90]
Description: The database [~test~] dump size is [~1265~] bytes which is too small for valid backup. Please read client logs for details and solution.

Run the flush logs command in the MySQL server. You will get the following error:

MariaDB [(none)]> flush logs;
ERROR 1105 (HY000): Unknown error

You get this error because you have enabled -syslog for mysqld_safe parameter and -log-error for mysqld parameter in the configuration file on MySQL server.

In this case, if you run the mysqldump command with -flush logs parameter, then mysqldump command will silently exit without dumping any data.

Cause 1

During the backup operation on MariaDB from version 5.5.37 to version 5.5.41, size of the dump is less than 5 KB.

Resolution 1

You can follow any one of the given steps to resolve this issue:

  • Upgrade MariaDB to a version 5.5.42 or later.
  • From the MySQL configuration file, either disable -syslog for mysqld_safe parameter or disable -log-error for mysqld parameter and restart the MySQL server.

    Now, when you run the flush logs command in MySQL server, you should not get any error:

    MariaDB [(none)]> flush logs;
    Query OK, 0 rows affected (0.01 sec)

Symptom 2

On MariaDB from version 5.5.37 to version 5.5.41, MySQL backup operation goes into pending state in the backup phase with the following error message on the CommCell Console:

Error Code:[87:90]
Description: The database [~test~] dump size is [~1265~] bytes which is too small for valid backup. Please read client logs for details and solution.

Run the flush logs command in MySQL server, you will not get any error.

Cause 2

During the backup operation on MariaDB from version 5.5.37 to version 5.5.41, size of the dump is less than 5 KB.

Resolution 2

You can follow any one of the given steps to resolve this issue:

  • Create the additional setting sDisableDumpSizeCheck and set its value as Y. This will not run a dump size check on the backed up databases. You can now resume the backup operation.

    For instructions on adding the additional setting from the CommCell Console, see Add or Modify an Additional Setting.

  • Customize the dump size check per database by adding the additional setting nMinValidDumpSize, and by setting its value to a numerical dump size value in bytes. The backup operation will not go into a pending state if the dump size is greater or equal to the value that you have set for this additional setting.

    For instructions on adding the additional setting from the CommCell Console, see Add or Modify an Additional Setting.

MSQL0015: Error Code [87:90] MySQL backup operation fails in the backup phase

Symptom

On MariaDB from version 5.5.37 to version 5.5.41, MySQL backup operation goes into pending state in the backup phase with one of the following error messages on the CommCell Console.

If you have InnoDB engine database, you will get the following error message:

Error Code:[87:90]
Description: The database [~test~] dump size is [~1265~] bytes which is too small for valid backup. Please read client logs for details and solution.

If you have MyISAM engine database, you will get the following error message:

Error Code:[87:90]
Description: The database [~test~] dump size is [~1265~] bytes which is too small for valid backup. Please read client logs for details and solution.

Run the flush logs command in the MySQL server. You will get the following error:

MariaDB [(none)]> flush logs;
ERROR 1105 (HY000): Unknown error

You get this error because you have enabled -syslog for mysqld_safe parameter and -log-error for mysqld parameter in the configuration file on MySQL server.

In this case, if you run the mysqldump command with -flush logs parameter, then mysqldump command will silently exit without dumping any data.

Cause

During the backup operation on MariaDB from version 5.5.37 to version 5.5.41, size of the dump is less than 5 KB.

Resolution

You can follow any one of the given steps to resolve this issue:

  • Upgrade MariaDB to a version 5.5.42 or later.
  • From the MySQL configuration file, either disable -syslog for mysqld_safe parameter or disable -log-error for mysqld parameter and restart the MySQL server.

    Now, when you run the flush logs command in MySQL server, you should not get any error:

    MariaDB [(none)]> flush logs;
    Query OK, 0 rows affected (0.01 sec)

MSQL0016: Error Code [19:1109] MySQL backup operation fails during the backup phase

Symptom

On MariaDB from version 5.5.37 to version 5.5.41, MySQL backup operation goes into pending state in the backup phase with the following error messages on the CommCell Console:

Error Code: [19:1109]
Description: Please check the log files for this job for more details.

In the MySqlBackupChild.log file, you will get the following error message:

31061 7955 09/23 11:52:08 225876 GetMySqlInfoExt::FlushLogs() - Trying to flush Logs...
31061 7955 09/23 11:52:08 225876 ::MySqlClBackupBase::DoBackupMySql() - Unable to flushLogs: Some error occurred

Run the flush logs command in the MySQL server. You will get the following error:

MariaDB [(none)]> flush logs;
ERROR 1105 (HY000): Unknown error

You get this error because you have enabled -syslog for mysqld_safe parameter and -log-error for mysqld parameter in the configuration file on MySQL server.

In this case, if you run the mysqldump command with -flush logs parameter, then mysqldump command will silently exit without dumping any data.

Cause

During the backup operation on MariaDB from version 5.5.37 to version 5.5.41, size of the dump is less than 5 KB.

Resolution

You can follow any one of the given steps to resolve this issue:

  • Upgrade MariaDB to a version 5.5.42 or later.
  • From the MySQL configuration file, either disable -syslog for mysqld_safe parameter or disable -log-error for mysqld parameter and restart the MySQL server.

    Now, when you run the flush logs command in MySQL server, you should not get any error:

    MariaDB [(none)]> flush logs;
    Query OK, 0 rows affected (0.01 sec)

MSQL0017: Error Code [87:27] MySQL backup operation fails with no database to back up error

Symptom

MySQL backup operation fails with the following error messages on the CommCell Console:

Error Code: [87:27]
Description: No database has been selected for backup. Either the subclient content is empty or database in subclient is in invalid state.

You will also find the following error message in the MySqlIfind.log file:

15998 3e7e 11/04 01:37:45 253514 ::MySqlIfind() - MySql database search completed.
15998 3e7e 11/04 01:37:45 253514 ::main() - There are no Databases to backup!!!
15998 3e7e 11/04 01:37:45 253514 Laptop2JobStatus::endJobPhase() - isLastPhase[no],isSuccessful[no],successFilesCount[0],failedFilesCount[0]
15998 3e7e 11/04 01:37:45 253514 ::exitHere() - Couldn't report phase completion status to laptop2: Laptop2JobStatus::endJobPhase : Object not initialized

Cause

The user does not have access to all the databases on the MySQL server.

Resolution

Use the following command to grant all databases access to the user:

mysql> grant all privileges on *.* to 'SAUser'@'localhost' identified by '<password>';

Completed with one or more errors

Backup jobs from MySQL iDataAgent will be displayed as "Completed w/ one or more errors" in the Job History in the following cases:

  • If the subclient contains multiple databases, and some of the database backups encounter errors and other database backups run successfully.

  • If the subclient contains multiple databases, and some databases in the subclient are corrupted or removed from the database server.

Error Code [19:1109] Backup goes into pending state with MySQL error

A restore operation for MySQL from the same host or to a different host fails.

Article ID: MSQL0003

Error Code [87:27] First backup operation on a new subclient fails with MySQL error

First MySQL backup operation on a new subclient fails.

Article ID: MSQL0004

Error Code: [87:83] Log restore operation failed

MySQL log restore operation fails

Article ID: MSQL0006