1.完整备份

要创建备份，请使用 xtrabackup —backup 选项运行xtrabackup。您还需要指定 xtrabackup —target-dir选项，如果InnoDB数据或日志文件未存储在同一目录中，则将在该位置存储备份。 如果目标目录不存在，则xtrabackup会创建它。 如果该目录确实存在并且为空，则xtrabackup将成功。 xtrabackup不会覆盖现有文件，它将失败，并显示操作系统错误17，file exists.

要启动备份过程，请运行：

  1. xtrabackup --backup --target-dir=/data/backups/
  2. #或 指定host地址、用户名以及密码
  3. xtrabackup --host=127.0.0.1 --user=root --password=123456 --backup --target-dir=/home/data/backups/full/

这会将备份存储在 /data/backups/. 中。 如果指定相对路径，则目标目录将相对于当前目录。

在备份过程中，您应该看到很多输出，显示正在复制的数据文件，以及日志文件线程反复扫描日志文件并从中复制。 这是一个示例，该示例显示了日志线程在后台扫描日志，以及在ibdata1文件上工作的文件复制线程：

  1. 160906 10:19:17 Finished backing up non-InnoDB tables and files
  2. 160906 10:19:17 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
  3. xtrabackup: The latest check point (for incremental): '62988944'
  4. xtrabackup: Stopping log copying thread.
  5. .160906 10:19:18 >> log scanned up to (137343534)
  6. 160906 10:19:18 Executing UNLOCK TABLES
  7. 160906 10:19:18 All tables unlocked
  8. 160906 10:19:18 Backup created in directory '/data/backups/'
  9. 160906 10:19:18 [00] Writing backup-my.cnf
  10. 160906 10:19:18 [00]        ...done
  11. 160906 10:19:18 [00] Writing xtrabackup_info
  12. 160906 10:19:18 [00]        ...done
  13. xtrabackup: Transaction log of lsn (26970807) to (137343534) was copied.
  14. 160906 10:19:18 completed OK!

您应该看到的最后一件事类似于以下内容，其中 的值将是一个取决于您的系统的数字：

  1. xtrabackup: Transaction log of lsn (<SLN>) to (<LSN>) was copied.

日志复制线程每秒检查一次事务日志，以查看是否有任何新的日志记录需要复制，但是日志复制线程有可能无法跟上要写入的日志数量。 事务性日志，当日志记录被覆盖而无法读取时，将报错。

备份完成后，假设您只有一个InnoDB表test.tbl1 ，并且使用的是MySQL的 innodb_file_per_table选项，则目标目录将包含如下文件：

  1. ls -lh /data/backups/
  2. #显示如下内容
  3. total 182M
  4. drwx------  7 root root 4.0K Sep  6 10:19 .
  5. drwxrwxrwt 11 root root 4.0K Sep  6 11:05 ..
  6. -rw-r-----  1 root root  387 Sep  6 10:19 backup-my.cnf
  7. -rw-r-----  1 root root  76M Sep  6 10:19 ibdata1
  8. drwx------  2 root root 4.0K Sep  6 10:19 mysql
  9. drwx------  2 root root 4.0K Sep  6 10:19 performance_schema
  10. drwx------  2 root root 4.0K Sep  6 10:19 sbtest
  11. drwx------  2 root root 4.0K Sep  6 10:19 test
  12. drwx------  2 root root 4.0K Sep  6 10:19 world2
  13. -rw-r-----  1 root root  116 Sep  6 10:19 xtrabackup_checkpoints
  14. -rw-r-----  1 root root  433 Sep  6 10:19 xtrabackup_info
  15. -rw-r-----  1 root root 106M Sep  6 10:19 xtrabackup_logfile

备份可能需要很长时间，具体取决于数据库的大小。 可以随时取消，因为它不会修改数据库。

下一步是准备好还原您的备份。

准备备份

使用 xtrabackup —backup 选项进行备份后，首先需要准备好备份才能还原。 在准备好数据文件之前，它们在时间点上是不一致的，因为它们是在程序运行时在不同的时间复制的，并且在此过程中它们可能已被更改。 如果您尝试使用这些数据文件启动InnoDB，它将检测到损坏并自身崩溃，以防止您在损坏的数据上运行。 xtrabackup —prepare步骤可以使文件在单个时刻完美地保持一致，因此您可以在文件上运行InnoDB。

您可以在任何计算机上运行prepare操作； 它不必位于原始服务器上或要还原到的服务器上。 您可以将备份复制到实用程序服务器并在那里准备。

