Error Messages
Failure Messages
- Permission denied (publickey,keyboard-interactive)
- The ZRM server's mysql user cannot login to the mysql client using passwordless authentication. You must set up public/private key authentication between the ZRM server and the MySQL server. See this KB article for details.
- mysqlhotcopy_path:No such file or directory
- The path specified for mysqlhotcopy on the Backup How page is incorrect. Specify the correct path.
- Permission denied at /opt/zmc/mysql/bin/mysqlhotcopy
- The uid and gid for the mysql user on the ZRM server are different from those on the ZRM server. They must match.
- mysqlhotcopy did not succeed
- The partition where ZRM is installed is out of space. Free up some space on that partition.
- Unable to abort backup run for backup-set
- The backup run cannot be aborted due to some delay or error condition. Check for other errors with the backup set (such as snapshot errors) and try again.
- mysqldump:Got errno 28 on write
- The backup destination directory is full. Free up or add space to the relevant partition and re-run the backup set.
- mail command failed
- The path to the mail command does not exist. Please check that the ZRM server is correctly configured to send mail. ZRM for MySQL cannot send notifications unless there is a mail command installed in one of the following directories: /usr/local/bin, /opt/csw/bin, /usr/bin, /usr/sbin, /sbin:/bin, or /usr/ucb.
- Unable to use snapshot
- The snapshot-based backup failed for some reason (for example, the volume has exhausted the free extents). Turn on verbose logging and run the backup again to determine the exact cause of the problem. See this KB article for details.
- Error backing up
- There was a problem with backing up replication files. Check the permissions for the mysql user.
- Could not copy bin log file
- Check that the bin-log file exists in the path specified in the Backup How page, and that the mysql user has the required permissions.
- Cannot find bin log file
- ZRM for MySQL was unable to back up the MySQL bin-log file or replication files. Check that the bin-log file exists in the path specified in the Backup How page, and that the mysql user has the required permissions.
- backup failed
- This error appears when the backup failed for any of a number of reasons, such as snapshot failure or running out of physical volume extents. Enable verbose logging as described here, then collect the logs and send them to the Zmanda support team as described here.
- error opening temporary file
- The mysql user does not have permission to write to the temporary directory. Set permissions so that the mysql user can write to the temporary directory defined on the Backup Where page (/tmp is the default).
- Cannot read tmp file
- The mysql user does not have permission to read from the temporary directory. Set permissions so that the mysql user can read from the temporary directory defined on the Backup Where page (/tmp is the default).
- mysql-zrm appears to be already running
- This error occurs when a mysql-zrm process is already running for a backup set. Remove the file /etc/mysql-zrm/backup_set_name/.mysql-zrm.pid
- Could not read file
- This error occurs when running in cluster mode, and indicates that the mysql user does not have read/write permission on the cluster backup directory. Give the mysql user permissions to that directory. Instructions for migrating the mysql user from a standard setup to a cluster setup are here.
- ndb_mgm
- This message indicates that the MySQL-ndb-tools and MySQL-ndb-management RPM packages are not installed in your system. Install these packages on the target system and try again.
- Unable to copy backup dir
- The mysql backup user does not have permission to read from the cluster backup directory. Ensure that the mysql user has read permissions on the cluster backup directory. For instructions on migrating the required permissions to the mysql user, see this KB article.
- could not delete in directory
- The mysql backup user does not have permission to write to the backup directory. Ensure that the mysql user has write permissions on the backup directory. For instructions on migrating the required permissions to the mysql user, see this KB article.
- Can not open output file for writing
- Ensure that the mysql user has permission to the given directory and file. For instructions on migrating the required permissions to the mysql user, see this KB article.
- Could not copy database
- This error indicates that a copy plugin failed, possibly due to the mysql user not having the correct permissions. For instructions on migrating the required permissions to the mysql user, see this KB article.
- copy-plugin exited with error 512
- The copy plugin failed due to any of the reasons listed here, the most likely reason being that the UID or GID of the mysql user is different on the client and ZRM server.
- Bad retention policy
- The values specified for retention policy are not numeric or outside the valid range. Ensure the retention policy is specified as a numeric value, and that it falls within the range of 1 day to 1 year.
- Could not copy file
- ZRM for MySQL could not copy the bin-log file(s), perhaps because of a permissions problem or a mismatch between the UID/GID of the mysql user on the client and server. For instructions on migrating the required permissions to the mysql user, see this KB article.
- Error stopping slave
- This error occurs if the user lacks permission to stop/start the slave. Make sure that ssh keys have been exported properly on all the nodes. Make sure that the sudoer file has been configured correctly on the nodes. For more information regarding sudoer configuration, see this KB article.
- Replication data will not be backed up
- This error occurs if MySQL replication is misconfigured or otherwise inoperative, or the Replication peer is unreachable. Make sure that Replication is configured and working properly, and that the Replication peer is reachable.
- No write permissions on
- This error occurs when the mysql backup user does not have write permissions on the destination directory. Ensure that the mysql backup user has write permissions on destination directory. For instructions on configuring the correct permissions for the mysql backup user, see this KB article.
- Unable to connect to cluster
- This message indicates that ZRM is unable to connect to the cluster. There are many issues that can prevent connection to the cluster. Please see the MySQL web site and documentation for further details on cluster errors.
- Could not get md5 checksum
- This error indicates that the backup has failed the MD5 checksum because it has been corrupted. Take a new backup.
- checksum for file does not match
- This error indicates that the backup has failed the MD5 checksum because it has been corrupted. Take a new backup.
- Errors found during configuration check
- The backup set failed the configuration check, perhaps because of a permissions problem or a mismatch between the UID/GID of the mysql user on the client and server. For instructions on migrating the required permissions to the mysql user, see this KB article.
- mysqlbinlog failed for file
- There can be many reasons for a binary log restore to fail. Turn on verbose logging and run the restore again to determine the exact cause of the problem. Use the zm-support tool to collect the logs and send them to the Zmanda Support team if you need further assistance.
- Backup root directory not found
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- Backup Set directory not found
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- can not parse this index file
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- Can not open index file
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- Restore failed
- There can be many reasons for a restore to fail. Turn on verbose logging and run the restore again to determine the exact cause of the problem. Use the zm-support tool to collect the logs and send them to the Zmanda Support team if you need further assistance.
- Restore from logical backup failed
- There can be many reasons for a logical restore to fail. Turn on verbose logging and run the restore again to determine the exact cause of the problem. Use the zm-support tool to collect the logs and send them to the Zmanda Support team if you need further assistance.
- Failed to restore database from raw backup
- There can be many reasons for a raw restore to fail. Turn on verbose logging and run the restore again to determine the exact cause of the problem. Use the zm-support tool to collect the logs and send them to the Zmanda Support team if you need further assistance.
- Failed to restore innodb databases
- There can be many reasons for an InnoDB restore to fail. Turn on verbose logging and run the restore again to determine the exact cause of the problem. Use the zm-support tool to collect the logs and send them to the Zmanda Support team if you need further assistance.
- ndb_restore
- This message indicates that the MySQL-ndb-tools and MySQL-ndb-management RPM packages are not installed in your system. Install these packages on the target system and try again.
- Restart of cluster node(s) failed
- The Cluster failed to restart automatically after a successful restore. Restart the cluster and all nodes manually.
- Timeout hit while waiting for nodes(s) to restart
- The Cluster failed to restart automatically after a successful restore. Restart the cluster and all nodes manually.
- not found in index
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- Errors found during verification
- This message indicates a problem with the backup resulting in data corruption. Perform the backup again.
- Duplicate entry
- MySQL for ZRM has encountered a MySQL bug.
- Can not open license file
- Indicates that the ZRM for MySQL license file (/etc/zmanda/zmanda_license) does not exist, or the mysql user does not have permission to read it.
- innobackup.pl: No such file or directory
- There is a problem with the location and/or execute permissions of ibbackup/innobackup.pl. Download the innobackup.pl script from www.innodb.com (version 1.5.0 or higher) and install it in the same place that ibbackup is installed (usually /usr/bin) on the MySQL Server. Make sure the mysql user has execute permissions on the file.
- sh: ibbackup: command not found
- There is a problem with the location and/or execute permissions of ibbackup/innobackup.pl. Download the innobackup.pl script from www.innodb.com (version 1.5.0 or higher) and install it in the same place that ibbackup is installed (usually /usr/bin) on the MySQL Server. Make sure the mysql user has execute permissions on the file.
Warning Messages
- Could not open file
- The mysql backup user does not have the necessary read/write permission on the backup directory. Ensure that the mysql user has write permissions on the backup directory. For instructions on migrating the required permissions to the mysql user, see this KB article.
- last backup directory is not valid
- This message occurs when the last full backup does not exist, either because it was purged or never taken. Perform a full backup as soon as possible.
- Error starting slave
- This error occurs if the user lacks permission to stop/start the slave. Make sure that ssh keys have been exported properly on all the nodes. Make sure that the sudoer file has been configured correctly on the nodes. For more information regarding sudoer configuration, see this KB article.
- Binary logging is OFF
- This message indicates that MySQL binary logging is disabled on the MySQL server (backup client). Binary logging is required for incremental backups. Follow these steps to correct the problem:
- 1. Edit the MySQL configuration file (typically /etc/my.cnf) to include the following entry in the [mysqld] section:
log-bin
- 2. Restart MySQL.
- See the MySQL documentation for details on enabling binary logs.
- 'databases' specified will be ignored
- If you choose both Database and Tables from the same database in a backup set, then the selectedTables are backed up and the Database selection is ignored.
- Database is empty and hence will not be backedup
- ZRM for MySQL will not perform a backup on a database that contains no data.
- Error getting device details
- This message indicates that the mysql backup user lacks the necessary sudo privileges. For details on sudoer configuration see this KB article.
- Could not copy table
- This message indicates that the mysql backup user lacks the necessary sudo privileges. For details on sudoer configuration see this KB article.
- Snapshot create failed
- The volume does not have enough free extents available to create the snapshot. Check that you have sufficient free extents available on the volume group to create snapshots. Use lvdisplay to check the volume. If you have insufficient free extents then you must add physical volumes to the group. For more information on the procedure to resize an LVM2 logical volume see this Redhat Knowledgebase article.
- Snapshot failed as copy failed
- The volume does not have enough free extents available to create the snapshot. Check that you have sufficient free extents available on the volume group to create snapshots. Use lvdisplay to check the volume. If you have insufficient free extents then you must add physical volumes to the group. For more information on the procedure to resize an LVM2 logical volume see this Redhat Knowledgebase article.
- flush tables with read lock and create snapshot failed
- The volume does not have enough free extents available to create the snapshot. Check that you have sufficient free extents available on the volume group to create snapshots. Use lvdisplay to check the volume. If you have insufficient free extents then you must add physical volumes to the group. For more information on the procedure to resize an LVM2 logical volume see this Redhat Knowledgebase article.
- Unable to open directory
- This message indicates that the mysql backup user lacks the necessary sudo privileges. For details on sudoer configuration see this KB article.
- umount failed
- This message indicates that the mysql backup user lacks the necessary sudo privileges. For details on sudoer configuration see this KB article.
- The table(s) of the database will be backed up in logical mode since some of the tables use a transactional engine
- To backup a mixed set of databases (non-transactional and transactional), you must either do a logical backup or use snapshots.
- It appears that node id is not in started state
- This message indicates that the cluster did not automatically restart after a successful restore. Manually restart the cluster and all nodes.
- Nothing to do
- This message indicates you are trying to restore or verify an unsuccessful backup.
- Backup root directory not specified, Assigning default value
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- Backup info fields not specified
- This error indicates either of the following:
- An invalid/non-existent destination directory has been specified in the backup set.
- The mysql user lacks necessary permissions on the directory.
- Note: The destination directory refers to the directory path specified for the backup set in the Backup Where page. By default it is /var/lib/mysql-zrm. Make sure that destination directories are present and owned by mysql user and group.
- Restoring from a backup which was not successful
- This message indicates you are trying to restore or verify an unsuccessful backup.
- Backup status is not available in the index file
- This message indicates you are trying to restore or verify an unsuccessful backup.
- Restoring from this may not be successful
- This message indicates you are trying to restore or verify an unsuccessful backup.
- Restoring from a raw backup without shutting down the MySQL server can result in unexpected problems
- You must shut down the MySQL server before performing a raw backup to ensure the database is backed up in a consistent state.
- After restore is completed, please verify the restored data
- This message is reminder to verify the restored data after a successful restore to ensure that the correct data was in fact restored.
- Nothing to verify
- This message indicates you are trying to restore or verify an unsuccessful backup.
- mysqladmin: command not found
- ZRM for MySQL can not find the MySQL executables in the default location, or in the location specified in the Backup What page.
- /usr/bin/mysql: not found
- ZRM for MySQL can not find the MySQL executables in the default location, or in the location specified in the Backup What page.
- only root can do that
- This message indicates that the mysql backup user lacks the necessary sudo privileges. For details on sudoer configuration see this KB article.
- Insufficient free extents
- The volume does not have enough free extents available to create the snapshot. Check that you have sufficient free extents available on the volume group to create snapshots. Use lvdisplay to check the volume. If you have insufficient free extents then you must add physical volumes to the group. For more information on the procedure to resize an LVM2 logical volume see this Redhat Knowledgebase article.