1.1. 物理备份方法
1.1.1. InnoDB 物理冷备份
备份过程：
a) 在复制操作期间停止服务器。
b) 验证服务器是否正常关闭，没有出错。
c) 生成每个组件的副本：
— 每个 InnoDB 表一个 .frm 文件
— 表空间文件：系统表空间、基于每个表的表空间
— InnoDB 日志文件
— my.cnf 文件
d) 重新启动服务器。
进行完整 InnoDB 备份（所有 InnoDB 表的备份）的物理备份操作基于生成 InnoDB 用于管理表空间的所有文件的完整副本。所有数据库中的所有 InnoDB 表必须一起备份，因为 InnoDB 会在系统表空间中集中维护某些信息。
要使用物理备份恢复 InnoDB 表，请停止服务器，替换其副本在备份过程中生成的所有组件，然后重新启动服务器。
注：必须将表空间文件作为一个组进行复制。也就是说，需要替换服务器上的所有现存的表空间文件。不能使用物理备份将一个表空间添加到另一个表空间。
1.1.2. MyISAM 和 ARCHIVE 物理备份
备份过程：
a) 在服务器运行期间，锁定要复制的表：
mysql> USE mysql
mysql> FLUSH TABLES users WITH READ LOCK;
要生成 MyISAM 或 ARCHIVE 表，需复制 MySQL 用于代表该表的文件。对于 MyISAM ，这些文件是 .frm 、 .MYD 和 .MYI 文件。对于 ARCHIVE 表，这些文件是 .frm 和 .ARZ 文件。在此复制操作过程中，其他程序（包括服务器）不能使用该表。为了避免服务器交互问题，要在复制操作过程中停止服务器。
注：锁定表而不关闭服务器的做法在 Linux 系统上有效。在 Windows 上，文件锁定行为会导致可能无法复制被服务器锁定的表的表文件。在这种情况下，需要停止服务器后再复制表文件。
b) 执行文件系统复制。
c) 启动新的二进制日志文件： FLUSH LOGS;
要启动新的二进制日志文件，可使用 FLUSH LOGS （在 UNLOCK TABLES 之前）。或者， SHOW MASTER STATUS 返回当前二进制日志文件的名称和位置。新二进制日志文件包含在备份之后更改了数据的所有语句（以及所有后续的二进制日志文件）。
d) 在文件系统复制后解除锁定： UNLOCK TABLES;
要从物理备份中恢复 MyISAM 或 ARCHIVE 表，应停止服务器，将备份表文件复制到相应的数据库目录中，然后重新启动服务器。
1.1.3. 使用 LVM 快照备份
在以下情况下，使用 LVM 快照执行物理备份：
l 主机支持 LVM ；例如， Linux 支持 LVM2 ；
l 包含 MySQL 数据目录的文件系统在逻辑卷上；
备份过程：
a) 生成包含 MySQL 数据目录的逻辑卷的快照。在备份非 InnoDB 表时，使用 FLUSH TABLES WITH READ LOCK 。
b) 从快照执行物理备份。
c) 删除快照。
在支持 LVM 的系统（如 Linux ）上，可以创建要包含 MySQL 数据目录的逻辑卷。可以创建该卷的快照，该快照的行为就像是逻辑卷的即时副本。 LVM 使用称为“写入时复制” (copy-on-write) 的机制创建最初不含数据的快照。在从新创建的快照读取文件时， LVM 会从原始卷读取这些文件。当原始卷发生变化时， LVM 会在原始卷上的数据发生变化之前，立即将其复制到快照，因此，在生成快照以来发生变化的任何数据都以其原始形式存储在快照中。这样做的结果是，当从快照读取文件时，将获得在创建快照时存在的数据版本。因为快照几乎是即时的，因此可以假定在生成快照过程中底层数据没有发生任何变化。这使得快照对于在不关闭服务器的情况下备份 InnoDB 数据库非常有用。要创建快照，可使用以下语法：
lvcreate -s -n <snapshot-name> -L <size> <original-volume>
选项 -s 指示 lvcreate 创建快照，其他选项指定新快照的名称和大小以及原始卷的位置。
例如，假定有一个卷组 VG_MYSQL 和一个逻辑卷 lv_datadir ：
lvcreate -s -n lv_datadirbackup -L 2G /dev/VG_MYSQL/lv_datadir
前一条语句创建快照 lv_datadirbackup ，其保留大小为 2 GB 。如果只是短时间需要该快照，则保留大小可以比原始卷的大小少很多，因为快照的存储仅包含在原始卷中发生更改的数据块。例如，如果要使用快照执行备份，则保留大小仅存储在执行备份以及删除快照的时间内所做的更改。
可以像挂载标准卷一样挂载快照。挂载了快照后，就像处理其他任何物理备份一样，从该卷执行物理备份（例如，通过使用 tar 或 cp ）。从快照备份时，数据库在备份过程中不能有更改。您肯定会获得与备份时一样的一致数据文件版本，无需停止服务器。随着时间的推移，快照的空间要求通常会增长到原始卷的大小。此外，对原始卷上数据块的每项初始数据更改将导致两次向卷组写入数据：请求的更改和对快照的写入时复制。这可能会影响快照保留期间的性能。由于以上原因，应在执行了备份之后尽快删除快照。要删除由前一条语句创建的快照，可使用以下语句：
lvremove VG_MYSQL/lv_datadirbackup
1.1.4. 物理备份的可移植性
l 可在 MySQL 服务器之间复制二进制数据库。当将一台计算机上生成的二进制备份拿到具有不同体系结构的另一台计算机上时，二进制可移植性会很有用。例如，使用二进制备份是将数据库在 MySQL 服务器之间复制数据库的一种方法。
l InnoDB 数据库的所有表空间和日志文件都可直接复制。源系统与目标系统上的数据库目录名称必须相同。对于 InnoDB ，利用二进制可移植性可在不同计算机上的不同 MySQL 服务器之间直接复制表空间，其他 MySQL 服务器可以访问该表空间。
l MyISAM 、 ARCHIVE ，单个表的所有文件都可直接复制。对于 MyISAM 和 ARCHIVE ，二进制可移植性意味着可在不同计算机上的 MySQL 服务器之间直接复制 MyISAM 或 ARCHIVE 表的文件，其他 MySQL 服务器可以访问该表。
l Windows 兼容性，在 Windows 系统上， MySQL 服务器在内部存储小写的数据库和表名称。对于区分大小写的文件系统，可使用选项文件语句：
lower_case_table_names=1
1.2. 备份日志和状态文件
Ø 二进制日志文件存储备份完成后所做的更新；
Ø 服务器使用的选项文件（ my.cnf 和 my.ini 文件）包含在系统崩溃后必须恢复的配置信息。
Ø 复制文件：复制 slave 创建一个包含连接到 master 所需信息的 master.info 文件，以及一个指示当前的中继日志处理进度的 relay-log.info 文件。
Ø 复制 slave 数据文件：复制 slave 创建用于处理 LOAD DATA INFILE 语句的数据文件。这些文件位于 slave_load_tmpdir 系统变量指定的目录中，在服务器启动时使用 --slave-load-tmpdir 选项可设置该变量。如果不设置 slave_load_tmpdir ，则应用 tmpdir 系统变量的值。要保护复制 slave 数据，需要备份以 SQL_LOAD- 开头的文件。
Ø MySQL 二进制文件和库
Ø 策略：
— 静态文件：使用常规系统工具在服务器运行的情况下备份
— 动态文件：使用常规系统工具在服务器停止的情况下备份
1.3. 将复制用作备份的辅助工具
Ø master 可以继续运行。
如果 MySQL 服务器在复制设置中用作 master ，则可使用 slave 生成备份，而不备份 master 。通过使用 slave 进行备份， master 不会被中断，备份过程不会对 master 增加处理负荷，也不要求增加硬盘空间或进行额外处理。
Ø 可以停止 slave 以生成备份
关闭 mysqld 进程，或者发出 STOP SLAVE SQL_THREAD 语句以停止服务器处理其从 master 收到的更新。在后一种情况下，必须刷新表以强制挂起对磁盘的更改。
Ø 备份 slave 的数据库
生成 slave 数据库的备份。可用的方法取决于服务器处于停止状态还是仍在运行。例如，如果服务器已停止，则不能使用连接到服务器的 mysqldump 或 mysqlhotcopy 之类的工具。停止的服务器可以使用系统工具； slave 线程停止，但仍在运行的服务器可以使用任何 MySQL 工具。
Ø 启动服务器：启动停止的服务器、 START SLAVE SQL_THREAD
重新启动停止的服务器。如果服务器仍在运行，则可通过发出 START SLAVE SQL_THREAD 语句重新启动 SQL 线程。
郑州不孕不育医院×××:http://wapyyk.39.net/zz3/zonghe/1d427.html
1.4. 备份方法比较
快照 ：并非所有引擎都以相同方式处理快照。例如， InnoDB 表不需要 FLUSH TABLES WITH READ LOCK 就能启动快照，但 MyISAM 表却需要。1.5. 备份策略
流程图表示可用于确定备份策略的决策流程。可能在此流程中提出的问题包括：
n 我们的系统能否承受长时间停机（停机时间）？
n 有多少数据要备份？
n 使用哪些存储引擎来存储数据（ InnoDB 、 MyISAM 或两者）？
1.6. mysqlbinlog
a) 确定在备份生成后写入哪些日志
在恢复了二进制备份文件或重新装入了文本备份文件后，通过重新处理在服务器的二进制日志中记录的数据更改，完成恢复操作。为此，必须确定在生成备份后写入哪些日志。然后，需要使用 mysqlbinlog 程序将这些二进制日志的内容转换成文本 SQL 语句，以便使用 mysql 处理结果语句。
b) 使用 mysqlbinlog 一个命令处理所有 binlog
mysqlbinlog bin.000050 bin.000051 bin.000052 | mysql
c) 恢复部分 Binlog
--start-datetime / --stop-datetime
--start-position / --stop-position
mysqlbinlog --start-position=23456 binlog.000004 | mysql
如果指定的二进制日志文件在备份过程中正在写入，则必须从中仅提取在备份后写入的分，再加上之后写入的所有日志文件。此外，如果意外删除了表或数据库（或者发生了他数据损坏情况），则可使用二进制日志中记录的增量活动恢复备份。为了避免重复执行问题语句，可以通过获取到该点之前的二进制日志文件，运行问题语句之前的所有语句。为了处理部分文件提取， mysqlbinlog 支持一些允许指定时间的选项，或者允许指定日志中开始提取日志内容的位置的选项：
--start-datetime 选项：指定开始提取的日期和时间，其中选项参数采用 DATETIME 格式。但是 --start-datetime 的粒度仅有一秒，因此可能不够精确，不能指定开始的确切位置。
--start-position 选项：可用于指定在给定的日志位置开始提取。
另外还有一些对应的 --stop-datetime 和 --stop-position 选项，用于指定停止提取日志内容的位置。
如果您不确定日志文件中对应于处理开始点的时间戳或位置，可使用 mysqlbinlog （不带 mysql ）显示日志内容进行检查：
shell> mysqlbinlog file_name | more