您可以准备使用较旧的Percona XtraBackup版本和较新版本创建的备份，反之则不然。 应该使用支持该服务器版本的最新Percona XtraBackup版本在不支持的服务器版本上准备备份。 例如，如果具有使用Percona XtraBackup 1.6创建的MySQL 5.0的备份，则不支持使用Percona XtraBackup 2.3进行备份的准备，因为在Percona XtraBackup 2.1中已删除了对MySQL 5.0的支持。 而是应使用2.0系列中的最新版本。

在prepare操作过程中，xtrabackup会启动一种嵌入其中的经过修改的InnoDB（与之链接的库）。 必须进行修改才能禁用InnoDB的标准安全检查，例如抱怨日志文件的大小不合适，这不适用于备份。 这些修改仅适用于xtrabackup二进制文件； 您不需要修改的InnoDB即可使用xtrabackup进行备份。

准备步骤使用此嵌入式InnoDB使用复制的日志文件对复制的数据文件执行崩溃恢复。 prepare 步骤的使用非常简单：您只需运行 xtrabackup —prepare 选项并告诉它要准备的目录，例如，准备先前进行的备份运行：

  1. xtrabackup --prepare --target-dir=/data/backups/

完成此操作后，您应该看到 InnoDB shutdown ，并显示以下消息，其中 LSN 的值将再次取决于您的系统：

  1. InnoDB: Shutdown completed; log sequence number 137345046
  2. 160906 11:21:01 completed OK!

以下所有准备工作都不会更改已经准备好的数据文件，您将看到输出显示：

  1. xtrabackup: This target seems to be already prepared.
  2. xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.

不建议在准备备份时中断xtrabackup过程，因为这可能会导致数据文件损坏并且备份将变得不可用。 如果准备过程中断，则不能保证备份的有效性。

如果打算将备份作为进一步增量备份的基础，则在准备备份时应使用 xtrabackup —apply-log-only选项，否则将无法对其应用增量备份。 有关更多详细信息，请参见有关准备增量备份的文档。

恢复备份

必须先准备好备份，然后才能还原它。

为了方便起见，xtrabackup二进制文件具有 xtrabackup —copy-back 选项，该选项会将备份复制到服务器的datadir中：

  1. xtrabackup --copy-back --target-dir=/data/backups/

如果您不想保存备份，则可以使用 xtrabackup —move-back 选项，该选项会将备份的数据移至datadir。

如果您不想使用以上任何选项，则可以另外使用rsync或cp来还原文件。

恢复备份之前， datadir 必须为空。 同样需要注意的是，必须先关闭MySQL服务器，然后才能执行还原操作。 您无法还原到正在运行的mysqld实例的 datadir （导入部分备份时除外）。

可用于还原备份的rsync命令示例如下所示：

  1. rsync -avrP /data/backup/ /var/lib/mysql/

您应该检查恢复的文件是否具有正确的所有权和权限。

由于将保留文件的属性，因此在大多数情况下，在启动数据库服务器之前，您需要将文件的所有权更改为mysql，因为它们将由创建备份的用户拥有：

  1. chown -R mysql:mysql /var/lib/mysql

现在，数据已还原，您可以启动服务器。

2.增量备份

xtrabackup和innobackupex工具都支持增量备份，这意味着它们只能复制自上次备份以来已更改的数据。

您可以在每个完整备份之间执行许多增量备份，因此您可以设置一个备份过程，例如每周一次完整备份和每天增量备份，或者每天完整备份和每小时增量备份。

增量备份之所以有效，是因为每个InnoDB页面都包含一个日志序列号或 LSN.。 LSN.是整个数据库的系统版本号。 每个页面的 LSN.都显示了最近的更改时间。

增量备份将复制其 LSN 比先前的增量或完整备份的 LSN 更新的每个页面。 有两种算法用于查找要复制的此类页面集。 第一个可用于所有服务器类型和版本的服务器是通过读取所有数据页直接检查 LSN 页。 Percona Server for MySQL中提供的第二个功能是启用服务器上已更改的页面跟踪功能，该功能将在更改页面时记录下来。 然后将这些信息写在一个紧凑的单独的所谓的位图文件中。 xtrabackup二进制文件将使用该文件来读取增量备份所需的数据页，从而可能保存许多读取请求。 如果xtrabackup二进制文件找到了位图文件，则默认情况下启用后一种算法。 即使位图数据可用，也可以指定 xtrabackup —incremental-force-scan 读取所有页面。

重要的

增量备份实际上不会将数据文件与先前备份的数据文件进行比较。 因此，在部分备份之后运行增量备份可能会导致数据不一致。

