SnapProtect - Troubleshooting - MySQL iDataAgent

SS0024: MySQL log backup associated with the SnapProtect backup fails

Symptom

During MySQL SnapProtect backup operation, the associated log backup operation fails with the following error message:

[19:1109]
Description: Please check the log files for this job for more details.
Source: basecs, Process: JobManager

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

62805 ac745740 01/16 11:13:15 590394 mysqlLogBackup:ArchiveLogs() - system command = /native/mariadb-5.5.41-linux-x86_64/bin//mysqladmin --defaults-file=/opt/simpana3/Base/Temp/galaxy_bkp_mycnf_21517_1484545390_62805_62805_590394 --default-character-set=utf8 -u root --socket=/var/lib/mysql/mysql-maria.sock flush-logs out =  err = /native/mariadb-5.5.41-linux-x86_64/bin//mysqladmin: flush failed; error: 'Unknown error'
 ret = 255
62805 ac745740 01/16 11:13:15 590394 mysqlLogBackup:ArchiveLogs() - system command = /native/mariadb-5.5.41-linux-x86_64/bin//mysqladmin --defaults-file=/opt/simpana3/Base/Temp/galaxy_bkp_mycnf_21517_1484545390_62805_62805_590394 --default-character-set=utf8 -u root --socket=/var/lib/mysql/mysql-maria.sock flush-logs out =  err = /native/mariadb-5.5.41-linux-x86_64/bin//mysqladmin: flush failed; error: 'Unknown error'
 ret = 255
62805 ac745740 01/16 11:13:15 590394 mysqlLogBackup:ArchiveLogs() - system [command] failed

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)

SS0023: MySQL server does not start automatically after the SnapProtect restore operation is complete

Symptom

After the data restore (as part of MySQL SnapProtect restore operation) is complete, the MySQL server starts automatically only if the installed MySQL service name is "MySQL". The server does not start automatically if the service is installed with any other name.

Resolution

Follow these steps to automatically start the MySQL server after the data restore (as part of MySQL SnapProtect restore operation) is complete, even if the installed service name is not "MySQL".

  1. From the CommCell Browser, navigate to Client Computers.
  2. Right-click the <Client> to be configured and then click Properties.
  3. Click Advanced.
  4. Click the Additional Settings tab and then click Add.
  5. In the Name field, type sServerStartCmd.
  6. In the Value field, type any one of the following commands:
    • service <MySQLInstanceName> start for a UNIX client
    • Any other command that you use to launch the MySQL server

    To start the MySQL server manually after the data restore (as part of MySQL SnapProtect restore operation) is complete, set the value for bManualServerStart as 1 from the MySQL Client Computer Properties dialog box.

  7. Click OK to save the key.
  8. Click OK.
  9. Start the backup operation.

SS0020: SnapProtect restore operation fails if MySQL server is running

SnapProtect restore operation fails with the following error message:

Description: Failure:[~Restoring from snap based backup, the destination MySQL server should be offline. Please shutdown the server and resume the job.]

Symptom

Restoring databases from a snapshot or backup copy fails if you attempt to restore while the MySQL server is running.

Resolution

Before you start the restore, make sure that the MySQL server is offline.

If you attempt to restore while the server is running, the software will notify you to shutdown the server and then resume with the restore:

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.

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

  • During Logs Restore, if applying log into a database fails, it marks such databases as non-recoverable and continues with other databases.

Recovering data associated with deleted clients and storage policies

Symptom

In a disaster recovery scenario, use the following procedure to recover data associated with the following entities:

  • Deleted storage policy
  • Deleted client, agent, backup set or instance

Before You Begin

This procedure can be performed when the following are available:

  • You have a Disaster Recovery Backup that contains information on the entity that you are trying to restore. For example, if you wish to recover a storage policy (and the data associated with the storage policy) that was accidentally deleted, you must have a copy of the disaster recovery backup that was performed before deleting the storage policy.
  • Media containing the data you wish to recover is available and not overwritten.
  • If a CommCell Migration license was available in the CommServe when the disaster recovery backup was performed, no additional licenses are required. If not, obtain the following licenses:
    • IP Address Change license
    • CommCell Migration license

    See License Administration for more details.

  • A standby computer, which is used temporarily to build a CommServe.
Recovering Deleted Data
  1. Locate the latest Disaster Recovery Backup that contains the information on the entity (storage policy, client, agent, backup set or instance) you are trying to restore.
    • Check the Phase 1 destination for the DR Set or use Restore by Jobs for CommServe DR Data to restore the data.
    • If the job was pruned and you know the media containing the Disaster Recovery Backup, you can move the media in the Overwrite Protect Media Pool. See Accessing Aged Data for more information. You can then restore the appropriate DR Set associated with the job as described in Restore by Jobs for CommServe DR Data.
    • If the job is pruned and you do not know the media containing the Disaster Recovery Backup, you can do one of the following:
      • If you regularly run and have copies of the Data on Media and Aging Forecast report, you can check them to see if the appropriate media is available.
      • If you do not have an appropriate report, and know the media that contains the DR Backup, catalog the media using Media Explorer. Once the cataloging process is completed, details of the data available in the media are displayed.
  2. On a standby computer, install the CommServe software. For more information on installing the CommServe, see Install the CommServe.
  3. Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See CommServe Disaster Recovery Tool for step-by-step instructions.)
  4. Verify and ensure that the NetApp Client Event Manager NetApp Communications Service (EvMgrS) is running.
  5. If you did not have a CommCell Migration license available in the CommServe when the disaster recovery backup was performed, apply the IP Address Change license and the CommCell Migration license on the standby CommServe. See Activate Licenses for step-by-step instructions.
  6. Export the data associated with the affected clients from the standby CommServe as described in Export Data from the Source CommCell.

    When you start the Command Line Interface to capture data, use the name of the standby CommServe in the -commcell argument.

  7. Import the exported data to the main CommServe as described in Import Data on the Destination CommCell.

    This brings back the entity in the CommServe database and the entity is visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)

  8. You can now browse and restore the data from the appropriate entity.

    As a precaution, mark media (tape media) associated with the source CommCell as READ ONLY before performing a data recovery operation in the destination CommCell.