The server cannot execute multiple BACKUP DATABASE and RESTORE statements concurrently. Each statement blocks the other as well as other instances of itself.

BACKUP DATABASE backs up database and table definitions, table data, views, stored programs (functions, procedures, triggers, events), and privileges. TEMPORARY tables are not included. Privileges for backed-up databases are saved. This includes privileges at the database level and below (table, column, routine). Global privileges are not saved.

BACKUP DATABASE does not back up the mysql or INFORMATION_SCHEMA databases.

For anything else not explicitly listed, assume that it is not backed up. This includes but is not limited to items such as UDF definitions and files, logs, and option files.

BACKUP DATABASE and RESTORE cannot be used in stored programs (functions, procedures, triggers, events).

BACKUP DATABASE and RESTORE cannot be used as prepared statements.

The backup image is consistent and has a well-defined validity point regardless of the storage engines used. However, nontransactional tables are locked for the duration of the BACKUP DATABASE operation if they use a storage engine other than MyISAM (such as ARCHIVE or MEMORY).

All storage engines that are represented by tables in the backup image must be enabled in the server on which a restore operation is performed. For example, if a backup image contains ARCHIVE tables and the server does not have the ARCHIVE storage engine enabled, the table cannot be restored and the operation fails.

For restore operations, only those privileges are restored that pertain to accounts that exist on the MySQL server performing the restore. Other privileges are ignored with a warning. (These warnings can be displayed with SHOW WARNINGS.) Restoration of privileges for nonexistent accounts is not done because that would implicitly create accounts that have no password, which is a security risk.

Restore operations create database objects with a creation or modification time of their creation within the restore operation. For some database objects, such as stored procedures, timestamps for creation or modification are maintained in system tables. These are not reset to the value they had at backup time.