增量备份只需阅读页面，然后将其 LSN.与上次备份的 LSN.进行比较即可。 但是，您仍然需要完整备份来恢复增量更改。 没有完整的备份作为基础，增量备份将毫无用处。

如果您知道它的 LSN.，则可以使用 —incremental-lsn 选项执行增量备份，而无需进行以前的备份。

创建增量备份

要进行增量备份，请像往常一样从完整备份开始。 xtrabackup二进制文件将名为 xtrabackup_checkpoints 的文件写入备份的目标目录。 该文件包含一行显示 to_lsn 的行，该行是备份结束时数据库的LSN 。 使用以下命令创建完整备份：

  1. xtrabackup --backup --target-dir=/data/backups/base

如果查看 xtrabackup_checkpoints 文件，则应根据您的LSN nuber看到类似的内容：

  1. backup_type = full-backuped
  2. from_lsn = 0
  3. to_lsn = 1626007
  4. last_lsn = 1626007
  5. compact = 0
  6. recover_binlog_info = 1

现在您已拥有完整备份，您可以基于它进行增量备份。 使用以下命令：

  1. xtrabackup --backup --target-dir=/data/backups/inc1 \
  2. --incremental-basedir=/data/backups/base

/data/backups/inc1/ 目录现在应该包含增量文件，例如 ibdata1.delta 和 test/table1.ibd.delta。 这些代表自 LSN 1626007.以来的更改。如果检查此目录中的 xtrabackup_checkpoints 文件，则应该看到与以下内容相似的内容：

  1. backup_type = incremental
  2. from_lsn = 1626007
  3. to_lsn = 4124244
  4. last_lsn = 4124244
  5. compact = 0
  6. recover_binlog_info = 1

from_lsn 是备份的起始LSN，对于增量备份，它必须与先前/基本备份的 to_lsn （如果它是最后一个检查点）相同。

现在可以将此目录用作另一个增量备份的基础：

  1. xtrabackup --backup --target-dir=/data/backups/inc2 \
  2. --incremental-basedir=/data/backups/inc1

此文件夹还包含 xtrabackup_checkpoints:

  1. backup_type = incremental
  2. from_lsn = 4124244
  3. to_lsn = 6938371
  4. last_lsn = 7110572
  5. compact = 0
  6. recover_binlog_info = 1

在这种情况下，您可以看到to_lsn （最后一个检查点LSN）和last_lsn （最后一个复制的LSN）之间存在差异，这意味着在备份过程中服务器上有一些流量。

准备增量备份

增量备份的xtrabackup —prepare步骤与完全备份不同。 在完全备份中，执行两种类型的操作以使数据库保持一致：已提交的事务相对于数据文件从日志文件中重放，未提交的事务被回滚。 在准备增量备份时，您必须跳过未提交事务的回滚，因为在备份时未提交的事务可能正在进行中，并且很可能会在下一次增量备份中提交。 您应该使用 xtrabackup —apply-log-only 选项来防止回滚阶段。

⚠警告
如果不使用xtrabackup —apply-log-only选项来防止回滚阶段，则增量备份将无用。 事务回滚后，无法再应用增量备份。

从您创建的完整备份开始，您可以准备它，然后将增量差异应用于它。回想一下，您有以下备份：

  1. /data/backups/base
  2. /data/backups/inc1
  3. /data/backups/inc2

要准备基本备份，您需要像往常一样运行 xtrabackup —prepare ，但是要防止回滚阶段：

  1. xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base

输出应以类似于以下内容的文本结尾：

  1. InnoDB: Shutdown completed; log sequence number 1626007
  2. 161011 12:41:04 completed OK!

日志序列号应与您先前看到的基本备份的 to_lsn 相匹配。

即使已跳过回滚阶段，此备份实际上现在也可以安全地按原样还原。 如果还原它并启动MySQL，InnoDB将检测到未执行回滚阶段，它将在后台执行该操作，就像启动时进行崩溃恢复一样。 它将通知您数据库未正常关闭。

要将第一个增量备份应用于完整备份，请运行以下命令：

  1. xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \
  2. --incremental-dir=/data/backups/inc1

这会将增量文件应用于 /data/backups/base中的文件，这会将它们及时向前滚动到增量备份的时间。 然后，它像往常一样将重做日志应用于结果。 最终数据位于 /data/backups/base 中，而不位于增量目录中。 您应该看到类似于以下内容的输出：

  1. incremental backup from 1626007 is enabled.
  2. xtrabackup: cd to /data/backups/base
  3. xtrabackup: This target seems to be already prepared with --apply-log-only.
  4. xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(4124244)
  5. ...
  6. xtrabackup: page size for /tmp/backups/inc1/ibdata1.delta is 16384 bytes
  7. Applying /tmp/backups/inc1/ibdata1.delta to ./ibdata1...
  8. ...
  9. 161011 12:45:56 completed OK!

