· Metadata（元数据）：所有数据库表的名称和定义。
· Table records（表记录）：执行备份时实际保存在数据库表中的数据。
· Transaction log（事务日志）：指明如何以及何时将数据保存在数据库中的连续记录。
每一部分均会保存在参与备份的所有节点上。在备份过程中 ，每个节点均会将这三个部分保存在磁盘上的三个文件中：
· BACKUP-backup_id.node_id.ctl
包含控制信息和元数据的控制文件。每个节点均会将相同的表定义（对于簇中的所有表）保存在自己的该文件中。
· BACKUP-backup_id-0.node_id.data
包含表记录的数据文件，它是按片段保存的，也就是说，在备份过程中，不同的节点会保存不同的片段。每个节点保存的文件以指明了记录所属表的标题开始。在记录清单后面有一个包含关于所有记录校验和的脚注。
· BACKUP-backup_id.node_id.log
包含已提交事务的记录的日志文件。在日志中，仅保存已在备份中保存的表上的事务。参与备份的节点将保存不同的记录，这是因为，不同的节点容纳了不同的数据库片段。
在上面所列的内容中，backup_id指的是备份ID，node_id是创建文件的节点的唯一ID。
开始备份前，请确保已为备份操作恰当地配置了簇。（请参见17.6.5.4节，“簇备份的配置”）。
使用管理服务器创建备份包含以下步骤：
1. 启动管理服务器(ndb_mgm)。
2. 执行命令START BACKUP。
3. 管理服务器将用消息“指示备份开始”作出应答。这意味着管理服务器将请求提交给了簇，但尚未收到任何回应。
4. 管理服务器回复“备份backup_id开始”，其中，backup_id是该备份的唯一ID（如果未作其他配置，该ID还将保存在簇日志中）。这意味着簇已收到并开始处理备份请求。它不表示备份已完成。
5. 管理服务器发出消息“备份backup_id完成”，通知备份操作已结束。
要想放弃正在处理的备份：
1. 启动管理服务器。
2. 执行命令ABORT BACKUP backup_id。backup_id是当备份开始时包含在管理服务器应大中的备份ID（在消息“备份backup_id启动”中）。
3. 管理服务器用消息“放弃指示的备份backup_id”确认放弃请求，注意，尚未收到对该请求的实际回应。
4. 一旦放弃了备份，管理服务器将通报“备份backup_id因XYZ而放弃”。这意味着簇中止了备份，并从簇文件系统中删除了与该备份有关的所有文件。
在系统shell中使用下述命令，也能放弃正在执行的备份：
shell> ndb_mgm -e "ABORT BACKUP backup_id"
注释：执行放弃操作时，如果没有ID为backup_id的备份，管理服务器不会给出任何明确回应。但是，所发出的无效放弃命令将在簇日志中给出。
簇恢复程序是作为单独的命令行实用工具ndb_restore实现的，它将读取由备份创建的文件，并将保存的信息插入数据库。必须为每组备份文件执行恢复程序，也就是说，执行次数与创建备份时运行的数据库节点数相同。
首次执行恢复程序时，还需要恢复元数据。换句话讲，必须重新创建数据库表（注意，开始执行恢复操作时，簇中应有一个空数据库）。恢复程序对于簇来说相当于API，因此，需要一个空闲连接，以便与簇相连。可使用ndb_mgm命令SHOW（在系统shell下使用ndb_mgm
-e SHOW即可完成该操作）进行验证。可以使用开关“-c
connectstring”来确定MGM节点的位置。（关于连接字符串的更多信息，请参见17.4.4.2节，“MySQL簇连接字符串”。备份文件必须位于恢复程序参量给定的目录下。
能够使用与创建是所用配置不同的配置将备份恢复到数据库。例如，对于备份ID为12的备份，该备份是在具有两个数据库节点（节点ID无恶2和3）的簇中创建的，可以将其恢复到具有4个节点的簇中。这样，ndb_restore必须运行两次，为创建备份时的每个数据库节点运行一次。
注释：对于快速恢复，能够以并行方式恢复数据，但必须有足够的可用簇连接。然而，数据文件必须始终前于日志文件。
有4个用于备份的基本配置参数：
· BackupDataBufferSize
将数据写入磁盘之前用于对数据进行缓冲处理的内存量。
· BackupLogBufferSize
将日志记录写入磁盘之前用于对其进行缓冲处理的内存量。
· BackupMemory
在数据库节点中为备份分配的总内存。它应是分配给备份数据缓冲的内存和分配给备份日志缓冲的内存之和。
· BackupWriteSize
写入磁盘的块大小。它适用于备份数据缓冲和备份日志缓冲
关于这些参数的更多细节，请参见17.4节，“MySQL簇的配置”。
NDB不支持重复的读取操作，对于恢复进程，这类操作会导致问题。尽管备份进程“hot”，但从备份恢复MySQL簇并不是100％“hot”的进程。其原因在于，在恢复进程执行期间，正在运行的事务会从已恢复的数据中获取不可重复的读。这意味着，当恢复正在进行时，数据的状态是不一致的。