The backup is done by querying the MySQL server to obtain database structure and content information.

Backup is slower than physical methods because the server must access database information and convert it to logical format. If the output is written on the client side, the server must also send it to the backup program.

Output is larger than for physical backup, particularly when saved in text format.

Backup and restore granularity is available at the server level (all databases), database level (all tables in a particular database), or table level. This is true regardless of storage engine.

The backup does not include log or configuration files, or other database-related files that are not part of databases.

Backups stored in logical format are machine independent and highly portable.

Logical backups are performed with the MySQL server running. The server is not taken offline.

Logical backup tools include the mysqldump program and the SELECT ... INTO OUTFILE statement. These work for any storage engine, even MEMORY.

To restore logical backups, SQL-format dump files can be processed using the mysql client. To load delimited-text files, use the LOAD DATA INFILE statement or the mysqlimport client.

The backup consists of exact copies of database directories and files. Typically this is a copy of all or part of the MySQL data directory. Data from MEMORY tables cannot be backed up this way because their contents are not stored on disk.

Physical backup methods are faster than logical because they involve only file copying without conversion.

Output is more compact than for logical backup.

Backup and restore granularity ranges from the level of the entire data directory down to the level of individual files. This may or may not provide for table-level granularity, depending on storage engine. (Each MyISAM table corresponds uniquely to a set of files, but an InnoDB table shares file storage with other InnoDB tables.)

In addition to databases, the backup can include any related files such as log or configuration files.

Backups are portable only to other machines that have identical or similar hardware characteristics.

Backups can be performed while the MySQL server is not running. If the server is running, it is necessary to perform appropriate locking so that the server does not change database contents during the backup.

Physical backup tools include file system-level commands (such as cp, scp, tar, rsync), mysqlhotcopy for MyISAM tables, or ibbackup for InnoDB tables.

For restore, files copied at the file system level or with mysqlhotcopy can be copied back to their original locations with file system commands; ibbackup restores InnoDB tables, and ndb_restore restores NDB tables.

The backup is less intrusive to other clients, which can connect to the MySQL server during the backup and may be able to access data depending on what operations they need to perform.

Care must be taken to impose appropriate locking so that data modifications do not take place that would compromise backup integrity.

Clients can be affected adversely because the server is unavailable during backup.

The backup procedure is simpler because there is no possibility of interference from client activity.

mysqldump can connect to local or remote servers. For SQL output (CREATE and INSERT statements), local or remote dumps can be done and generate output on the client. For delimited-text output (with the --tab option), data files are created on the server host.

mysqlhotcopy performs only local backups: It connects to the server to lock it against data modifications and then copies local table files.

SELECT ... INTO OUTFILE can be initiated from a local or remote client host, but the output file is created on the server host.

Physical backup methods typically are initiated locally on the MySQL server host so that the server can be taken offline, although the destination for copied files might be remote.