SQL 转储方法的思想是创建一个由SQL命令组成的文件，当把这个文件回馈给服务器时，服务器将利用其中的SQL命令重建与转储时状态一样的数据库。 LightDB为此提供了工具lt_dump。这个工具的基本用法是：
lt_dumpdbname>dumpfile
正如你所见，lt_dump把结果输出到标准输出。我们后面将看到这样做有什么用处。 尽管上述命令会创建一个文本文件，lt_dump可以用其他格式创建文件以支持并行 和细粒度的对象恢复控制。
lt_dump是一个普通的LightDB客户端应用（尽管是个
相当聪明的东西）。这就意味着你可以在任何可以访问该数据库的远端主机上进行备份工作。但是请记住
lt_dump不会以任何特殊权限运行。具体说来，就是它必须要有你想备份的表的读
权限，因此为了备份整个数据库你几乎总是必须以一个数据库超级用户来运行它（如果你没有足够的特权
来备份整个数据库，你仍然可以使用诸如-n
或schema-t 选项来备份该数据库中你能够
访问的部分）。
table
要声明lt_dump连接哪个数据库服务器，使用命令行选项-h和 host-p 。 默认主机是本地主机或你的portLTHOST环境变量指定的主机。 类似地，默认端口是环境变量LTPORT或（如果LTPORT不存在）内建的默认值。 （服务器通常有相同的默认值，所以还算方便。）
和任何其他LightDB客户端应用一样， lt_dump默认使用与当前操作系统用户名同名的数据库用户名进行连接。 要使用其他名字，要么声明-U选项，要么设置环境变量LTUSER。请注意lt_dump的连接也要通过客户认证机制（在Chapter 19里描述）。
lt_dump对于其他备份方法的一个重要优势是，lt_dump的输出可以很容易地在新版本的LightDB中载入，而文件级备份和连续归档都是极度的服务器版本限定的。lt_dump也是唯一可以将一个数据库传送到一个不同机器架构上的方法，例如从一个32位服务器到一个64位服务器。
由lt_dump创建的备份在内部是一致的， 也就是说，转储表现了lt_dump开始运行时刻的数据库快照，且在lt_dump运行过程中发生的更新将不会被转储。lt_dump工作的时候并不阻塞其他的对数据库的操作。 （但是会阻塞那些需要排它锁的操作，比如大部分形式的ALTER TABLE）
lt_dump生成的文本文件可以由ltsql程序读取。 从转储中恢复的常用命令是：
ltsqldbname<dumpfile
其中dumpfile就是lt_dump命令的输出文件。这条命令不会创建数据库dbname，你必须在执行ltsql前自己从template0创建（例如，用命令createdb -T template0 ）。ltsql支持类似lt_dump的选项用以指定要连接的数据库服务器和要使用的用户名。参阅ltsql的手册获取更多信息。
非文本文件转储可以使用lt_restore工具来恢复。
dbname
在开始恢复之前，转储库中对象的拥有者以及在其上被授予了权限的用户必须已经存在。如果它们不存在，那么恢复过程将无法将对象创建成具有原来的所属关系以及权限（有时候这就是你所需要的，但通常不是）。
默认情况下，ltsql脚本在遇到一个SQL错误后会继续执行。你也许希望在遇到一个SQL错误后让ltsql退出，那么可以设置ON_ERROR_STOP变量来运行ltsql，这将使ltsql在遇到SQL错误后退出并返回状态3：
ltsql --set ON_ERROR_STOP=ondbname<dumpfile
不管怎样，你将只能得到一个部分恢复的数据库。作为另一种选择，你可以指定让整个恢复作为一个单独的事务运行，这样恢复要么完全完成要么完全回滚。这种模式可以通过向ltsql传递-1或--single-transaction命令行选项来指定。在使用这种模式时，注意即使是很小的一个错误也会导致运行了数小时的恢复被回滚。但是，这仍然比在一个部分恢复后手工清理复杂的数据库要更好。
lt_dump和ltsql读写管道的能力使得直接从一个服务器转储一个数据库到另一个服务器成为可能，例如：
lt_dump -hhost1dbname| ltsql -hhost2dbname
lt_dump产生的转储是相对于template0。这意味着在template1中加入的任何语言、过程等都会被lt_dump转储。结果是，如果在恢复时使用的是一个自定义的template1，你必须从template0创建一个空的数据库，正如上面的例子所示。
一旦完成恢复，在每个数据库上运行ANALYZE是明智的举动，这样优化器就有有用的统计数据了，更多信息参见Section 23.1.3和Section 23.1.6。更多关于如何有效地向LightDB里装载大量数据的建议， 请参考Section 15.4。
lt_dump每次只转储一个数据库，而且它不会转储关于角色或表空间（因为它们是实例范围的）的信息。为了支持方便地转储一个数据库实例的全部内容，提供了lt_dumpall程序。lt_dumpall备份一个给定实例中的每一个数据库，并且也保留了实例范围的数据，如角色和表空间定义。该命令的基本用法是：
lt_dumpall > dumpfile
转储的结果可以使用ltsql恢复：
ltsql -f dumpfile postgres
（实际上，你可以指定恢复到任何已有数据库名，但是如果你正在将转储载入到一个空实例中则通常要用（postgres）。在恢复一个lt_dumpall转储时常常需要具有数据库超级用户访问权限，因为它需要恢复角色和表空间信息。如果你在使用表空间，请确保转储中的表空间路径适合于新的安装。
lt_dumpall工作时会发出命令重新创建角色、表空间和空数据库，接着为每一个数据库lt_dump。这意味着每个数据库自身是一致的，但是不同数据库的快照并不同步。
实例范围的数据可以使用lt_dumpall的--globals-only选项来单独转储。如果在单个数据库上运行lt_dump命令，上述做法对于完全备份整个实例是必需的。
在一些具有最大文件尺寸限制的操作系统上创建大型的lt_dump输出文件可能会出现问题。幸运地是，lt_dump可以写出到标准输出，因此你可以使用标准Unix工具来处理这种潜在的问题。有几种可能的方法：
使用压缩转储。. 你可以使用你喜欢的压缩程序，例如gzip：
lt_dumpdbname| gzip >filename.gz
恢复：
gunzip -cfilename.gz | ltsqldbname
或者：
catfilename.gz | gunzip | ltsqldbname
使用split。.
split命令允许你将输出分割成较小的文件以便能够适应底层文件系统的尺寸要求。例如，让每一块的大小为2吉字节：
lt_dumpdbname| split -b 2G -filename
恢复：
catfilename* | ltsqldbname
如果使用 GNU split, 可能会把它和 gzip 一起使用:
lt_dump dbname | split -b 2G --filter='gzip > $FILE.gz'
它可以用 zcat 恢复。
使用lt_dump的自定义转储格式。.
如果LightDB所在的系统上安装了zlib压缩库，自定义转储格式将在写出数据到输出文件时对其压缩。这将产生和使用gzip时差不多大小的转储文件，但是这种方式的一个优势是其中的表可以被有选择地恢复。下面的命令使用自定义转储格式来转储一个数据库：
lt_dump -Fcdbname>filename
自定义格式的转储不是ltsql的脚本，只能通过lt_restore恢复，例如：
lt_restore -ddbnamefilename
详情请参阅lt_dump和lt_restore。
对于非常大型的数据库，你可能需要将split配合其他两种方法之一进行使用。
使用lt_dump的并行转储特性。.
为了加快转储一个大型数据库的速度，你可以使用lt_dump的并行模式。它将同时转储多个表。你可以使用-j参数控制并行度。并行转储只支持“目录”归档格式。
lt_dump -jnum-F d -fout.dirdbname
你可以使用lt_restore -j来以并行方式恢复一个转储。它只能适合于“自定义”归档或者“目录”归档，但不管归档是否由lt_dump -j创建。
lt_distributed_probackup.py — 备份和恢复 LightDB 分布式集群。
lt_distributed_dump.py — 提取一个分布式LightDB数据库到一个目录中，包括脚本文件或其他存档文件。
lt_distributed_restore.py — 从由 lt_distributed_dump.py 创建的归档文件中还原一个 LightDB 数据库。