同样， LSN 应该与您先前对第一个增量备份的检查中看到的相符。 如果从 /data/backups/base还原文件，则应该在第一次增量备份时看到数据库的状态。

⚠警告
PXB不支持使用相同的增量备份目录来准备备份的两个副本。 不要使用相同的增量备份目录（–incremental-dir的值）多次运行 xtrabackup —prepare 。

准备第二个增量备份是一个类似的过程：将增量应用到（已修改的）基本备份，您将及时将其数据前滚到第二个增量备份的点：

  1. xtrabackup --prepare --target-dir=/data/backups/base \
  2. --incremental-dir=/data/backups/inc2

合并除最后一个以外的所有增量时，应使用xtrabackup —apply-log-only 。 这就是为什么上一行不包含xtrabackup —apply-log-only选项的原因。 即使在最后一步使用了xtrabackup —apply-log-only，备份仍将保持一致，但在这种情况下，服务器将执行回滚阶段。

一旦准备好，增量备份就与完整备份相同，并且可以用相同的方式还原它们。

3.部分备份

启用innodb_file_per_table选项时，xtrabackup支持进行部分备份。有三种创建部分备份的方法：

  1. 将表名称与正则表达式匹配
  2. 在文件中提供表名列表
  3. 提供数据库列表

⚠警告
如果在备份过程中删除了任何匹配或列出的表，则xtrabackup将失败。
不要复制回准备好的备份。还原部分备份应通过导入表而不是使用该—copy-back选项来完成。不建议在运行部分备份之后运行增量备份。
尽管在某些情况下可以通过复制回文件来完成还原，但这在许多情况下可能导致数据库不一致，因此不建议这样做。

就本手册页而言，我们假设有一个名为test的数据库，其中包含名为t1和t2的表。

使用xtrabackup—tables

第一种方法涉及xtrabackup—tables选项。 该选项的值是一个正则表达式，它与标准的表名（包括数据库名）匹配，格式为databasename.tablename.

要仅备份test数据库中的表，可以使用以下命令：

  1. xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/ --tables="^test[.].*"

要仅备份表test.t1，可以使用以下命令：

  1. xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/ --tables="^test[.]t1"

使用xtrabackup—tables-file

xtrabackup—tables-file指定一个文件，该文件可以包含多个表名，文件中每行一个表名。 仅备份文件中命名的表。 名称完全匹配，区分大小写，没有模式或正则表达式匹配。 表名必须完全合格，格式为databasename.tablename。

  1. echo "mydatabase.mytable" > /tmp/tables.txt
  2. xtrabackup --backup --tables-file=/tmp/tables.txt

使用xtrabackup—databases和xtrabackup—databases-file

xtrabackup—databases接受以空格分隔的数据库和表列表，以格式databasename[.tablename].进行备份。 除了此列表之外，请确保指定mysql,sys, 和performance_schema数据库。 使用xtrabackup—copy-back.还原数据库时，这些数据库是必需的。

如果在准备步骤中处理的表是在备份开始后创建的，则即使未在参数中明确列出这些表，也可以将它们添加到备份中。

  1. xtrabackup --databases='mysql sys performance_schema ...'

例如：

  1. xtrabackup --user=root --password=123456 --backup --databases='mysql sys performance_schema ngcc_db' --target-dir=/home/data/backups/partial/database/

xtrabackup —databases-file指定一个文件，该文件可以以databasename[.tablename]格式包含多个数据库和表，该文件中每行一个元素名称。 名称完全匹配，区分大小写，没有模式或正则表达式匹配。

如果在准备步骤中处理的表是在备份开始后创建的，则即使未在参数中明确列出这些表，也可以将它们添加到备份中。

准备备份

在部分备份上使用xtrabackup —prepare选项时，将看到有关不存在的表的警告。 这是因为这些表存在于InnoDB的数据字典中，但是不存在相应的.ibd文件。 它们没有被复制到备份目录中。 这些表将从数据字典中删除，并且当您还原备份并启动InnoDB时，它们将不再存在并且不会导致任何错误或警告被打印到日志文件。

您将在准备阶段看到错误消息的示例。

  1. InnoDB: Reading tablespace information from the .ibd files...
  2. 101107 22:31:30  InnoDB: Error: table 'test1/t'
  3. InnoDB: in InnoDB data dictionary has tablespace id 6,
  4. InnoDB: but tablespace with that id or name does not exist. It will be removed from data dictionary.