精华内容
下载资源
问答
  • PostgreSQL备份和恢复

    千次阅读 2019-07-18 14:05:10
    按照备份后的文件类型,可以分为物理备份(文件系统级别的备份逻辑备份备份后的文件是sql文件或特定格式的导出文件);按照备份过程中是否停止数据库服务,可分为冷备份备份过程中停止数据...

    1.简介

    由于数据库中包含着有价值的数据,PostgreSQL数据库应当被定期地备份。虽然过程相当简单,但清晰地理解其底层技术和假设是非常重要的。

    2.PostgreSQL数据备份方式

    • 按照备份后的文件类型划分为

    物理备份:文件系统级别的备份
    逻辑备份:备份后的文件是sql文件或特定格式的导出文件

    • 按照备份过程中是否停止数据库服务划分为

    冷备份
    热备份

    • 按照备份是否是完整的数据库划分为

    全量备份:备份是完整的数据库
    增量备份:备份是上一次全量备份后数据库改变的内容

    有三种不同的基本方法来备份PostgreSQL数据:

    • 1、SQL转储 *
    • 2、文件系统级备份 *
    • 3、连续归档 *
      每一种都有其优缺点

    2.1. SQL转储

    用到的工具是pg_dumppg_dumpall
    SQL 转储方法的思想是创建一个由SQL命令组成的文件,当把这个文件回馈给服务器时,服务器将利用其中的SQL命令重建与转储时状态一样的数据库。 PostgreSQL为此提供了工具pg_dump。这个工具的基本用法是:

    pg_dump dbname > outfile
    

    正如你所见,pg_dump把结果输出到标准输出。我们后面将看到这样做有什么用处。 尽管上述命令会创建一个文本文件,pg_dump可以用其他格式创建文件以支持并行 和细粒度的对象恢复控制。

    pg_dump是一个普通的PostgreSQL客户端应用(尽管是个相当聪明的东西)。这就意味着你可以在任何可以访问该数据库的远端主机上进行备份工作。但是请记住 pg_dump不会以任何特殊权限运行。具体说来,就是它必须要有你想备份的表的读 权限,因此为了备份整个数据库你几乎总是必须以一个数据库超级用户来运行它(如果你没有足够的特权 来备份整个数据库,你仍然可以使用诸如-n schema 或-t table选项来备份该数据库中你能够 访问的部分)。

    要声明pg_dump连接哪个数据库服务器,使用命令行选项-hhost-p port。 默认主机是本地主机或你的PGHOST环境变量指定的主机。 类似地,默认端口是环境变量PGPORT或(如果PGPORT不存在)内建的默认值。 (服务器通常有相同的默认值,所以还算方便。)

    和任何其他PostgreSQL客户端应用一样, pg_dump默认使用与当前操作系统用户名同名的数据库用户名进行连接。 要使用其他名字,要么声明-U选项,要么设置环境变量PGUSER。请注意pg_dump的连接也要通过客户认证机制。

    pg_dump对于其他备份方法的一个重要优势是,pg_dump的输出可以很容易地在新版本的PostgreSQL中载入,而文件级备份和连续归档都是极度的服务器版本限定的。pg_dump也是唯一可以将一个数据库传送到一个不同机器架构上的方法,例如从一个32位服务器到一个64位服务器。

    由pg_dump创建的备份在内部是一致的, 也就是说,转储表现了pg_dump开始运行时刻的数据库快照,且在pg_dump运行过程中发生的更新将不会被转储。pg_dump工作的时候并不阻塞其他的对数据库的操作。 (但是会阻塞那些需要排它锁的操作,比如大部分形式的ALTER TABLE)

    2.1.1. 从转储中恢复

    pg_dump生成的文本文件可以由psql程序读取。 从转储中恢复的常用命令是:

    psql dbname < infile
    

    其中infile就是pg_dump命令的输出文件。这条命令不会创建数据库dbname,你必须在执行psql前自己从template0创建(例如,用命令createdb -T template0 dbname)。psql支持类似pg_dump的选项用以指定要连接的数据库服务器和要使用的用户名。 非文本文件转储可以使用pg_restore工具来恢复。

    在开始恢复之前,转储库中对象的拥有者以及在其上被授予了权限的用户必须已经存在。如果它们不存在,那么恢复过程将无法将对象创建成具有原来的所属关系以及权限(有时候这就是你所需要的,但通常不是)。

    默认情况下,psql脚本在遇到一个SQL错误后会继续执行。你也许希望在遇到一个SQL错误后让psql退出,那么可以设置ON_ERROR_STOP变量来运行psql,这将使psql在遇到SQL错误后退出并返回状态3:

    psql --set ON_ERROR_STOP=on dbname < infile
    

    不管怎样,你将只能得到一个部分恢复的数据库。作为另一种选择,你可以指定让整个恢复作为一个单独的事务运行,这样恢复要么完全完成要么完全回滚。这种模式可以通过向psql传递-1或–single-transaction命令行选项来指定。在使用这种模式时,注意即使是很小的一个错误也会导致运行了数小时的恢复被回滚。但是,这仍然比在一个部分恢复后手工清理复杂的数据库要更好。

    pg_dump和psql读写管道的能力使得直接从一个服务器转储一个数据库到另一个服务器成为可能,例如:

    pg_dump -h host1 dbname | psql -h host2 dbname
    

    重要
    pg_dump产生的转储是相对于template0。这意味着在template1中加入的任何语言、过程等都会被pg_dump转储。结果是,如果在恢复时使用的是一个自定义的template1,你必须从template0创建一个空的数据库,正如上面的例子所示。

    一旦完成恢复,在每个数据库上运行ANALYZE是明智的举动,这样优化器就有有用的统计数据了。

    2.1.2. 使用pg_dumpall

    pg_dump每次只转储一个数据库,而且它不会转储关于角色或表空间(因为它们是集簇范围的)的信息。为了支持方便地转储一个数据库集簇的全部内容,提供了pg_dumpall程序。pg_dumpall备份一个给定集簇中的每一个数据库,并且也保留了集簇范围的数据,如角色和表空间定义。该命令的基本用法是:

    pg_dumpall > outfile
    

    转储的结果可以使用psql恢复:

    psql -f infile postgres
    

    (实际上,你可以指定恢复到任何已有数据库名,但是如果你正在将转储载入到一个空集簇中则通常要用(postgres)。在恢复一个pg_dumpall转储时常常需要具有数据库超级用户访问权限,因为它需要恢复角色和表空间信息。如果你在使用表空间,请确保转储中的表空间路径适合于新的安装。

    pg_dumpall工作时会发出命令重新创建角色、表空间和空数据库,接着为每一个数据库pg_dump。这意味着每个数据库自身是一致的,但是不同数据库的快照并不同步。

    集簇范围的数据可以使用pg_dumpall的–globals-only选项来单独转储。如果在单个数据库上运行pg_dump命令,上述做法对于完全备份整个集簇是必需的。

    2.1.3. 处理大型数据库

    在一些具有最大文件尺寸限制的操作系统上创建大型的pg_dump输出文件可能会出现问题。幸运地是,pg_dump可以写出到标准输出,因此你可以使用标准Unix工具来处理这种潜在的问题。有几种可能的方法:

    使用压缩转储。. 你可以使用你喜欢的压缩程序,例如gzip:

    pg_dump dbname | gzip > filename.gz
    

    恢复:

    gunzip -c filename.gz | psql dbname
    

    或者:

    cat filename.gz | gunzip | psql dbname
    

    使用split。. split命令允许你将输出分割成较小的文件以便能够适应底层文件系统的尺寸要求。例如,让每一块的大小为1兆字节:

    pg_dump dbname | split -b 1m - filename
    

    恢复:

    cat filename* | psql dbname
    

    使用pg_dump的自定义转储格式。. 如果PostgreSQL所在的系统上安装了zlib压缩库,自定义转储格式将在写出数据到输出文件时对其压缩。这将产生和使用gzip时差不多大小的转储文件,但是这种方式的一个优势是其中的表可以被有选择地恢复。下面的命令使用自定义转储格式来转储一个数据库:

    pg_dump -Fc dbname > filename
    

    自定义格式的转储不是psql的脚本,只能通过pg_restore恢复,例如:

    pg_restore -d dbname filename
    

    详情请参阅pg_dumppg_restore

    对于非常大型的数据库,你可能需要将split配合其他两种方法之一进行使用。

    使用pg_dump的并行转储特性。. 为了加快转储一个大型数据库的速度,你可以使用pg_dump的并行模式。它将同时转储多个表。你可以使用-j参数控制并行度。并行转储只支持“目录”归档格式。

    pg_dump -j num -F d -f out.dir dbname
    

    你可以使用pg_restore -j来以并行方式恢复一个转储。它只能适合于“自定义”归档或者“目录”归档,但不管归档是否由pg_dump -j创建。

    2.2. 文件系统级别备份(冷备份)

    文件系统级别备份策略是直接复制PostgreSQL用于存储数据库中数据的文件。你可以采用任何你喜欢的方式进行文件系统备份。
    数据库集簇说明:
    在磁盘上初始化一个数据库存储区域称之为一个数据库集簇(SQL标准使用的术语是目录集簇)。一个数据库集簇是被一个运行数据库服务器的单一实例所管理的多个数据库的集合。
    在文件系统术语中,一个数据库集簇是一个单一目录,所有数据都将被存储在其中。我们称它为数据目录或数据区域。在哪里存储你的数据完全由你选择。没有默认的位置,不过/usr/local/pgsql/data或/var/lib/pgsql/data位置比较流行。
    你的数据库集簇的文件系统位置由-D选项指定,例如:

    $ initdb -D /usr/local/pgsql/data
    

    作为-D选项的一种替换方案,你可以设置环境变量PGDATA

    2.2.1备份数据库集簇文件

    示例

    tar -cf backup.tar /usr/local/pgsql/data
    

    限制
    文件系统级别备份数据的方法有两个限制,使得这种方法不实用:

    1.为了得到一个可用的备份,数据库服务器必须被关闭。例如阻止所有连接这样的不彻底的措施是不起作用的(部分原因是tar和类似工具无法得到文件系统状态的一个原子的快照,还有服务器内部缓冲的原因)不用说,在恢复数据之前你也需要关闭服务器

    2.如果你已经深入地了解了数据库的文件系统布局的细节,你可能会有兴趣尝试通过相应的文件或目录来备份或恢复特定的表或数据库。这种方法也不会起作用,因为包含在这些文件中的信息只有配合提交日志文件(pg_xact/)才有用,提交日志文件包含了所有事务的提交状态。一个表文件只有和这些信息一起才有用。当然也不可能只恢复一个表及相关的pg_xact数据,因为这会导致数据库集簇中所有其他表变得无用。因此文件系统备份只适合于完整地备份或恢复整个数据库集簇*。

    2.2.2一致快照

    另一种文件系统备份方法是创建一个数据目录的“一致快照”,如果文件系统支持此功能(并且你相信它的实现正确)。典型的过程是创建一个包含数据库的卷的“冻结快照”,然后从该快照复制整个数据目录(如上,不能是部分复制)到备份设备,最后释放冻结快照。即使在数据库服务器运行时,这种方式也有效。但是,以这种方式创建的备份保存的文件看起来就像数据库没有被正确关闭时的状态。因此,当你从备份数据上启动数据库服务器时,它会认为上一次的服务器实例崩溃了并尝试重放WAL日志。这不是问题,只是需要注意(当然WAL文件必须要包括在备份中)。你可以在拍摄快照之前执行一次CHECKPOINT以便节省恢复时间。

    如果你的数据库跨越多个文件系统,可能没有任何方式可以对所有卷获得完全同步的冻结快照。例如,如果你的数据文件和WAL日志放置在不同的磁盘上,或者表空间在不同的文件系统中,可能没有办法使用快照备份,因为快照必须是同步的。在这些情况下,一定要仔细阅读你的文件系统文档以了解其对一致快照技术的支持。

    如果没有可能获得同步快照,一种选择是将数据库服务器关闭足够长的时间以建立所有的冻结快照。另一种选择是执行一次连续归档基础备份,因为这种备份对于备份期间发生的文件系统改变是免疫的。这要求在备份过程中允许连续归档,恢复时使用连续归档恢复。

    2.2.3 rsync

    使用rsync来执行一次文件系统备份,是先在数据库服务器运行时执行rsync,然后关闭数据库服务器足够长时间来做一次rsync --checksum (–checksum是必需的,因为rsync的文件修改 时间粒度只能精确到秒)。第二次rsync会比第一次快,因为它只需要传送相对很少的数据,由于服务器是停止的,所以最终结果将是一致的。这种方法允许在最小停机时间内执行一次文件系统备份。

    2.2.4小结

    这种备份方式需要关闭数据库,然后拷贝数据文件的完整目录。恢复数据库时,只需将数据目录复制到原来的位置。该方式实际工作中很少使用。
    一个文件系统备份通常会比一个SQL转储体积更大(例如pg_dump不需要转储索引的内容,而是转储用于重建索引的命令)。但是,做一次文件系统备份可能更快。

    2.3. 连续归档和时间点恢复(PITR)

    2.3.1.整体介绍

    在任何时间,PostgreSQL在数据集簇目录的pg_wal/子目录下都保持有一个预写式日志(WAL)。这个日志存在的目的是为了保证崩溃后的安全:如果系统崩溃,可以“重放”从最后一次检查点以来的日志项来恢复数据库的一致性。该日志的存在也使得第三种备份数据库的策略变得可能:我们可以把一个文件系统级别的备份和WAL文件的备份结合起来。当需要恢复时,我们先恢复文件系统备份,然后从备份的WAL文件中重放来把系统带到一个当前状态。这种方法比之前的方法管理起来要更复杂,但是有其显著的优点。
    优点:
    1.我们不需要一个完美的一致的文件系统备份作为开始点。备份中的任何内部不一致性将通过日志重放(这和崩溃恢复期间发生的并无显著不同)来修正。因此我们不需要文件系统快照功能,只需要tar或一个类似的归档工具。

    2. 由于我们可以结合一个无穷长的WAL文件序列用于重放,可以通过简单地归档WAL文件来达到连续备份。这对于大型数据库特别有用,因为在其中不方便频繁地进行完全备份。

    3.并不需要一直重放WAL项一直到最后。我们可以在任何点停止重放,并得到一个数据库在当时的一致快照。这样,该技术支持时间点恢复:在得到你的基础备份以后,可以将数据库恢复到它在其后任何时间的状态。

    4.如果我们连续地将一系列WAL文件输送给另一台已经载入了相同基础备份文件的机器,我们就得到了一个热备份系统:在任何时间点我们都能提出第二台机器,它差不多是数据库的当前副本。
    注意:
    pg_dump和pg_dumpall不会产生文件系统级别的备份,并且不能用于连续归档方案。这类转储是逻辑的并且不包含足够的信息用于WAL重放。

    就简单的文件系统备份技术来说,这种方法只能支持整个数据库集簇的恢复,却无法支持其中一个子集的恢复。另外,它需要大量的归档存储:一个基础备份的体积可能很庞大,并且一个繁忙的系统将会产生大量需要被归档的WAL流量。尽管如此,在很多需要高可靠性的情况下,它是首选的备份技术。

    要使用连续归档(也被很多数据库厂商称为“在线备份”)成功地恢复,你需要一个从基础备份时间开始的连续的归档WAL文件序列。为了开始,在你建立第一个基础备份之前,你应该建立并测试用于归档WAL文件的过程。对应地,我们首先讨论归档WAL文件的机制。

    2.3.2.建立WAL归档

    抽象地来说,一个运行中的PostgreSQL系统产生一个无穷长的WAL记录序列。系统从物理上将这个序列划分成WAL 段文件,通常是每个16MB(段尺寸在构建PostgreSQL时可修改)。段文件会被分配一个数字名称以便反映它在整个抽象WAL序列中的位置。在没有使用WAL归档时,系统通常只创建少量段文件,并且通过重命名不再使用的段文件为更高的段编号来“回收”它们。系统假设内容位于最后一个检查点之前的段文件是无用的且可以被回收。

    在归档WAL数据时,我们需要在每一段被填充满时捕捉其内容,并且在段文件被回收重用之前保存该数据。依靠应用和可用的硬件,有很多不同的方法来“保存数据”:我们可以将段文件拷贝到一个已挂载的位于另一台机器上的NFS目录,或者将它们写出到一个磁带驱动器(确保你有办法标识每个文件的原始文件名),或者将它们批量烧录到CD上,或者其他什么方法。为了向数据库管理员提供灵活性,PostgreSQL不对如何归档做任何假设。取而代之的是,PostgreSQL让管理员声明一个shell命令来拷贝一个完整的段文件到它需要去的地方。 该命令可以简单得就是一个cp,或者它可以调用一个复杂的 shell 脚本 — 所有都由你决定。

    要启用WAL归档,需设置wal_level配置参数为replica或更高,设置archive_mode为on,并且使用archive_command配置参数指定一个shell命令。实际上,这些设置总是被放置在postgresql.conf文件中。在archive_command中,%p会被将要归档的文件路径所替代,而%f只会被文件名所替代(路径名是相对于当前工作目录而言的,即集簇的数据目录)。修改postgresql.conf文件,如果你需要在命令中嵌入一个真正的%字符,可以使用%%。最简单的命令类似于:

    archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
    archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows
    

    它将把 WAL 段拷贝到目录/mnt/server/archivedir(这个只是一个例子,并非我们建议的方法,可能不能在所有系统上都正确运行)。在%p和%f参数被替换之后,实际被执行的命令看起来可能是:

    test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065
    

    对每一个将要被归档的新文件都会生成一个类似的命令。

    归档命令将在运行PostgreSQL服务器的同一个用户的权限下执行。因为被归档的一系列WAL 文件实际上包含你的数据库里的所有东西,所以你应该确保自己的归档数据不会被别人窥探; 比如,归档到一个没有组或者全局读权限的目录里。

    有一点很重要:当且仅当归档命令成功时,它才返回零退出。在得到一个零值结果之后,PostgreSQL将假设该文件已经成功归档, 因此它稍后将被删除或者被新的数据覆盖。但是,一个非零值告诉PostgreSQL该文件没有被归档; 因此它会周期性的重试直到成功。

    归档命令通常应该被设计成拒绝覆盖已经存在的归档文件。这是一个非常重要的安全特性, 可以在管理员操作失误(比如把两个不同的服务器的输出发送到同一个归档目录)的时候保持你的归档的完整性。

    我们建议你首先要测试你准备使用到归档命令,以保证它实际上不会覆盖现有的文件, 并且在这种情况下它返回非零状态。以上Unix中的命令例子通过包含一个独立的test步骤来保证这一点。
    在设计你的归档环境时,请考虑一下如果归档命令不停失败会发生什么情况, 因为有些情况要求操作者的干涉,或者是归档空间不够了。你应该确保任何错误情况或者任何要求操作员干涉的情况都会被正确报告, 这样才能迅速解决这些问题。否则pg_wal/目录会不停地被WAL段文件填充, 直到问题解决(如果包含pg_wal/的文件系统被填满,PostgreSQL将会做一次致命关闭。不会有未提交事务被丢失,但是数据库将会保持离线直到你释放一部分空间)。

    归档命令的速度并不要紧,只要它能跟上你的服务器生成 WAL 数据的平均速度即可。即使归档进程稍微落后,正常的操作也会继续进行。 如果归档进程慢很多,就会增加灾难发生的时候丢失的数据量。这同时也意味着pg_wal/目录包含大量未归档的段文件, 并且可能最后超出了可用磁盘空间。我们建议你监控归档进程,确保它是按照你的期望运转的。

    在写自己的归档命令的时候,你应该假设被归档的文件名最长为64个字符并且可以包含 ASCII 字母、数字以及点的任意组合。 我们不需要保持原始的相对路径(%p),但是有必要保持文件名(%f)。

    请注意尽管 WAL 归档允许你恢复任何对你的PostgreSQL数据库中数据所做的修改, 但它不会恢复对配置文件的修改(即postgresql.conf、pg_hba.conf 和 pg_ident.conf),因为这些文件都是手工编辑的,而不是通过 SQL 操作来编辑的。 所以你可能会需要把你的配置文件放在一个日常文件系统备份过程可处理的位置。

    归档命令只会为完成的WAL段调用。因此如果你的服务器产生了一点点WAL流量(或者在产生时有宽松的周期),从一个事务完成到它被安全地记录在归档存储中之间将会有较长的延迟。要为未归档数据设置一个年龄限制,你可以设置archive_timeout来强制要求服务器按照其设定的频度切换到一个新的WAL段。注意由于强制切换而被归档的文件还是具有和完全归档的文件相同的长度。因此设置一个很短的archive_timeout是很不明智的 — 它会膨胀你的归档存储。将archive_timeout设置为1分钟左右通常是合理的。

    同样,如果你希望确保一个刚刚完成的事务能被尽快归档,可以使用pg_switch_xlog进行一次手动段切换。
    wal_levelminimal时,一些SQL命令被优化为避免记录WAL日志。在这些语句的其中之一的执行过程中如果打开了归档或流复制,WAL中将不会包含足够的信息用于归档恢(崩溃恢复不受影响)。出于这个原因,wal_level只能在服务器启动时修改。但是,archive_command可以通过重载配置文件来修改。如果你希望暂时停止归档,一种方式是将archive_command设置为空串('')。这将导致WAL文件积累在pg_wal/中,直到一个可用的archive_command被重新建立。

    2.3.3.制作一个基础备份

    执行一次基础备份最简单的方法是使用pg_basebackup工具。它将会以普通文件或一个tar归档的方式创建一个基础备份。如果需要比pg_basebackup更高的灵活性,你也可以使用低级API来制作一个基础备份。

    没有必要关心创建一个基础备份所需的时间。但是,如果你正常地运行停用了full_page_writes的服务器,你可能会注意到备份运行时的性能下降,因为full_page_writes在备份模式期间会被实际强制实施。

    要使用备份,你将需要保留所有在文件系统备份期间及之后生成的WAL段文件。为了便于你做这些,基础备份过程会创建一个备份历史文件,它将被立刻存储到WAL归档区域。该文件以文件系统备份中你需要的第一个WAL段文件命名。例如,如果开始的WAL文件是0000000100001234000055CD,则备份历史文件将被命名为0000000100001234000055CD.007C9330.backup.(文件名的第二部分表明WAL文件中的一个准确位置,一般可以被忽略)。一旦你已经安全地归档了文件系统备份和在备份过程中被使用的WAL段文件(如备份历史文件中所指定的) ,所有名字在数字上低于备份历史文件中记录值的已归档WAL段对于恢复文件系统备份就不再需要了,并且可以被删除。但是你应该考虑保持多个备份集以绝对保证你能恢复你的数据。

    备份历史文件是一个很小的文本文件。它包含你指定给pg_basebackup的标签字符串,以及备份的起止时间以及起止WAL段。如果你使用该标签来标识相关转储文件,则已归档的历史文件足以说明需要哪个转储文件进行恢复。

    由于你不得不保存最后一次基础备份之后的所有归档WAL文件,基础备份之间的间隔通常应该根据你希望在归档WAL文件上花费的存储空间来设定。你也应该考虑你准备花多长时间来进行恢复,如果需要恢复 — 系统将不得不重放所有那些WAL段,如果这些WAL段覆盖了最后一次基础备份以后的很长时间,重放过程将会花费一些时间。

    2.3.4.使用低级API制作一个基础备份

    使用低级API制作一个基础备份的过程比pg_basebackup方法要包含更多的步骤,但相对要更简单。很重要的一点是,这些步骤要按照顺序执行,并且在执行下一步之前要验证上一步是否成功。

    可以用非排他或者排他的方法来制作低级基础备份。我们推荐非排他方法,而排他的方法已经被废弃并且最终将被去除。

    2.3.4.1. 制作一个非排他低级备份

    非排他低级备份允许其他并发备份运行(既包括那些使用同样的 备份 API 开始的备份,也包括那些使用 pg_basebackup开始的备份)。

    1.确保WAL归档被启用且正在工作。

    2.作为一个具有运行 pg_start_backup 权利的用户(超级用户,或者被授予在该 函数上 EXECUTE 的用户)连接到服务器(不在乎是哪个数据库)并且发出命令:

    SELECT pg_start_backup('label', false, false);
    

    其中label是用来唯一标识这次备份操作的任意字符串。调用 pg_start_backup的连接必须被保持到备份结束,否则备份 将被自动中止。

    默认情况下,pg_start_backup可能需要较长的时间完成。 这是因为它会执行一个检查点,并且该检查点所需要的 I/O 将会分散到一段 显著的时间上,默认情况下是你的检查点间隔(见配置参数 checkpoint_completion_target)的一半。这通常 是你所想要的,因为它可以最小化对查询处理的影响。如果你想要尽可能快地 开始备份,请把第二个参数改成true, 这将使用尽可能多的I/O发出即时检查点。

    第三个参数为false会告诉pg_start_backup 开始一次非排他基础备份。

    3.使用任何趁手的文件系统备份工具(例如tar或者 cpio,不是pg_dump 或者pg_dumpall)执行备份。当你做这些 时,不需要也不值得停止正常的数据库操作。
    4.在同一个连接中,发出命令:

    SELECT * FROM pg_stop_backup(false);
    

    这会终止备份模式。在主服务器上,它还自动切换到下一个 WAL 段。 在备服务器上,无法自动切换WAL段,因此您可能希望在主服务器上运行 pg_switch_wal以执行手动切换。 切换的原因是让备份间隔期间写入的最后一个WAL段文件准备归档。

    pg_stop_backup将返回一个具有三个值的行。这些域的 第二个应该被写入到该备份根目录中名为backup_label的 文件。第三个域应该被写入到一个名为tablespace_map 的文件,除非该域为空。这些文件对该备份正常工作来说是至关重要的, 不能被随意修改。

    1. 一旦备份期间活动的 WAL 段文件被归档,备份就完成了。由 pg_stop_backup的第一个返回值标识的文件是构成一个 完整备份文件集合所需的最后一个段。在主服务器上,如果 archive_mode被启用,并且wait_for_archive参数为true,则直到最后一个段被归档前pg_stop_backup都不会 返回。在备用服务器上,为了使pg_stop_backup等待, archive_mode必须是always。 从你已经配置好archive_command之后这些文件的 归档就会自动发生。在大部分情况下,这些归档会很快发生,但是建议你监控你的归档系统确保没有延迟。如果归档进程由于归档命令的失败而落后,它将会持续重试直到归档成功并且备份完成。如果你希望对 pg_stop_backup的执行给出一个时间限制,可以设置一个 合适的statement_timeout值,但要注意如果 pg_stop_backup因此而中止会致使备份可能失效。

    如果备份进程监视并确保备份所需的所有WAL段文件已成功归档,则可以将 wait_for_archive参数(默认为true)设置为false以使 停止备份记录写入WAL后,pg_stop_backup立即返回。 默认情况下,pg_stop_backup将一直等到所有WAL归档完毕, 这可能需要一些时间。必须谨慎使用此选项:如果未正确监控WAL归档, 则备份可能未包括所有WAL文件,因此将不完整且无法恢复。

    2.3.4.2. 制作一个排他低级备份

    一个排他备份的处理绝大部分都和非排他备份相同,但是在一些关键步骤上 不同。这种类型的备份只能在主服务器上进行,并且不允许并发备份。
    1.确保 WAL 归档被启用且正常工作。

    2.作为一个具有运行 pg_start_backup 权利的用户(超级用户,或者被授予在该 函数上 EXECUTE 的用户)连接到服务器(不在乎是哪个数据库)并且发出命令:

    SELECT pg_start_backup('label');
    

    这里label是任何你希望用来唯一标识这个备份操作的字符串。 pg_start_backup在集簇目录中创建一个关于备份信息的 备份标签文件,也被称为backup_label, 其中包括了开始时间和标签字符串。该函数也会在集簇目录中创建一个 名为tablespace_map的表空间映射文件, 如果在pg_tblspc/中有一个或者多个表空间符号链接存在, 该文件会包含它们的信息。如果你需要从备份中恢复,这两个文件对于备份的 完整性都至关重要。

    默认情况下,pg_start_backup会花费很长时间来完成。这是因为它会执行一个检查点,而检查点所需要的I/O在相当一段时间内将会被传播,默认情况下这段时间是内部检查点间隔的一半。这通常是你所希望的,因为它能将对查询处理的影响最小化。如果你要尽快开始备份,可使用:

    SELECT pg_start_backup('label', true);
    

    这会使检查点尽可能快地被完成。

    使用任何方便的文件系统备份工具执行备份,例如tar 或cpio(不是pg_dump 或pg_dumpall)。在此期间,不需要也 不值得停止正常的数据库操作。

    注意,如果服务器在备份期间崩溃,直到从PGDATA 目录手动删除backup_label文件,才可能重新启动。

    4.再次以具有运行 pg_stop_backup 权利的用户(超级用户,或者已经被授予 该函数上 EXECUTE 的用户)连接到数据库并且发出命令:

    SELECT pg_stop_backup();
    

    该函数终止备份模式,并且执行一个自动切换到下一个WAL段。 进行切换的原因是将在备份期间生成的最新WAL段安排为可归档。

    5.一旦备份期间活动的WAL段文件被归档,你的工作就完成了。 pg_stop_backup的结果所标识的文件是构成一个完整备份 文件组所需的最新段。如果archive_mode被启用,直到最 新段被归档pg_stop_backup都不会返回。由于你已经配置了 archive_command,这些文件的归档过程会自动发生。在 大部分情况下这会很快发生,但还是建议你监控你的归档系统来确保不会有 延迟。如果归档处理由于归档命令的错误而延迟,它会保持重试直到归档成 功和备份完成。如果你希望在pg_stop_backup的执行上 设置一个时间限制,可对statement_timeout设 置一个合适的值,但要注意如果pg_stop_backup因此而 中止会致使备份可能失效。

    2.3.4.3. 备份数据目录

    如果被拷贝的文件在拷贝过程中发生变化,某些文件系统备份工具会发出警告或错误。在建立一个活动数据库的基础备份时,这种情况是正常的,并非一个错误。然而,你需要确保你能够把它们和真正的错误区分开。例如,某些版本的rsync为“消失的源文件”返回一个独立的退出码,且你可以编写一个驱动脚本来将该退出码接受为一种非错误情况。同样,如果一个文件在被tar复制的过程中被截断,某些版本的GNU tar会返回一个与致命错误无法区分的错误代码。幸运的是,如果一个文件在备份期间被改变,版本为1.16及其后的GNU tar将会退出并返回1,而对于其他错误返回2。在版本1.23及其后的GNU tar中,你可以使用警告选项--warning=no-file-changed --warning=no-file-removed来隐藏相关的警告消息。

    确认你的备份包含数据库集簇目录(例如/usr/local/pgsql/data)下的所有文件。如果你使用了不在此目录下的表空间,注意也把它们包括在内(并且确保你的备份将符号链接归档为链接,否则恢复过程将破坏你的表空间)。

    不过,你应当从备份中忽略集簇的pg_wal/子目录中的文件。这种微小的调整是值得的,因为它降低了恢复时的错误风险。如果pg_wal/是一个指向位于集簇目录之外其他地方的符号链接就很容易安排了,这是一种出于性能原因的常见设置。你可能也希望排除postmaster.pidpostmaster.opts,它们记录了关于postmaster运行的信息,但与最终使用这个备份的postmaster无关(这些文件可能会使pg_ctl搞混淆)。

    从备份中忽略集簇的pg_replslot/子目录中的文件通常也是个好主意,这样 主控机上存在的复制槽不会成为备份的一部分。否则,后续用该备份创建一个后备机可能会导致该 后备机上的WAL文件被无限期保留,并且在启用了热后备反馈的情况下可能导致主控机膨胀,因为使用 那些复制槽的客户端将继续连接到主控机(而不是后备机)并且继续更新其上的槽。即使该备份是要被 用来创建一个新的主控机,拷贝复制槽也不是特别有用,因为这些槽的内容在新主控机上线时很可能已 经过时。

    pg_dynshmem/pg_notify/pg_serial/pg_snapshots/pg_stat_tmp/pg_subtrans/目录的内容()(但不是目录本身)可以从备份中省略, 因为它们将在postmaster启动时初始化。如果设置了 stats_temp_directory并且是在数据目录下, 那么也可以省略该目录的内容。

    任何以pgsql_tmp开头的文件或目录都可以从备份中省略。 这些文件在postmaster启动时被删除,并且根据需要重新创建目录。

    备份标签文件包含你指定给pg_start_backup的标签字符串,以及 pg_start_backup被运行的时刻和起始WAL文件的名字。 在发生混乱的情况下就可以在备份文件中查看并准确地决定该转储文件来 自于哪个备份会话。表空间映射文件包括存在于目录pg_tblspc/ 中的符号链接名称以及每一个符号链接的完整路径。这些文件不仅是为了供参考, 它们的存在和内容对于系统恢复过程的正确操作是至关重要。

    在服务器停止时也可以创建一个备份。在这种情况下,你显然不能使用 pg_start_backuppg_stop_backup, 并且因此你只能依靠你的自己的策略来跟踪哪个备份是哪个, 以及相关WAL文件应该走回到什么程度。通常最好遵循上面的连续归档过程。

    2.3.5. 使用一个连续归档备份进行恢复

    你需要从备份进行恢复,其过程如下:

    1.如果服务器仍在运行,停止它。

    2.如果你具有足够的空间,将整个集簇数据目录和表空间复制到一个临时位置,稍后你将用到它们。注意这种预防措施将要求在你的系统上有足够的空闲空间来保留现有数据库的两个拷贝。如果你没有足够的空间,你至少要保存集簇的pg_wal子目录的内容,因为它可能包含在系统垮掉之前还未被归档的日志。

    3.移除所有位于集簇数据目录和正在使用的表空间根目录下的文件和子目录。

    4.从你的文件系统备份中恢复数据库文件。注意它们要使用正确的所有权恢复(数据库系统用户,不是root!)并且使用正确的权限。如果你在使用表空间,你应该验证pg_tblspc/中的符号链接被正确地恢复。

    5.移除pg_wal/中的任何文件,这些是来自于文件系统备份而不是当前日志,因此可以被忽略。如果你根本没有归档pg_wal/,那么以正确的权限重建它。注意如果以前它是一个符号链接,请确保你也以同样的方式重建它。

    6.如果你有在第2步中保存的未归档WAL段文件,把它们拷贝到pg_wal/(最好是拷贝而不是移动它们,这样如果在开始恢复后出现问题你任然有未修改的文件)。

    7.在集簇数据目录中创建一个恢复命令文件recovery.conf。你可能还想临时修改pg_hba.conf来阻止普通用户在成功恢复之前连接。

    8.启动服务器。服务器将会进入到恢复模式并且进而根据需要读取归档WAL文件。恢复可能因为一个外部错误而被终止,可以简单地重新启动服务器,这样它将继续恢复。恢复过程结束后,服务器将把recovery.conf重命名为recovery.done(为了阻止以后意外地重新进入恢复模式),并且开始正常数据库操作。

    9.检查数据库的内容来确保你已经恢复到了期望的状态。如果没有,返回到第1步。如果一切正常,通过恢复pg_hba.conf为正常来允许用户连接。

    所有这些的关键部分是设置一个恢复配置文件,它描述你希望如何恢复以及恢复要运行到什么程度。你可以使用recovery.conf.sample(通常在安装的share/目录中)作为一个原型。你绝对必须在recovery.conf中指定的是restore_command,它告诉PostgreSQL如何获取归档WAL文件段。与archive_command相似,这也是一个shell命令字符串。它可以包含%f(将被期望的日志文件名替换)和%p(将被日志文件被拷贝的目标路径名替换)。(路径名是相对于当前工作目录的,即集簇的数据目录)。如果你需要在命令中嵌入一个真正的%字符,可以写成%%。最简单的命令类似于:

    restore_command = 'cp /mnt/server/archivedir/%f %p'
    

    它将从目录/mnt/server/archivedir中拷贝之前归档的WAL段。当然,你可以使用更复杂的,甚至是一个要求操作者装载合适磁带的shell脚本。

    重要的是命令在失败时返回非零退出状态。该命令将被调用来请求不在归档中的文件, 在这种情况下它应该返回非零值。这不是一种错误情况。一种例外是该命令被一个信号(除了被用作数 据库服务器关闭动作一部分的SIGTERM)终止或者被shell的错误 (例如命令未找到)终止,那样恢复将中止并且服务器将不会启动。

    并非所有被请求的文件都是WAL段文件,你也许还会请求一些具有.backup或 .history后缀的文件。还要注意的是,%p路径的基本名字将会和%f 不同,但不要期望它们可以互换。

    归档中找不到的WAL段可以在pg_wal/中看到,这使得可以使用最近未归档的段。但是,在归档中可用的段将会被优先于pg_wal/中的文件被使用。

    通常,恢复将会处理完所有可用的WAL段,从而将数据库恢复到当前时间点(或者尽可能接近给定的可 用WAL段)。因此,一个正常的恢复将会以一个“文件未找到”消息结束,错误消息的准确文 本取决于你选择的restore_command。你也可能在恢复的开始看到一个针对名称类 似于00000001.history文件的错误消息。这也是正常的并且不表示在简单恢复情况中的问题。

    如果你希望恢复到之前的某个时间点(例如,恢复到幼稚的DBA丢弃了你主要的交易表之前),只需要 在recovery.conf中指定要求的停止点。你可以使用日期/时间、命名恢复点或一个 指定事务ID的结束时间来定义停止点(也被称为“恢复目标”)。在这种写法中,只有日期/时 间和命名恢复点选项非常有用,因为没有工具可以帮助你准确地确定要用哪个事务ID。
    注意
    停止点必须位于基础备份的完成时间之后,即pg_stop_backup的完成时间。在备份过程中你不能使用基础备份来恢复(要恢复到这个时间,你必须回到你之前的基础备份并且从这里开始前滚)。

    如果恢复找到被破坏的WAL数据,恢复将会停止于该点并且服务器不会启动。在这种情况下,恢复进程需要从开头重新开始运行,并指定一个在损坏点之前的“恢复目标”以便恢复能够正常完成。如果恢复由于一个外部原因失败,例如一个系统崩溃或者WAL归档变为不可访问,则该次恢复可以被简单地重启并且它将会从几乎是上次失败的地方继续。恢复重启工作起来很像普通操作时的检查点:服务器周期性地强制把它的所有状态写到磁盘中,然后更新pg_control文件来说明已经处理过的WAL数据,这样它们就不会被再次扫描。

    2.3.6. 时间线

    将数据库恢复到一个之前的时间点的能力带来了一些复杂性,想回到最初历史中的某个时间。你没法这样做,在你的数据库在线运行期间,它重写了某些WAL段文件,而这些文件本来可以将你引向你希望回到的时间。因此,为了避免出现这种状况,你需要将完成时间点恢复后生成的WAL记录序列与初始数据库历史中产生的WAL记录序列区分开来。

    要解决这个问题,PostgreSQL有一个时间线概念。无论何时当一次归档恢复完成,一个新的时间线被创建来标识恢复之后生成的WAL记录序列。时间线ID号是WAL段文件名的一部分,因此一个新的时间线不会重写由之前的时间线生成的WAL数据。实际上可以归档很多不同的时间线。虽然这可能看起来是一个无用的特性,但是它常常扮演救命稻草的角色。考虑到你不太确定需要恢复到哪个时间点的情况,你可能不得不做多次时间点恢复尝试和错误,直到最终找到从旧历史中分支出去的最佳位置。如果没有时间线,该处理将会很快生成一堆不可管理的混乱。而有了时间线,你可以恢复到任何之前的状态,包括早先被你放弃的时间线分支中的状态。

    每次当一个新的时间线被创建,PostgreSQL会创建一个“时间线历史”文件,它显示了新时间线是什么时候从哪个时间线分支出来的。系统在从一个包含多个时间线的归档中恢复时,这些历史文件对于允许系统选取正确的WAL段文件非常必要。因此,和WAL段文件相似,它们也要被归档到WAL归档区域。历史文件是很小的文本文件,因此将它们无限期地保存起来的代价很小,而且也是很合适的(而段文件都很大)。如果你喜欢,你可以在一个历史文件中增加注释来记录如何和为什么要创建该时间线。当你由于试验的结果拥有了一大堆错综复杂的不同时间线时,这种注释将会特别有价值。

    恢复的默认行为是沿着相同的时间线进行恢复,该时间线是基础备份创建时的当前时间线。如果你希望恢复到某个子女时间线(即,你希望回到在一次恢复尝试后产生的某个状态),你需要在recovery.conf中指定目标时间线ID。你不能恢复到早于该基础备份之前分支出去的时间线。

    2.3.7.操作实例

    2.3.7.1. 单机热备份

    可以使用PostgreSQL的备份功能来产生单机热备份。这些备份不能被用于时间点恢复,然而备份和恢复时要比使用pg_dump转储更快(它们也比pg_dump转储更大,所以在某些情况下速度优势可能会被否定)。

    在基础备份的帮助下,产生一个单机热备份最简单的方式是使用 pg_basebackup工具。如果你在调用它时使用了 -X参数,使用该备份所需的所有预写式日志将会被自动包含在该备份中,并且恢复该备份也不需要特殊的动作。

    如果在复制备份文件时需要更多灵活性,也可以使用一个较低层的处理来创建单机热备份。要为低层 单机热备份做准备,确保将wal_level设置为replica或更高, archive_mode设置为on,并且设置一个archive_command,该命令只当一个开关文件存在时执行归档。例如:

    wal_level = 'replica'
    archive_mode = ‘on'
    archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)'
    

    该命令在/var/lib/pgsql/backup_in_progress存在时执行归档,否则会安静地返回0值退出状态(让PostgreSQL能回收不需要的WAL文件)。

    通过这样的准备,可以使用一个如下所示的脚本来建立备份:

    touch /var/lib/pgsql/backup_in_progress
    psql -c "select pg_start_backup('hot_backup');"
    tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
    psql -c "select pg_stop_backup();"
    rm /var/lib/pgsql/backup_in_progress
    tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
    

    开关文件 /var/lib/pgsql/backup_in_progress首先被创建,这使对于未完成WAL文件的归档操作发生。备份完成之后开关文件会被删除。归档的WAL文件则被加入到备份中,这样基础备份和所有需要的WAL文件都是同一个tar文件的组成部分。请记住在你的备份脚本中加入错误处理。

    2.3.7.2. 压缩的归档日志

    如果担心归档存储的尺寸,你可以使用gzip来压缩归档文件:

    archive_command = 'gzip < %p > /var/lib/pgsql/archive/%f'
    

    那么在恢复时你将需要使用gunzip:

    restore_command = 'gunzip < /mnt/server/archivedir/%f > %p'
    

    2.3.7.3. archive_command脚本

    很多人选择使用脚本来定义他们的archive_command,这样他们的postgresql.conf项看起来非常简单:

    archive_command = 'local_backup_script.sh "%p" "%f"'
    

    任何时候如果你希望在归档处理中使用多个命令,明智的方法是使用一个独立的脚本文件。这可以使脚本更为复杂,它可以使用一种流行的脚本语言来编写,例如bash 或perl。

    需要在一个脚本内解决的需求例子包括:

     将数据拷贝到安全的场外数据存储
     批处理WAL文件,这样它们可以每三小时被传输一次,而不是一次一个
     与其他备份和恢复软件交互
     与监控软件交互以报告错误

    提示
    在使用一个`archive_command`脚本时,最好启用`logging_collector`。任何从该脚本被写到stderr的消息将出现在数据库服务器日志中,这允许在复杂配置失败后能更容易被诊断。
    

    2.3.8.警告

    连续归档技术存在一些限制:
    如果一个CREATE DATABASE命令在基础备份时被执行,然后在基础备份进行时CREATE DATABASE所复制的模板数据库被修改,恢复中可能会导致这些修改也被传播到已创建的数据库中。这当然是我们不希望的。为了避免这种风险,最好不要在创建基础备份时修改任何模板数据库。

    CREATE TABLESPACE命令会WAL以其字面绝对路径记录,并且因此将在重放时以相同的绝对路径来创建表空间。当日志在一台不同的机器上被重放时,这可能也不是我们希望的。即使日志在同一台机器上被重放也是危险的,就算是恢复到一个新的数据目录重放过程也会覆盖原来表空间的内容。为了避免这种潜在的陷阱,最佳做法是在创建或丢弃表空间后创建一个新的基础备份。

    还需要注意的是,默认的WAL格式相当庞大,因为它包括了很多磁盘页快照。这些页快照被设计用于支持崩溃恢复,因为我们可能需要修复断裂的磁盘页。依靠你的系统硬件和软件,页断裂的风险可能会小到可以忽略,在此种情况下你可以通过使用full_page_writes参数关闭页快照来显著降低归档日志的总容量。关闭页快照并不会阻止使用日志进行PITR操作。一个未来的开发点是通过移除不需要的页拷贝来压缩归档的WAL数据,即使full_page_writeson。同时,管理员可能希望通过尽可能增大检查点间隔参数来减少WAL中包含的页快照数量。

    参考:
    https://www.postgresql.org/docs/10/different-replication-solutions.html
    https://edu.csdn.net/course/play/25603/307048
    https://edu.csdn.net/course/play/25785/313742
    https://edu.csdn.net/course/play/25125/292196

    展开全文
  • 12 备份和恢复数据库

    千次阅读 2017-07-12 23:07:22
    备份和恢复数据库 本主题介绍如何使用Greenplum的备份和恢复功能。 定期执行备份,确保您可以恢复你的数据,或者数据损坏或系统故障发生重建Greenplum的数据库系统。您还可以使用备份将数据迁移从一个Greenplum...

    1        备份和恢复数据库

    本主题介绍如何使用Greenplum的备份和恢复功能。

    定期执行备份,确保您可以恢复你的数据,或者数据损坏或系统故障发生重建Greenplum的数据库系统。您还可以使用备份将数据迁移从一个Greenplum数据系统到另一个。

     

    1.1       备份和恢复概述

    With non-parallel backup and restore operations,the data must be sent over the network from the segments to the master, whichwrites all of the data to its storage. In addition to restricting I/O to onehost, non-parallel backup requires that the master have sufficient local diskstorage to store the entire database.

    Greenplum数据引擎支持备份和恢复数据库的并行和非并行的方法。并行操作规模不会受限于系统中的段数,因为段上的主机每个同时写入他们的数据到本地磁盘存储。在非并行备份和恢复操作时,数据必须在从段服务器到master,其中所有的数据都是通过网络进行发送。除了受限于一个主机的I/O之外,非并行备份要求master必须有足够的本地磁盘空间以存储整个数据库。

    1.1.1    并行备份和恢复

    GDPB的并行dump程序同时备份master实例和所有的活动段实例。

    默认情况下,gpcrondump在每个段实例的gp_dump子目录中创建转储文件。对于master, gpcrondump创建若干个转储文件,包含数据库的信息,如DDL语句,系统目录表,和元数据文件。在每个段上,gpcrondump创建一个转储文件,其中包含的命令来重新创建该段的数据。每个文件都包含一个14位的时间戳用以标识这个备份文件的归属。


    Figure 11: Parallel Backups in Greenplum Database

    The gpdbrestore parallel restore utility takes thetimestamp key generated by gpcrondump, validates the backup set, and restoresthe database objects and data into a distributed database. Parallel restoreoperations require a complete backup set created by gpcrondump, a full backup,and any required incremental backups. As the following figure illustrates, allsegments restore data from local backup files simultaneously.

    该gpdbrestore并行恢复工具需要通过gpcrondump产生的时间戳键,验证备份集,将数据库对象和数据恢复到一个分布式数据库。并行恢复操作需要由gpcrondump创建一个完整的备份集。一个完整的备份及,以及任何所需的增量备份。如下图所示,所有段同时从本地备份文件恢复数据。


    Figure 12: Parallel Restores in Greenplum Database

    该gpdbrestore工具提供了灵活性和验证的选项与通过gpcrondump或从Greenplum的集群移动到其他位置的备份文件生成的自动备份文件的使用。请参阅恢复Greenplum的数据库。 gpdbrestore也可用于将文件复制到备用位置。

    1.1.2    非并行备份和恢复

    PostgreSQL的pg_dump和pg_dumpall非并行备份实用程序可以用来在master上创建一个包含所有活动段中的所有数据的dump文件。

    PostgreSQL的非并行实用程序仅限在特殊情形下使用。它们比使用G​​reenplum备份工具慢很多,因为所有的数据都必须通过master。此外,master主机往往没有足够的空间来存储整个集群的数据。

    pg_restore的实用程序需要一个由pg_dump或pg_dumpall创建的压缩转储文件。在开始恢复之前,您应该修改转储文件的CREATE TABLE语句使其包含Greenplum的distributed子句。如果不包括distributed子句,Greenplum数据分配缺省值,这可能不是最优的。有关详细信息,请参阅Greenplum数据参考指南CREATE TABLE。see create table inthe Greenplum Database Reference Guide.

    要执行非并行恢复使用并行备份文件,可以备份文件从每段主机到主主机复制,然后通过主加载它们。请参阅恢复到不同的Greenplum的系统配置。See Restoring to a Different Greenplum System Configuration.


    Figure 13: Non-parallel Restore Using ParallelBackup Files

    备份数据库的Greenplum数据的另一种非并行的方法是使用复制到SQL命令表的全部或部分从数据库中拷贝到分隔的文本文件在master主机上。

    1.1.3    备份和恢复选项

    Greenplum的数据库备份和恢复工具支持备份文件不同的位置:

    •      使用 gpcrondump utility, 备份文件可以保存在默认位置, 在master和每个setment上的db_dumps 子目录,或者使用gpcrondump -u 选项来保存到另一个目录。

    •      gpcrondump 和gpdbrestore utilities 都集成了EMC Data Domain Boost 和 Symantec NetBackup 系统的支持.

    •               备份文件可以通过命名管道到任何网络访问的位置保存。

    •      保存到默认位置备份文件可以被移动到在网络上归档服务器。这使得在最高传输速率执行备份时(段写入备份数据快速本地磁盘阵列),然后将文件移动到远程存储释放磁盘空间。

    •               您可以创建转储包含选定的数据库对象:

    •      你可以通过命令行或文本文件指定一个或多个schema包含的表。

    •      你可以在备份是通过命令行或文本文件将指定的schema排除。

    •      你可以在命令行或文本文件中列出需要备份的表。表和schema不能在同一次备份中同时使用。

    •      对于数据库对象,gpcrondump 可以备份pg_hba.conf,pg_ident.conf, and postgresql.conf,以及全局数据库对象,如角色和表空间。

    你也可以创建增量备份:

    •      增量备份只包含追加优化和自最近一次增量备份或完全备份之后发生变化的面向列的表。

    •      对于分区追加优化表,只改追加优化/面向列的表分区进行备份。

    •      增量备份包括所有堆表。

    •      使用gpchrondump --incremental标志指定增量备份。

    •      还原增量备份需要一个完全备份和所有后续增量备份,最多要还原的备份。

    该gpdbrestore工具提供了很多选项:

    •默认情况下,gpdbrestore恢复数据,这是从备份的数据库。

    • --redirect标志允许您备份还原到不同的数据库。

    •恢复的数据库可以被删除并重新创建,但默认是恢复到现有的数据库。

    •选定表可以从备份通过列出在命令行上的表或通过在文本文件中列出它们并指定命令行的文本文件被恢复。

    •从备份文件移动到归档服务器可以恢复数据库。备份文件复制回原处主控主机上和每个段主机,然后恢复到数据库。

     

    1.2       使用gpcrondump备份

    使用gpcrondump备份数据库,数据以及数据库角色和服务器配置文件等对象。

    gpcrondump实用程序将Greenplum数据库的内容转储成SQL脚本文件并存在master和各个段服务器上。这些脚本文件可以被用来恢复数据库。

    master备份文件包含SQL命令来创建数据库schema。段数据转储文件包含SQL语句将数据加载到表中。段转储文件都是使用gzip压缩的。另外,服务器配置文件postgresql.conf,pg_ident.conf和pg_hba.conf以及角色和表空间也可以包含在备份中。

    该gpcrondump实用程序所需的一个标志,-x,其中指定数据库转储:

    gpcrondump -x MYDB

    这对指定数据库的默认位置完全备份。

     

    默认情况下,gpcrondump在data_directory创建在主服务器上的数据目录中的备份文件和每段实例/db_dumps目录。您可以使用-u标志指定不同的备份位置。例如,下面的命令将保存备份文件到/备份目录​​:

    gpcrondump MYDB -u  /backups

    gpcrondump会在指定目录下的子目录db_dumps。如果每个主机的多个主段,所有的主机上的段写的备份文件到同一目录。这不同于默认,其中每个段将备份写入其自己的数据的目录。这可以被用来合并备份以单个目录或装载的存储设备。

    在db_dumps目录,备份保存到一个目录中的YYYYMMDD格式,例如

    data_directory/db_dumps / 20151012对2015年10月12日,创建目录中的备份文件名包含一个完整的时间戳,格式为YYYYMMDDHHMMSS的备份,例如gp_dump_0_2_20151012195916.gz备份。该gpdbrestore命令默认使用最近的备份,但你可以指定一个较早的备份来恢复。

    如果包括了-g选项,gpcrondump保存与备份的配置文件。这些配置文件转储在主或段的数据目录db_dumps/YYYYMMDD/config_files_timestamp.tar。如果指定--ddboost,备份位于由--ddboost-BACKUPDIR设置的目录的存储单元。-G选项备份全局对象,如角色和表空间在指定gp_global_1_1_timestamp的主备份目录中的文件。

    如果指定--ddboost,备份位于由--ddboost-BACKUPDIR指定的目录的默认的存储单元。

    有许多可用来配置备份的更多gpcrondump选项。请参阅Greenplum的实用参考指南有关所有可用选项的信息。请参阅备份与Data Domain的升压数据库与Data Domain的加速备份的详细信息。

    1.3       备份一系列的表

    可以创建一个备份,其包括在一个数据库中的模式或表的子集,通过使用

    以下gpcrondump选项:

    •-t schema.tablename - 指定表的备份中包含。您可以使用-t选项多次。

    •--table文件=文件名 - 指定包含表的列表在备份中包含文件。

    •-T schema.tablename - 指定表从备份中排除。您可以使用-t选项多次。

    •--exclude表文件=文件名 - 指定包含表的列表,以从备份中排除的文件。

    •-s SCHEMA_NAME - 包括备份一个指定的架构名称限定的所有表。您可以使用-s选项多次。

    •--schema文件=文件名 - 指定包含模式列表的备份中包含的文件。

    •-S SCHEMA_NAME - 排除从备份指定的架构名称限定表。您可以使用-S选项多次。

    •--exclude-架构文件=文件名 - 指定包含架构名称从备份中排除的文件。

    只有一组表或模式的组可以被指定。例如,-s选项不能与-t选项指定。

    请参阅增量备份与设置有关使用与增量备份这些gpcrondump选项的其他信息。

    1.4       创建增量备份

    gpcrondump和gpdbrestore实用程序支持增量备份并附加优化表,包括面向列的表的恢复。使用gpcrondump --incremental选项来创建一个增量备份。

    如果下列操作之一是上次完全备份或增量备份后的表执行增量备份只备份追加优化或面向列的表:

    •        ALTER TABLE

    •        DELETE

    •        INSERT

    •        TRUNCATE

    •        UPDATE

    •        DROP and then re-create thetable

    对于分区的附加优化表,仅将更改分区备份。

    堆表是与每一个完全备份和增量备份备份。

    增量备份对于追加优化表分区或面向列的表中少量数据变化的情况下是非常有效的。

    每次gpcrondump运行时,它会创建一个包含数据库中每个追加优化表和列存储表以及分区表的行数的状态文件。这个状态文件也保存着元数据的操作例如truncate和alter。当gpcrondump在使用--incremental选项运行时,它的当前状态与存储的状态进行比较,以确定该表或分区是否应当包括在增量备份中。

    一个唯一的14位数字时间戳标识包括增量备份集文件。

    要创建一个增量备份或从增量备份恢复数据,您需要的完整备份集。一个完整的备份集包括一个完全备份和上次完全备份创建的所有增量备份。当您存档增量备份,上次完全备份和目标增量备份之间的所有增量备份必须归档。您必须存档在主服务器和所有段创建的所有文件。

    重要提示:对于增量备份集,完整备份和相关的增量备份,备份集必须在单个设备上。例如,备份集必须全部Data Domain系统上。备份集不能有Data Domain系统和其他本地文件系统或NetBackup系统上的一些备份。

    注意:您可以使用Data Domain的服务器作为NFS文件系统(不包括Data Domain的升压)执行增量备份。

    改变Greenplum数据段的配置无效增量备份。您更改分段配置后必须创建一个完整备份,然后才能创建增量备份。

    1.4.1    增量备份示例

    每个备份集都有一个键,它是在创建备份时采取了时间戳。例如,如果你在2012年5月14日,创建一个备份,备份设置文件名包含20120514hhmmss。该HHMMSS表示时间:小时,分钟和秒。

    在这个例子中,假设你已经创建的数据库mytest的两个全备份和增量备份。要创建完整备份,您使用以下命令:

    gpcrondump -x mytest -u /backupdir

    到后来,已经做了一些修改后追加优化的表,创建使用下面的命令的增量备份:

    gpcrondump -x mytest -u /backupdir --incremental

    当您指定-u选项,在每个Greenplum数据主机上的/ BACKUPDIR目录中创建备份。该文件名称包括以下时间戳密钥。全备份有时间戳关键20120514054532和20121114064330.其他的备份是增量备份。

    •               2 0120514054532 (full backup)

    •               20120714095512

    •               20120914081205

    •               20121114064330 (full backup)

    •               20130114051246

    要创建新的增量备份,你既需要最新的增量备份20130114051246和前面的完全备份20121114064330.此外,还必须指定是备份集的一部分的任何增量备份相同的-u选项。

    恢复与增量备份20120914081205的数据库,你需要的增量备份

    20120914081205和01207140955122,和完全备份20120514054532。

    为了与增量备份20130114051246恢复mytest的数据库,你只需要增量备份和完全备份20121114064330. restore命令将类似于此命令。

    gpdbrestore -t 20130114051246 -u /backupdir

     

    1.4.2    增量备份集

    要备份一组数据库表与增量备份,确定备份,当您创建完整备份与gpcrondump与--prefix选项设置。例如,创建增量备份在MYSCHEMA模式中的表,首先创建一个完整备份用一个前缀,如MYSCHEMA:

    gpcrondump -x mydb -s myschema --prefix myschema

    -s选项指定由MYSCHEMA模式来限定表都将包含在备份中。请参阅备份一组表以获得更多选项来指定一组表进行备份的。

    一旦你有一个完整的备份,你可以通过指定gpcrondump --incremental和--prefix选项,指定您为完整备份集前缀为同一组表的增量备份。增量备份会自动限制为只能在完全备份的表。例如:

    gpcrondump -x mydb --incremental --prefix myschema

     

    下面的命令列出了包含或排除了完全备份的表。

    gpcrondump -x mydb --incremental --prefix myschema--list-filter-tables

    1.4.3    从增量备份中恢复

     

    当gpdbrestore备份进行恢复时,命令行输出显示是否恢复类型是增量或完全数据库恢复。您不必指定备份的增量。例如,下面的gpdbrestore命令恢复最近的mydb数据库的备份。 gpdbrestore搜索db_dumps目录,找到它找到的备份最新的转储和显示信息。

     

    $ gpdbrestore -s mydb

    ...

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-

    [INFO]:-------------------------------------------

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Greenplum databaserestore

    parameters

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-

    [INFO]:-------------------------------------------

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Restore type =

    Incremental Restore

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Database to berestored =

    mydb

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Drop and re-createdb =

    Off

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Restore method =

    Search for latest

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Restore timestamp=

    20151014194445

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Restore compresseddump =

    On

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Restore globalobjects =

    Off

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-[INFO]:-Array faulttolerance =

    f

    20151015:20:10:34:002664 gpdbrestore:mdw:gpadmin-

    [INFO]:-------------------------------------------

    Continue with Greenplum restore Yy|Nn (default=N):

     

    gpdbrestore确保完整备份和其他所需的增量备份恢复备份前可用。随着--list备份选项,您可以显示执行恢复所需的完整备份和增量备份集。

    如果指定了gpdbrestore选项-q,备份的类型信息被写入到日志文件中。随着gpdbrestore选项--noplan,只能还原包含在增量备份中的数据。

     

    1.5       备份过程中的数据库锁

     

    当备份数据库,Greenplum的数据库锁定下表:

    1.当备份开始时,一个排它锁exclusive lock加在获取目录表的pg_class,其中包含数据库的相关信息。独占锁只允许并发读取操作。如表,索引和视图关系不能创建或数据库中删除。

    在pg_class被锁定后,schema information会收集将要备份的数据库表。

    当所有要备份的表都获取到access share lock之后,在pg_classs上的exclusive lock被释放。

    2. ACCESS SHARE锁在段实例级别的并行操作获得的。该数据已备份在一个段中的表之后,对在该段的表中的锁被释放。

    一个访问共享锁是由只有从表中读取查询,获取了锁。

    一个访问共享锁只能用ACCESS EXCLUSIVE锁冲突。下面的SQL语句获得一个ACCESS EXCLUSIVE锁:

    •                     ALTER TABLE

    •                     CLUSTER

    •                     DROP TABLE

    •                     REINDEX

    •                     TRUNCATE

    •                     VACUUM FULL

    1.6       使用 Direct I/O

    操作系统通常在内存中缓存文件I / O操作,因为内存访问比磁盘访问速度更快。应用程序写入到稍后刷新到存储装置中,通常是在一个Greenplum数据系统中的RAID控制器的一个内存块中。当应用访问的块仍驻留在内存中时,就避免了设备的访问。Direct I / O,您可以让应用程序直接写入到存储设备绕过缓存。这降低CPU消耗,消除了数据复制操作。Direct I / O对那些像备份文件等只需要一次处理的操作时非常有效的。

    注意:Direct I / O仅在Red Hat,CentOS的,和SUSE支持。

    开启 Direct I/O

    通过设置gp_backup_directIO 系统参数为 on来为备份启用Direct I/O:

    $ gpconfig -c gp_backup_directIO -v on

    如需检查direct I/O是否启用,用如下命令:

    $ gpconfig -s gp_backup_directIO

     

     

    当数据库忙时减少网络数据块传输到转储

    启用Direct I / O时,gp_backup_directIO_read_chunk_mb配置参数设置大小对于I / O块是以MB为单位。默认的块大小是20MB,此参数已经过测试的最佳参数。

    降低这个参数会增加了备份时间,导致了增加了变化不大的备份时间。

    要查找当前直接I / O块大小,输入以下命令:

    $ gpconfig-s gp_backup_directIO_read_chunk_mb

    下面的示例更改默认的块大小为10MB。

    $ gpconfig-c gp_backup_directIO_read_chunk_mb-v10

     

    1.7       Using Named Pipes

    Greenplum的数据库允许使用与gpcrondump和gpdbrestore备份和恢复的Greenplum数据库命名管道。当备份与常规文件的数据库,包含备份信息的文件被放置在了Greenplum数据段目录。如果段上的主机没有可用的备份足够的本地磁盘空间来的文件,你可以使用命名管道备份到外地的存储,例如存储在另一台主机在网络上或备份设备。

    备份与命名管道如果指定了--ddboost选项不被支持。

    要使用命名管道备份Greenplum数据库:

    1.               运行 gpcrondump 命令并带 -Ktimestamp 和 --list-backup-files.

    这个命令会创建两个文本文件包含了需要备份的文件,每行一个。文件名包含了你用-k timestamp指定的timestamp,并且包含有后缀后缀_pipes和_regular_files。例如:

    gp_dump_20150519160000_pipes

    gp_dump_20150519160000_regular_files

    在_pipes文件中列出的文件名命名管道被创建。在文件名_regular_files文件不应该命名管道创建。 gpcrondump和gpdbrestore使用备份期间在这些文件中的信息和还原操作。

    2.               在Greenplum所有的段上使用创建使用_pipes里的文件名来创建命名文件(named pipes)。

    3.               重定向每个命名管道的输出到目标进程或文件对象。

    4.               运行gpcrondump使用命名管道备份数据库。

    要建立一套完整的Greenplum的数据库备份文件,这些在_regular_files文件的文件也必须也被备份。

    如果要在还原备份过程中使用命名管道数据库

    To restore a database that used named pipes duringbackup

    1.               直接每个备份文件到它的命名管道的输入的内容,例如 cat filename >pipename, 如果备份文件是作为本地文件对象访问。

    2.               运行gpdbrestore命令恢复使用命名管道数据库。

    1.7.1    示例

    这个例子展示了如何通过使用命名管道和netcat的(NC)Linux命令网络备份数据库。该段写入备份文件命名管道的投入。命名管道的输出通过NC命令,这使得对TCP端口可用的文件输送。然后在其他主机上的进程可以连接到指定的端口段上的主机接收备份文件。此示例要求nc package软件包安装在所有Greenplum的主机。

    1.输入以下命令gpcrondump生成的备份文件列表,以便在/备份目录​​testdb数据库

    $ gpcrondump -x testdb -K 20150519160000--list-backup-files -u /backups

    2. 查看gpcrondump在/ backup目录下创建的文件:

    $ ls -lR /backups

    /backups:

    total 4

    drwxrwxr-x 3gpadmin gpadmin 4096 May 19 21:49 db_dumps

    /backups/db_dumps:

    total 4

    drwxrwxr-x 2gpadmin gpadmin 4096 May 19 21:49 20150519

    /backups/db_dumps/20150519:

    total 8

    -rw-rw-r-- 1gpadmin gpadmin 256 May 19 21:49 gp_dump_20150519160000_pipes

    -rw-rw-r-- 1gpadmin gpadmin 391 May 19 21:49 gp_dump_20150519160000_regular_files

    3. 查看_pipes文件的内容。

    $ cat/backups/db_dumps/20150519/gp_dump_20150519160000_pipes

    sdw1:/backups/db_dumps/20150519/gp_dump_0_2_20150519160000.gz

    sdw2:/backups/db_dumps/20150519/gp_dump_0_3_20150519160000.gz

    mdw:/backups/db_dumps/20150519/gp_dump_1_1_20150519160000.gz

    mdw:/backups/db_dumps/20150519/gp_dump_1_1_20150519160000_post_data.gz

    4. 创建对Greenplum数据段指定的命名管道。同时设立了命名管道读者。

    gpssh -h sdw1

    [sdw1] mkdir -p/backups/db_dumps/20150519/

    [sdw1] mkfifo/backups/db_dumps/20150519/gp_dump_0_2_20150519160000.gz

    [sdw1] cat/backups/db_dumps/20150519/gp_dump_0_2_20150519160000.gz | nc -l 21000

    [sdw1] exit

    完成这些步骤为每个在_pipes文件中列出的命名管道。一定要选择一个可用的TCP端口为每个文件。

    5. 在目标主机,接收像下面的命令备份文件:

    nc sdw1 21000> gp_dump_0_2_20150519160000.gz

    6.运行gpcrondump开始备份:

    gpcrondump -xtestdb -K 20150519160000 -u /backups

    与命名管道恢复的数据库,通过发送备份文件中的内容的命名管道的输入端反向备份文件的方向和运行gpdbrestore命令:

    gpdbrestore -xtestdb -t 20150519160000 -u /backups

    gpdbrestore readsfrom the named pipes' outputs.

     

     

    1.8       使用Data Domain Boost备份数据库

    EMC Data Domain Boost (DD Boost)是可以与gpcrondump和gpdbrestore实用工具一起工作用于执行更快的备份到EMC的Data Domain存储设备的EMC软件。 Data Domain在其存储的数据上执行数据去重,所以最初的备份操作后,各个应用程序就只指向那些不变的数据。这减少了在磁盘上的备份的大小。当在gpchrondump中使用DD Boost,Greenplum数据库参与了重复数据删除过程,减少了通过网络发送的数据量。当您从Data Domain系统中使用 Data Domain Boost恢复文件时,有些文件被复制到master本地磁盘并从那里被恢复,剩余的直接恢复。

    使用Data Domain Boost来管理文件复制,你可以复制一个Greenplum并存储到Data Domain系统以便进行灾难恢复。gpmfr程序管理Greenplumz在primary和远程的Data Domain系统中的数据备份集。有关gpmfr信息,请参阅Greenplum的数据库实用程序指南。

    当两个Data Domain系统之间使用的复制网络时,需要网络配置。

    •在Greenplum数据引擎系统需要使用gpcrondump配置Data Domain的登录凭据。证书必须为本地和远程Data Domain系统创建。

    •当非管理网络接口用于复制的Data Domain系统,静态路由必须在系统配置为复制数据流量传递到正确的接口。

    不要在pg_dump或者是pg_dumpall中使用Data Domain Boost。

    请参阅的Data Domain Boost文档的详细信息。

    重要提示:对于增量备份集,完整备份和相关的增量备份必须在单个设备上。例如,备份集都必须在文件系统上。备份集不能有本地文件系统和其他Data Domain系统上的一些备份。

    注意:您可以使用Data Domain的服务器作为NFS文件系统(不包括Data Domain的升压)执行增量备份。

    1.8.1    Data Domain Boost Requirements

    使用Data DomainBoost 需要以下。

    •               Data Domain Boost in included only with PivotalGreenplum Database.

    •               在Data Domain中购买并安装 EMCData Domain Boost 和 Replicator licenses.

    •      获取对Data Domain Boost 推荐的大小。确保DataDomain 系统能支持你的Greenplum集群中所有的段的足够的写和读。

     

    1.8.2     One-Time Data Domain Boost Credential Setup

    There is a one-time process to set up credentialsto use Data Domain Boost. Credential setup connects one Greenplum Databaseinstance to one Data Domain instance. If you are using the gpcrondump -­replicateoption or Data Domain Boost managed file replication capabilities for disasterrecovery purposes, you must set up credentials for both the local and remoteData Domain systems.

    To set up credentials, run gpcrondump with thefollowing options:

    一一ddboost-hostbdboost_ho stnaioe--ddboost-user--ddboost-backupdir backup_directory

    To remove credentials, run gpcrondump with the--ddboost-config-remove option.

    To manage credentials for the remote Data Domainsystem that is used for backup replication, include the - -ddboost-remoteoption with the other gpcrondump options. 例如, thefollowing options set up credentials for a Data Domain system that is used forbackup replication. The system IP address is 172.28.8.230, the user ID isddboostmyuser, and the location for the backups on the system is gpdb/

    gp_production:

    --ddboost-host 172.28.8.230 --ddboost-userddboostmyuser --ddboost-backupdir gp_production --ddboost-remote

    For details, see gpcrondump in the Greenplum Database Utility Guide.

    If you use two or more network connections toconnect to the Data Domain system, use gpcrondump to set up the logincredentials for the Data Domain hostnames associated with the networkinterfaces. To perform this setup for two network connections, run gpcrondumpwith the following options:

    --ddboost-host                                                               ddboost_hostnamel

    --ddboost-host ddboost_hostname2 --ddboost-userddboost_user --ddboost-backupdir backup_directory

    1.8.3    Configuring Data Domain Boostfor Greenplum Database

    After you set up credentials for Data Domain Boost onthe Greenplum Database, perform the following tasks in Data Domain to allowData Domain Boost to work with Greenplum Database:

    •               Configuring Distributed Segment Processing in DataDomain

    •               Configuring Advanced Load Balancing and LinkFailover in Data Domain

    •               Export the Data Domain Path to the DCA Network

    Configuring Distributed Segment Processing in Data Domain

    Configure the distributed segment processing optionon the Data Domain system. The configuration applies to all the DCA servers andthe Data Domain Boost plug-in installed on them. This option is enabled bydefault, but verify that it is enabled before using Data Domain Boost backups:

    #                ddboost option show

    To enable or disable distributed segmentprocessing:

    #                ddboost option set distributed-segment-processing{enabled 丨 disabled}

    ConfiguringAdvanced Load Balancing and Link Failover in Data Domain

    If you have multiple network connections on anetwork subnet, you can create an interface group to provide load balancing andhigher network throughput on your Data Domain system. When a Data Domain systemon an interface group receives data from the media server clients, the datatransfer is load balanced and distributed as separate jobs on the privatenetwork. You can achieve optimal throughput with multiple 1 GbE connections.

    Note: To ensure that interface groups functionproperly, use interface groups only when using multiple network connections onthe same networking subnet.

    To create an interface group on the Data Domainsystem, create interfaces with the net command. If interfaces do not alreadyexist, add the interfaces to the group, and register the Data Domain systemwith the backup application.

    1.             Add the interfaces to the group:

    #                       ddboost ifgroup add interface 192.168.1.1

    #                       ddboost ifgroup add interface 192.168.1.2

    #                       ddboost ifgroup add interface 192.168.1.3

    #                       ddboost ifgroup add interface 192.168.1.4

    Note: You can create only one interface group andthis group cannot be named.

    2.    Select one interface on the Data Domain system toregister with the backup application. Create a failover aggregated interfaceand register that interface with the backup application.

    Note: You do not have to register one of theifgroup interfaces with the backup application. You can use an interface thatis not part of the ifgroup to register with the backup application.

    3.              Enable ddboost on the Data Domain system:

    #                       ddboost ifgroup enable

    4.              Verify the Data Domain system configuration asfollows:

    #                       ddboost ifgroup show config

    Results similar to the following are displayed.

    Interface

    192.168.1.1

    192.168.1.2

    192.168.1.3

    192.168.1.4

    You can add or delete interfaces from the group atany time.

    Note: Manage Advanced Load Balancing and LinkFailover (an interface group) using the ddboost ifgroup command or from theEnterprise Manager Data Management > DD Boost view.

    1.8.4     Export the Data Domain Path to the DCA Network

    The commands and options in this topic apply toDDOS 5.0.x and 5.1.x. See the Data Domain documentation for details.

    Use the following Data Domain commands to exportthe /backup/ost directory to the DCA for Data Domain Boost backups.

    #                nfs add /backup/ost 172.28.8.0/24, 172.28.12.0/24(insecure)

    Note: The IP addresses refer to the Greenplumsystem working with the Data Domain Boost system.

    Createthe Data Domain Login Credentials for the DCA

    Create a username and password for the DCA toaccess the DD Boost Storage Unit (SU) at the time of backup and restore:

    #                user add user [password password] [priv {admin 丨 security丨 user}]

    1.8.5    Backup Options for Data DomainBoost

    Specify the gpcrondump options to match the setup.

    Data Domain Boost backs up files to the Data Domainsystem. Status and report files remain on the local disk.

    To configure Data Domain Boost to remove old backupdirectories before starting a backup operation, specify a gpcrondump backupexpiration option:

    • The -c option clears all backup directories.

    • The -o option clears the oldestbackup directory.

    To remove the oldest dump directory, specifygpcrondump --ddboost with the -o option. 例如, ifyour retention period is 30 days, use gpcrondump --ddboost with the -o option on day 31.

    Use gpcrondump --ddboost with the -c option toclear out all the old dump directories in db_dumps. The - c option deletes alldump directories that are at least one day old.

    1.8.6    Using CRON to Schedule a DataDomain Boost Backup

    1.              Ensure the One-Time Data DomainBoo^t Credential S^tup is complete.

    2.              Add the option --ddboost to the gpcrondump option:

    gpcrondump -x mydatabase -z -v --ddboost

    Important: Do not use compression with Data DomainBoost backups. The -z option turns backup compression off.

    Some of the options available in gpcrondump havedifferent implications when using Data Domain Boost. For details, seegpcrondump in the GreenplumDatabase Utility Reference.

    1.8.7    Restoring From a Data DomainSystem with Data Domain Boost

    1.              Ensure the One-Time Data DomainBoo^t Credential S^tup is complete.

    2.              Add the option --ddboost to the gpdbrestorecommand:

    $ gpdbrestore -t                                                                        Vackup_timestamp -v -ddboost

    Note: Some of the gpdbrestore options availablehave different implications when using Data Domain. For details, seegpdbrestore in the Greenplum Database Utility Reference.

     

    1.9       使用Symantec NetBackup备份数据库

    有关红帽企业Linux Greenplum数据引擎,您可以配置Greenplum数据与赛门铁克的NetBackup执行备份和还原操作。您配置Greenplum数据引擎和NetBackup,然后运行Greenplum数据gpcrondump或gpdbrestore命令。以下主题介绍了如何设置NetBackup和备份或还原的Greenplum数据库。

    •关于NetBackup软件

    •系统要求

    •限制

    •为NetBackup配置Greenplum数据主机

    •配置NetBackup for Greenplum数据引擎

    •利用NetBackup执行备份或恢复

    •实例的NetBackup备份和恢复命令

     

    1.9.1     关于NetBackup软件

    NetBackup中将包括以下服务器和客户端软件:

    •NetBackup主服务器管理的NetBackup备份,归档和恢复。主服务器负责媒体和设备为NetBackup选择。

    •NetBackup介质服务器是允许NetBackup使用连接到它们的存储设备,提供额外的存储NetBackup设备主机。

    •驻留在包含数据的Greenplum数据主机NetBackup客户端软件来进行备份。

    查看赛门铁克的NetBackup入门指南关于NetBackup信息。Symantec NetBackup Getting started Guide

     

    1.9.2    系统要求

    注:Greenplum数据使用NetBackup API(XBSA)与NetBackup进行通信。

    Greenplum的数据库使用的SDK版本的Symantec XBSA 1.1.0。

    •NetBackup客户端软件安装和Greenplum的数据库主主机和所有段上的主机上配置。

    NetBackup客户端软件必须能够与NetBackup服务器软件进行通信。

    •NetBackup主服务器版本7.5和NetBackup介质服务器7.5版

    •NetBackup客户端7.1或更高版本。

    限制

    •      NetBackup将不兼容DDBoost。 NetBackup和DDBoost不能在单个使用备份或恢复操作。

    •      对于增量备份集,完整备份和相关的增量备份,备份集必须在单个设备上。例如,备份集都必须是NetBackup系统上。备份集不能有NetBackup系统和其他本地文件系统或Data Domain系统上的一些备份。

     

    1.9.3     为NetBackup配置Greenplum数据主机

    您安装和Greenplum的数据库主主机和所有段上的主机上配置NetBackup客户端软件。

    1.安装在Greenplum数据主机上的NetBackup客户端软件。请参阅在UNIX系统上安装NetBackup客户端的信息,NetBackup安装文档。

    2.对Greenplum数据引擎主段上的主机NetBackup配置文件的/usr/openv/netbackup/bp.conf设置参数。设置每个Greenplum的数据库主机上的下列参数。

     

    Parameter

    Description

    SERVER

    Host name of the NetBackup Master Server

    MEDIA SERVER

    Host name of the NetBackup Media Server

    CLIENT NAME

    Host name of the Greenplum Database Host

    请参见Symantec NetBackup管理指南有关bp.conf文件的信息。Seethe Symantec NetBackup Administrator's Guide for information about the bp.conf file.

     

    3.设置Greenplum数据LD_LIBRARY_PATH环境变量主机使用NetBackup客户端

    7.1或7.5。 Greenplum的数据库附带的NetBackupSDK与NetBackup 7.1兼容的库文件

    和7.5客户端。要使用NetBackup 7.1或7.5客户端附带的Greenplum数据引擎,添加

    下面一行到文件$ GPHOME/greenplum_path.sh:

    LD_LIBRARY_PATH=$GPHOME/lib/nbuNN/lib:$LD_LIBRARY_PATH

    根据与您需要使用NetBackup客户端上75或71更换NN。

    该LD_LIBRARY_PATH行应这一行$GPHOME/greenplum_path.sh前加入:

    exportLD_LIBRARY_PATH

     

    4.执行此命令删除当前LD_LIBRARY_PATH值:

    unsetLD_LIBRARY_PATH

    5.执行这个命令来更新数据库Greenplum的环境变量:

    source$GPHOME/greenplum_path.sh

     

    请参见Symantec NetBackup管理指南有关配置的NetBackup服务器的信息。

    1.确保Greenplum数据引擎的主机被列为NetBackup服务器NetBackup客户端。

    在NetBackup管理控制台中,为NetBackup客户端的信息,媒体服务器,以及主服务器是在主机属性节点内的NetBackup管理节点。

    2.配置NetBackup存储单元。存储单元必须配置为指向一个可写的磁盘位置。

    在NetBackup管理控制台中,NetBackup存储单元的信息是NetBackup

    存储节点内部的管理节点。

    3.配置策略中的NetBackup备份策略和日程表。

    在NetBackup管理控制台中,在主服务器节点下的策略节点是你创建策略和策略的日程表。

    •                      In the Policy Attributes tab, these values arerequired for Greenplum Database:

    The value in the Policy type field must beDataStore

    The value in the Policy storage field is thestorage unit created in the previous step.

    The value in Limit jobs per policy field must be atleast 3.

    •                      In the Policy Schedules tab, create a NetBackupschedule for the policy.

     

    1.9.4    使用NetBackup执行备份或恢复

    在Greenplum数据gpcrondump和gpdbrestore实用程序支持选项来备份或恢复数据发送到NetBackup存储单元。当进行备份,Greenplum数据传输数据文件直接到NetBackup存储单元。没有备份的数据文件在Greenplum数据主机上创建。

    备份文件的元数据都存储在主机和备份到NetBackup存储单元。

    执行还原时,这些文件从NetBackup服务器检索,然后还原。

    以下是NetBackup的gpcrondump实用程序选项:

    --netbackup-service-host netbackup_master_server

    --netbackup-policy policy_name

    --netbackup-schedule schedule_name

    --netbackup-block-size size (optional)

    --netbackup-keyword keyword (optional)

    The gpdbrestore utility provides the followingoptions for NetBackup:

    --netbackup-service-host netbackup_master_server

    --netbackup-block-size size (optional)

    Note: When performing a restore operation fromNetBackup, you must specify the backup timestamp with the gpdbrestore utility-t option.

    The policy name and schedule name are defined onthe NetBackup master server. SeeConfiguringNetBackupfor Greenplum Database for information about policy name and schedulename. See the Greenplum DatabaseUtility Guide for information about the Greenplum Databaseutilities.

    Note: You must run the gpcrondump or gpdbrestorecommand during a time window defined for the NetBackup schedule.

    During a back up or restore operation, a separateNetBackup job is created for the following types of Greenplum Database data:

    •                Segment data for each segment instance

    •                C database data

    •                Metadata

    •                Post data for the master

    •                State files Global objects (gpcrondump -g option)

    •                Configuration files for master and segments(gpcrondump -g option)

    •                Report files (gpcrondump -h option)

    In the NetBackup Administration Console, theActivity Monitor lists NetBackup jobs. For each job, the job detail displaysGreenplum Database backup information.

    1.9.5     Example NetBackup Back Up and Restore Commands

    This gpcrondump command backs up the database customer andspecifies a NetBackup policy and schedule that are defined on the NetBackupmaster server nbu_serveri. A block size of 1024 bytes is used to transfer datato the NetBackup server.

    gpcrondump -x customer--netbackup-service-host=nbu_server1

    --netbackup-policy=gpdb_cust--netbackup-schedule=gpdb_backup --netbackup-block-size=1024

    This gpdbrestore command restores GreenplumDatabase data from the data managed by NetBackup master server nbu_server1. The option -t 20130530090000specifies the timestamp generated by gpcrondump when the backup was created.The -e option specifies that the target database is dropped before it isrestored.

    gpdbrestore -t 20130530090000 -e--netbackup-service-host=nbu_server1

     

    1.10     恢复Greenplum数据库

    如何还原从并行备份文件的数据库取决于你如何回答以下问题。

    1.    你备份的文件在哪? 如果你使用了gpcrondump在段服务器上创建了备份文件,那你可以用gpdbrestore来恢复数据库。如果你将利用gpcrondump将备份文件从Greenplum数据库集群移到了归档服务器,则使用gpdbrestore来恢复。

    2.    你是要重新创建Greenplum数据库系统,还是仅仅是恢复数据。如果Greenplum 系统在运行并且你仅需恢复数据,则使用gpdbrestore 。如果你丢失了整个集群并且需要从备份中重建数据库系统,则使用gpinitsystem。

    3.    是否将备份集恢复到具有相同数量的段的集群?如果你要还原到具有相同数量的段实例并且每个主机上都有相同的段实例,则使用gpdbrestore。如果你要将其迁移到一个不同配置的集群,则你只能使用非并行恢复。详情参阅See Restoring to a Different Greenplum SystemConfiguration.

    1.11    Restoring a Database Usinggpdbrestore

    gpdbrestore实用程序恢复由pcrondump创建的备份文件的数据库。

    该gpdbrestore需要以下选项来确定备份集来还原一个:

    •               -t timestamp -指定的时间戳恢复备份。

    •      -b YYYYYMMDr -还原段数据目录中的子目录db_dumps指定的日期的转储文件中。

    •      -s database_name - 恢复最新转储文件在他的段数据目录中找到指定的数据库。

    •               -r hostname:path - 恢复位于远程主机的指定目录中的备份集。

    要还原增量备份,你需要一套完整的备份文件,一个完全备份和任何所需的增量备份。您可以使用--list的备份选项列出由时间戳所指定的增量备份所需的全面,cremental备份集。 例如:

    $ gpdbrestore -t 20151013195916 --list-backup

    您可以使用--redirect数据库选项备份还原到不同的数据库。如果不存在,该数据库中创建。下面的示例恢复最新的mydb数据库到新的数据库名为mydb_snapshot的备份:

    $ gpdbrestore -s grants --redirect grants_snapshot

    您还可以还原备份到一个不同的Greenplum的数据库系统。请参阅恢复到不同的Greenplum的系统配置有关此选项的信息。 See Restoring to a Different Greenplum SystemConfiguration for information about this option.

     

    1.11.1 使用 gpdbrestore从归档服务器恢复

    使用gpdbrestore可以使用-R选项从保存在Greenplum集群之外的归档主机的备份进行恢复。尽管Greenplum的数据库软件不必须在远程主机上安装,远程主机必须有密码的ssh访问所有主机的Greenplum的集群中配置一个gpadmin帐户。

    这是必需的,因为每个段的主机将使用SCP从存档主机复制其段的备份文件。看到Greenplum的数据库实用程序指南(Greenplum Database Utility Guide)中gpssh-exkeys添加远程主机到群集的帮助。

    此过程假定备份集移出Greenplum的阵列到网络中的另一台主机。

    1.              确保归档主机是从Greenplum的master主机访问::

    $ping archive_host

    2.              确保您可以ssh与gpadmin账号,没有密码的远程主机。

    $ sshgpadmin@archive_host

    3.              确保您可以ping从归档主机主控主机:

    $ pingmdw

    4.              确保恢复的目标数据库中存在。例如:

    $createdb database name

    5.    从master运行gpdbrestore实用程序。 -r选项指定主机名和路径,一个完整的备份集:

    $gpdbrestore -R archive_host:/gpdb/backups/archive/20120714 -edbname

    如果数据库已创建,省略-e DBNAME选项。

     

    1.12        Restoring to a Different Greenplum System Configuration

    要使用gpdbrestore执行并行还原操作时,您要还原到系统必须具有相同的配置作为备份的系统。要还原数据库对象和数据到不同的系统配置,例如,将数据导入到一个更多段实例的系统,需要将并行备份文件加载到master节点并执行恢复。要执行非并行恢复,您必须:

    •      由gpcrondump操作创建一个完整的备份集。主的备份文件包含DDL来重新创建数据库对象。该段的备份文件包含的数据。

    •      一个运行着的Greenplum数据库系统。

    •      需要还原的数据库在系统中。

    段转储文件包含一个COPY命令的每个表,然后在分隔文本格式的数据。收集所有的转储文件的所有段的实例并运行它们通过主恢复你的数据和整个新的系统配置重新分配。

    恢复到配置不同的数据库系统

    1.             首先确保具备了全部的备份文件。包括Master的备份文件(gp_dump_1_1_timestamp, gp_dump_1_1_timestamp_post_data) and one for eachsegment instance gp_dump_0_2_timestamp,gp_dump_0_3_timestamp,gp_dump_0_4_timestamp,等等).。每个转储文件必须具有相同的时间戳关键。gpcrondump每段实例的数据目录下创建转储文件。你必须收集所有的转储文件,并将其移动到master的一个位置。你可以复制一个段的dump数据到master,加载后,删除,再复制其他段的数据。

    2.             确保在系统中,需要恢复的数据库已经存在. 例如:

    $createdb       database_name

    3.             装载Master备份文件以恢复数据库对象。例如:

    $ psqldatabase_name -f /gpdb/backups/gp_dump_1_1_20120714

    4.             加载每段转储文件来恢复数据。例如:

    $ psqldatabase_name -f /gpdb/backups/gp_dump_0_2_20120714

    $ psqldatabase_name -f /gpdb/backups/gp_dump_0_3_20120714

    $ psqldatabase_name -f /gpdb/backups/gp_dump_0_4_20120714

    $ psqldatabase_name -f /gpdb/backups/gp_dump_0_5_20120714

    ...

    5.    加载后的数据文件来恢复数据库对象,如索引,触发器,主键约束,等等.

    $ psql database_name -f/gpdb/backups/gp_dump_0_5_20120714_post_data

    6.             更新基于从原始数据库中的值的数据库序列。您可以使用系统工具,并用gunzipegrep的从原来的Greenplum数据主转储文件gp_dump_1_1_timestamp.gz序列值信息提取到一个文本文件中。此命令提取的信息到文件schema_path_and_seq_next_val。

     

    gunzip-c path_to_master_dump_directory/gp_dump_1_1_timestamp.gz | egrep "SETsearch_path|SELECT pg_catalog.setval"

    >schema_path_and_seq_next_val

    这个例子命令假定原来的Greenplum数据主转储文件是 /data/gpdb/master/gpseg-1/db_dumps/20150112.

     

    gunzip-c /data/gpdb/master/gpseg-1/db_dumps/20150112/

    gp_dump_1_1_20150112140316.gz

    |egrep "SET search_path|SELECT pg_catalog.setval" >

    schema_path_and_seq_next_val

     

    提取信息后,使用Greenplum数据PSQL工具来更新数据库中的序列。这个例子命令更新数据库test_restore的序列信息:

     

    psqltest_restore -f schema_path_and_seq_next_val

    展开全文
  • es数据备份和恢复

    万次阅读 2019-02-21 11:11:50
    Elasticsearch 5.x 数据备份和恢复可由 snapshot 模块来完成,snapshot模块可以通过文件共享系统为单个索引或整个集群远程创建快照进行数据恢复。 数据备份 索引快照时增量的。在创建快照前es会分析已有快照...

      

    Elasticsearch 5.x 数据备份和恢复可由 snapshot 模块来完成,snapshot模块可以通过文件共享系统为单个索引或整个集群远程创建快照和进行数据恢复。

    数据备份

    索引快照时增量的。在创建快照前es会分析已有快照仓库,只对上次备份后更改的内容进行增量备份。在创建备份时同一个集群中只能运行一个es snapshot进程。

    Es 基础命令

    创建快照仓库

    curl -X PUT "node1:9200/_snapshot/my_backup" -H 'Content-Type: application/json' -d'{ "type": "fs", "settings": { "location": "sys_backup" } }'

    查看已注册的快照仓库

    curl -X GET "node1:9200/_snapshot/my_backup"

    可以使用逗号间隔多个仓库,星号通配符匹配所有仓库名字,下面示例返回仓库名以repo开头的和包含backup的仓库信息:

    curl -X GET "node1:9200/_snapshot/repo*,*backup*"

    获取所有已注册快照仓库,省略仓库名或者使用_all

    curl -X GET "node1:9200/_snapshot"

    或者

    curl -X GET "node1:9200/_snapshot/_all"

    查看快照仓库列表

    curl -X GET "node1:9200/_cat/repositories?v"

    准备工作

    文件共享系统

    nfs、hdfs?

    共享文件系统仓库(“type”: “fs”)使用共享文件系统存快照,如果要注册共享文件系统仓库,必须在所有master和data节点挂载相同的共享文件系统到同一个路径位置。这个路径位置(或者它的一个父目录)必须在所有master和data节点的path.repo设置上注册。

    假设共享文件系统挂载到 /data/backups/es_backup ,应该在elasticsearch.yml文件中添加如下配置:

    path.repo: ["/data/backups", "/data/longterm_backups"]

    创建快照仓库

    所有节点重启之后,执行下面的命令注册名字为 es_backup 的共享文件系统仓库:

    curl -X PUT 'node1:9200/_snapshot/es_backup?verify=false' -H 'Content-Type: application/json' -d'{ "type": "fs", "settings": { "location": "/mount/backups/es_backup", "compress": true, "max_restore_bytes_per_sec": 50m, "max_snapshot_bytes_per_sec": 30m } }'

    如果使用相对路径,该路径将根据在path.repo中定义的第一个路径决定:

    curl -XPUT 'http://node1:9200/_snapshot/es_backup?verify=false' -H 'Content-Type: application/json' -d '{ "type": "fs", "settings": { "location": "es_backup", "compress": true, "max_restore_bytes_per_sec": 50m, "max_snapshot_bytes_per_sec": 30m } }'

    参数说明

    参数

    含义

    location

    快照存储位置

    compress

    是否压缩源文件,默认为true

    chunk_size

    如果有需要,可以将大文件分解为多个小文件,默认不开启

    max_restore_bytes_per_sec

    指定数据恢复速度,默认为 40m/s

    max_snapshot_bytes_per_sec

    指定创建快照时的速度,默认为 40m/s

    readonly

    设置为只读仓库,默认为false

    Repository Verification

    在创建一个仓库时,会即刻在集群所有节点验证确保其功能在所有节点可用,verify 参数可以用来取消该验证(如果想使用验证功能,创建仓库时去掉 ?verify=false 参数即可):

    curl -XPUT 'http://node1:9200/_snapshot/es_backup?verify=false' -H 'Content-Type: application/json' -d '{ "type": fs ... ... }'

    验证过程可以通过下面命令手动执行:

    curl -X POST "node1:9200/_snapshot/es_backup/_verify"

    Snapshot

    创建快照

    一个仓库可以拥有同一个集群的多个快照。在一个集群中快照拥有一个唯一名字作为标识。

    示例: 在仓库 es_backup 中创建名字为 test_snapshot 的快照,可以通过执行下面的命令来实现。

    curl -X PUT "node1:9200/_snapshot/es_backup/test_snapshot?wait_for_completion=true"

    参数 wait_for_completion 决定请求是在快照初始化后立即返回(默认),还是等快照创建完成之后再返回。快照初始化时,所有之前的快照信息会被加载到内存,所以在一个大的仓库中改请求需要若干秒(甚至分钟)才能返回,即使参数 wait_for_completion 的值设置为 false。

    默认情况下,创建一个快照会包含集群中所有打开和启动状态的索引。可以通过在创建快照的请求体中定义索引列表来改变这个默认处理:

    curl -X PUT "node1:9200/_snapshot/es_backup/test_snapshot_2?wait_for_completion=true" -H 'Content-Type: application/json' -d' { "indices": "index_1,index_2", "ignore_unavailable": true, "include_global_state": false }

    要包含到快照中索引列表可以使用支持多个索引语法的 indices 参数来指定。快照请求也支持 ignore_unavailable 选项,该选项设置为 true 时,在创建快照时会忽略不存在的索引。默认情况下,如果选项 ignore_unavailable 没有设值,一个索引缺失,快照请求会失败。

    通过设置 include_global_state 为 false,可以阻止集群全局状态信息被保存为快照的一部分。默认情况下,如果如果一个快照中的一个或者多个索引没有所有主分片可用,整个快照创建会失败,该情况可以通过设置 partial 为 true 来改变。

    快照名可以通过使用 date_math_expressions 来自动获得,和创建新索引时类似。注意特殊字符需要 URI 转码处理。

    例如,在名字中使用当前日期,比如 snapshot-2018.05.11,来创建快照,可以使用如下命令完成:

    # PUT /_snapshot/es_backup/<snapshot-{now/d}> curl -X PUT "node1:9200/_snapshot/es_backup/%3Csnapshot-%7Bnow%2Fd%7D%3E"

    创建快照:

    curl -X PUT "node1:9200/_snapshot/es_backup/syslog?wait_for_completion=true" -H 'Content-Type: application/json' -d' { "indices": "bash_history.log*,secure.log*,cron.log*", "ignore_unavailable": true, "include_global_state": false }

    查看快照信息

    curl -X GET "node1:9200/_snapshot/es_backup/syslog"

    这个命令返回快照的基本信息,包括开始合结束时间、创建快照的 ElasticSearch 版本、包含的索引列表、快照当前状态和快照期间产生的失败索引列表。快照的状态有:

    状态

    含义

    IN_PROGRESS

    正在创建快照

    SUCCESS

    快照创建成功

    FAILED

    快照创建完成,但是有错误,数据不会保存

    PARTIAL

    整个集群备份完成,但是至少有一个shard数据存贮失败,会有更具体报错信息

    INCOMPATIBLE

    创建快照的es版本和当前集群es版本不一致

    查看某仓库下所有快照信息:

    curl -X GET "node1:9200/_snapshot/es_backup/_all"

    查看当前正在运行的快照:

    curl -X GET "localhost:9200/_snapshot/my_backup/_current"

    删除快照

    从仓库中删除一个快照,使用如下命令:

    curl -X DELETE "node1:9200/_snapshot/es_backup/test_snapshot_2"

    当一个快照从仓库中删除,ElasticSearch 将删除该快照关联的但不被其他快照使用的所有文件。如果在快照创建的时候执行快照删除操作,此快照创建进程将终止且所有该进程已创建的文件也将被清理。所以,快照删除操作可以用来取消错误启动的长时间运行的快照操作。

    删除仓库

    可以使用下面命令注销仓库:

    curl -X DELETE "node1:9200/_snapshot/es_backup"

    数据恢复

    全量恢复

    快照可以通过执行以下命令恢复

    curl -X POST "node1:9200/_snapshot/es_backup/syslog/_restore"

    默认情况下,快照中的所有索引将被恢复,集群状态不被恢复。可以通过在恢复请求中使用 indices 和 include_global_state 选项来指定要恢复的索引和允许恢复集群全局状态。索引列表支持多索引语法。rename_pattern 和 rename_replacement 选项在恢复时通过正则表达式来重命名索引。设置 include_aliases 为 false 可以防止与索引关联的别名被一起恢复。

    curl -X POST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore" -H 'Content-Type: application/json' -d' { "indices": "index_1,index_2", "ignore_unavailable": true, "include_global_state": true, "rename_pattern": "index_(.+)", "rename_replacement": "restored_index_$1" }'

    恢复操作可以在正常运行的集群上执行。已存在的索引只能在关闭状态下才能恢复,并且要跟快照中索引拥有相同数目的分片。还原操作自动打开关闭状态的索引,如果被还原索引在集群不存在,将创建新索引。如果集群状态通过include_global_state (默认是 false)选项被还原,在集群中不存在的模板会被新增,已存在的同名模板会被快照中的模板替换。持久化设置会被添加到现有的持久化设置中。

    参考

    © 著作权归作者所有

    打赏点赞 (0)收藏 (8)

     分享

    举报

    上一篇:Linux环境变量

    下一篇:记一次centos 7内核升级事故

    阿dai学长

    粉丝 68

     

    博文 225

     

    码字总数 295497

     

    作品 0

     海淀

     

     运维

    关注 私信 提问

    相关文章最新文章

    Elasticsearch 备份和恢复

    备份步骤: 1、设置备份目录(用于存储备份文件): 进入es安装目录下面的config,编辑elasticsearch.yml加入: path.repo: ["/data/es_backup"] /data/es_backup:备份目录,根据自己情况进行...

    Zero零_度

     

    2016/11/04

     

     20

     

     0

    Elasticsearch 备份和恢复

    备份步骤: 1、设置备份目录(用于存储备份文件): 进入es安装目录下面的config,编辑elasticsearch.yml加入: path.repo: ["/data/es_backup"] /data/es_backup:备份目录,根据自己情况进行...

    打字猿

     

    2016/10/31

     

     821

     

     0

    Elastic大数据量迁移方法及注意事项

    一、需求 1 需求 ES集群ClusterA里的数据(某个索引或某几个索引),需要迁移到另外一个ES集群ClusterB中。 ES集群的索引有大有小,个别索引达到5T磁盘空间占用。 2 环境 Linux:Centos7 / C...

    wyl9527的博客

     

    2017/12/13

     

     0

     

     0

    大数据量Elastic数据迁移方法及注意事项

    一、需求 1 需求 ES集群ClusterA里的数据(某个索引或某几个索引),需要迁移到另外一个ES集群ClusterB中。 ES集群的索引有大有小,个别索引达到5T磁盘空间占用。 2 环境 Linux:Centos7 / C...

    wyl9527

     

    2017/12/13

     

     0

     

     0

    ElasticSearch数据备份与恢复

    ES备份快照的时候可以用或者。有点麻烦,我们使用。 1.安装hdfs插件(如果已安装,则忽略这一步): 注意下载后会提示是否安装,一定要输入 ,否则视为取消安装。 安装完之后要重启ES集群. 2...

    cjsoldier

     

    展开全文
  • HP Vertica数据库的备份和恢复

    千次阅读 2016-11-11 16:39:48
    Backing Up and Restoring the Database HP Vertica支持一个综合的应用,vbr.py...备份支持object-levelbackups,备份用户表。对于全库,可以创建全量或者增量的备份。如果存在一个全量的备份,我们可以恢复全库,

    Backing Up and Restoring the Database

    HP Vertica支持一个综合的应用,vbr.pyPython script,它的功能包括:back up, restore, list backups,把数据库复制到其他集群。备份支持object-levelbackups,备份用户和表。对于全库,可以创建全量或者增量的备份。如果存在一个全量的备份,我们可以恢复全库,也可以恢复一个或者多个数据库对象。使用vbr.py备份集支持的保存位置:

    A.    本地目录(the nodes in the cluster);

    B.    集群外的一个或者多个主机;

    C.    A different HP Vertica cluster(可以有效复制数据库)

    1 兼容性要求

    you cannot restore a version 6.x backup toa version 7.x database;

    HP Vertica does support restores within thesame major release.

    Forexample you can restore a version 7.0 backup to a version 7.1 database

    2 自动定期备份

    将vbr.py的运行参数放到一个脚本文件中。利用linux的cron定时调度备份操作。

    3 备份方式

    Vbr.py支持3中备份方式:

    a.     Full backups

    b.     Object-level backups

    c.     Hard link local backups

    我们可以通过用户自定义的描述名称来指示全库或者对象备份,比如FullDBSnap, Schema1Bak, Table1Bak

    注:

    recovery主要是处理数据一致性的问题--一个应用archivelog及redo

    restore单纯还原文件了

     

    3.1 全库备份

    一个全库的备份集包括:databasecatalog,用户模式,表和其他对象。备份集是数据库备份时刻的一个镜像或者快照。灾难恢复的时候,可以使用一个全量的备份集还原不完备或者损坏的数据。

             当一个全量备份集存在的时候,vbr.py在全量之后,创建一系列连续的快照,记录数据的变化。

             Archives包含了一系列想通名称的备份集。

    3.2 Object-Level备份

    一个object-level备份,包含了一个或者多个表或者用户;当一个对象的备份存在的时候,我们可以恢复它的全部内容,但是不能指定恢复其中的一个特定的。

    Note: HP Verticadoes not support object level backups on Hadoop Distributed File System

    (HDFS) storage.

             Object-Level备份支持如下基本的对象:

    可选择对象

    可以选择作为object-level备份一部分的对象,比如T1和T2表

    依赖对象

    由于依赖关系,必须作为备份集一部分的对象。比如,对一个包含外键的表创建备份集,则vbr.py因为表约束,自动包含主键的表。Projections也是依赖对象

    Principal objects

    The objects on which both selected and dependent objects depend are

    called principal objects. For example, each table and projection has an

    owner, and each is a principal object.

     

    3.3 本地备份的硬链接

    一系列的hard file links来匹配数据文件。A hard link local backup是数据库catalog(登记目录)的备份。

    4 什么时候备份数据库

    升级版本之前:Before you upgrade HP Vertica to another release。

    删除分区之前:Beforeyou drop a partition

    加载大的数据卷之后:Afteryou load a large volume of data.

    修改集群(添加删除更好节点)之后:Before and after you add, remove, or replace nodes in your databasecluster                                                                                                                   

    还原集群之后:After recovering a cluster from a crash。

     

    注:全库还原之后,集群也需要还原。所以更新集群配置之后,需要重新备份。

    When you restore a full database backup, you mustrestore to a cluster that is identical

    to the one on which you created the backup. For thisreason, always create a new full backup

    after adding, removing, or replacing nodes.

     

    5 配置备份主机

    使用vbr.py的配置文件,指定集群中的哪个节点备份到哪个主机上面。对于备份主机的要求:

    A.    有足够备份的磁盘空间。

    B.    集群可以通过SSH访问备份主机。

    C.    备份主机可以无密码SSH访问数据库的管理员用户。

    D.    备份主机的python和rsync版本和HP Vertica installer安装的版本相同。

    5.1 创建备份主机的配置文件

    注:考虑到备份的性能,推荐集群中的每个node备份到一个单独的备份主机上。

    for optimal network performance whencreating a backup, HP Vertica recommends having each node in the cluster use adedicated backup host。

    对于全量备份和对象基本的备份,创建分开的配置文件不同的名称的配置文件,对于相同的节点,相同的备份主机和备份目录。针对一个备份目录,最后只存放一个database的备份集。

    5.2 估算备份主机的磁盘需求

    首先,需要考虑增量备份的磁盘的容量。如果使用多个archive,磁盘容量还好增加。

    HP推荐每个备份主机的容量,是数据库使用空间的2倍(HP Vertica recommendsthat each backup host has space for at least twice the database footprint size)

             确认磁盘空间:

    select sum(used_bytes) fromstorage_containers where node_name='v_mydb_node0001';

    或者

    select node_name,sum(used_bytes) assize_in_bytes from v_monitor.storage_containers group

    by node_name;

    5.3 Log File估算日志文件的备份要求

    HP推荐每个备份主机给vbr.pylog files分配1GB的空间;log file不会自动删除,有必要手段删除。

             执行命令vbr.py—setupconfig配置配置文件和参数的时候,有个参数tempDir指定vbr.py在备份主机写日志。默认位置是在每个主机的/tmp/vbr目录下面。日志文件描述了进程,吞吐,每个node发生的任何报错。

    5.4 确定备份主机是可以访问的。

             在数据库节点和备份主机之间,防火墙需要允许ssh和rsync协议通过port 50000连接。备份主机的python和rsync版本和HP Vertica installer安装或支持的版本相同。

    5.5 设置无密码SSH访问

    【1】备份主机的访问账户,拥有写备份目录和日志目录(默认/tmp/)的权限。

             【2】相应的备份节点有用集群中任一节点的无密码ssh访问权限。

    5.6 增加备份主机SSH协议最大的连接数的设置

    多个数据库节点备份到一个备份主机的时候(N:1),SSH daemon(sshd)增加ssh连接数量的设置,默认每个host的ssh连接数是10;

    1. Log on as root to access the config file.

    2. Open the SSH configuration file (/etc/ssh/sshd_config) in a text editor.

    3. Locate the #MaxStartups parameter.

    4. Remove the comment character (#) and increase the value from the default of 10. 大于所有要连接主机的数量。

    5. Save the file.

    6. Reload the file using the following command:

    sudo /etc/init.d/sshd reload

    7. Exit from root.

     

    6 配置本地备份主机的Hard Link

    When specifyingthe backupHost parameter for your hard link local configuration files, use the databasehost names (or IP addresses) as known to Admintools, rather than the node names.Host names (or IP addresses) are what you used when setting up the cluster. Donot use localhost for the backupHost parameter.

    6.1 列出hostname

             selectnode_name, host_name from node_resources;

    7 创建vbr.py配置文件

    back up andrestore a full or object-level backup, or to copy a cluster,vbr.pyutility是通过配置文件来完成这些操作的。

    注:

    Note: You must be logged on as dbadmin, not root, to create the vbr configuration file.

             创建配置文件命令:

    #dbadmin用户执行。

    /opt/vertica/bin/vbr.py --setupconfig

    例如:

    [dbadmin@localhost ~]$ /opt/vertica/bin/vbr.py --setupconfig

    Snapshot name (backup_snapshot): fullbak

    Backup vertica configurations? (n) [y/n]: y

    Number of restore points (1): 3

    Specify objects (no default):

    Vertica user name (dbadmin):

    Save password to avoid runtime prompt? (n) [y/n]: y

    Password to save in vbr config file (no default):

    Node v_vmart_node0001

    Backup host name (no default): 127.0.0.1

    Backup directory (no default): /home/dbadmin/backups

    Config file name (fullbak1.ini):

    Change advanced settings? (n) [y/n]: n

    Saved vbr configuration to fullbak1.ini.

    7.1 指定一个备份名称

    Snapshot name (backup_snapshot):

    不能空白。备份名称,不需要添加时间。

    全库备份和对象备份的配置文件虽然不同,但是备份目录是相同的。

    例如:

    a full database backup, called fullbak.iniwould have these snapshotName and backupDir

    parameter values:

    snapshotName=fullbak

    backupDir=/home/dbadmin/data/backups

     

    The configuration file for the object-levelbackup, called objectbak.ini, would have these

    parameter values:

    snapshotName=objectbak

    backupDir=/home/dbadmin/data/backups

    7.2 备份Vertica Configuration File

    一定要备份数据库的配置文件。配置文件vertica.conf保存在catalog的目录。

    Enter y to include a copy of the vertica.conffile in the backup. The file is not saved by default:

    Backup vertica configurations? (n) [y/n]:

    The vertica.conf file containsconfiguration parameters you have changed. The file is stored in

    the catalog directory. Press Enter toaccept the default, or n to omit the file explicitly.

    7.3 保存多个还原点

    Number of restore points (1):

    指定还原点的数据量:默认为1。

    7.4 选择Full or Object-Level Backups

    Specify objects (no default):

    输入表名的形式为:schema.objectname

    输入多个表名或者schema名称,用逗号分开名称

    输入的名称,在配置文件的Objects parameter中列出来。

    7.5 输入User Name

    输入谁会调用vbr.py的用户:

    Vertica user name (dbadmin):

    7.6 保存账号密码

    vbr.py执行的时候,是否提示输入密码

    Save password to avoid runtime prompt? (n)[y/n]:

     

    7.7 指定 Backup Host and Directory

    应用列出集群中的每个节点:为没节点节点输入备份主机和目录

    Node v_vmart_node0001

    Backup host name (no default):

    Backup directory (no default):

    输入的配置信息保存在文件[Mapping] 选项卡中。如

    [Mapping]

    v_vmart_node0001 = 127.0.0.1:/home/dbadmin/backups

    7.8 保存配置文件

    输入一个配置文件的名称

    Config file name (fullbak.ini):

    注:由于配置文件默认保存在数据库集群上,为了防止文件丢失,最好copy一份到备份主机上面。

    7.9 Continuing to Advanced Settings

    Change advanced settings? (n) [y/n]:

    7.10 配置文件的例子

    [Misc]

    ; Section headings are enclosed by square brackets.

    ; Comments have leading semicolons.

    ; Option and values are separated by an equal sign.

    snapshotName = exampleBackup

    ; For simplicity, use the same temp directory location on

    ; all backup hosts. The utility must be able to write to this

    ; directory.

    tempDir = /tmp/vbr

    ; Vertica binary directory should be the location of

    ; vsql & bootstrap. By default it's /opt/vertica/bin

    ;verticaBinDir =

    ; include vertica configuration in the backup

    verticaConfig = True

    ; how many times to rety operations if some error occurs.

    retryCount = 5

    retryDelay = 1

    restorePointLimit = 5

    [Database]

    ; db parameters

    dbName = exampleDB

    dbUser = dbadmin

    dbPassword = password

    ; if this parameter is True, vbr will prompt user for db password every time

    dbPromptForPassword = False

    [Transmission]

    encrypt = False

    checksum = False

    port_rsync = 50000

    ; total bandwidth limit for all backup connections in KBPS, 0 for unlimited

    total_bwlimit_backup = 0

    ; total number of backup connections, -u for unlimited

    concurrency_backup = 0

    ; total bandwidth limit for all restore connections in KBPS, 0 for unlimited

    total_bwlimit_restore = 0

    ; total number of restore connections, -u for unlimited

    concurrency_restore = 0

    [Mapping]

    ; backupDir ignored for copy cluster task

    v_exampledb_node0001 = backup01:/home/dbadmin/backups

    v_exampledb_node0002 = backup02:/home/dbadmin/backups

    v_exampledb_node0003 = backup03:/home/dbadmin/backups

     

    7.11 改变Overwrite参数值

    针对对象级别的备份,如果配置文件以及存在,可以添加overrite参数。

    7.12 配置要求的VBR Parameters

    /opt/vertica/bin/vbr.py –setupconfig

    例子:

    > /opt/vertica/bin/vbr.py --setupconfig

    Snapshot name (snapshotName): ExampleBackup

    Backup Vertica configurations? (n) [y/n] y

    Number of restore points? (1): 5

    Specify objects (no default): dim, dim2

    Vertica user name (current_user): dbadmin

    Save password to avoid runtime prompt? (n)[y/n]: y

    Password to save in vbr config file (no default): mypw234

    Node v_example_node0001

    Backup host name (no default): backup01

    Backup directory (no default): /home/dbadmin/backups

    Node v_exampledb_node0002

    Backup host name: backup02

    Backup directory: /home/dbadmin/backups

    Node v_exampledb_node0003

    Backup host name: backup03

    Backup directory: /home/dbadmin/backups

    Config file name: exampleBackup.ini

    Change advanced settings? (n)[y/n]: n

    Administrator's Guide

    Backing Up and Restoring the Database

    HP

    7.13 配置高级的VBR Parameters

    port_rsync,The Port number forthe rsync daemon. The default value is 50000.

    retryCount,The number of timesto retry if a connection attempt fails. The default value is 2.

    tempDir,

    total_bwlimit_backup,The totalbandwidth limit in KBps for backup connections

    total_bwlimit_restore,The totalbandwidth limit in KBps for restore connections

    7.14 Configuring the Hard Link Local Parameter

    手动添加

    [Transmission]

    hardLinkLocal = True

    如果配置文件有高级参数,则

    [Transmission]

    encrypt = False

    checksum = False

    port_rsync = 50000

    total_bwlimit_backup = 0

    total_bwlimit_restore = 0

    hardLinkLocal = True

     

    8 使用Hard File Link Local Backups

    在数据库本地创建备份集,包括全库或者对象的。使用hard link local backups,对比远程有如下好处:

             A.速度, In a hardlink local backup, vbr.py does not copy files (as long asthe backup directory exists on the same file system as the database catalog anddata directories).

             B.减少网络活动:

             C.更少的磁盘空间。Sincethe backup includes a copy of the catalog and hard file links。

    since a hard link local backup saves a fullcopy of the catalog each time you run

    vbr.py, the disk size will increase withthe catalog size over time

             应用场景是开发设计阶段,备份一个用户或者表,当新的开发不成功的时候,可以快速的恢复。

    9 创建全量和增量的备份

    条件是:

    A.    数据库是运行的,down的节点是不会被备份的。

    B.    所有的备份主机是运行的,可用的。

     

    在数据库集群的发起节点,使用databaseadministrator 账号执行vbr.py脚本,但是不能是root用户。

    9.1 执行Vbr 不带可选参数

    执行vbr只需要如下选项:

    l --task backup

    l --config-file config_file

    例如

    > vbr.py --task backup --config-filemyconfig.ini Copying...

    Enter vertica password for user dbadmin:

    Preparing...

    FoundDatabase port: 5433

    [==================================================]100%

    All child processes terminatedsuccessfully.

    Committing changes on all backupsites...

    backup done!

    9.2 创建备份的最佳实践

    a.    Createseparate configuration files to create full- and object-level backups

    b.     Usethe same backup host directory location for both kinds of backups

    c.      Forbest network performance, use one backup host per cluster node

    d.     Useone directory on each backup-node to store successive backups

    e.     Forfuture reference, append the major Vertica version number to the configurationfile name(mybackup76x)

    9.3 Object-Level备份

    9.4 备份的位置和存储

    备份的目录,针对每个数据库节点创建一个子目录;然后针对每个备份集的名称创建子目录;

    备份集的名字就是配置文件中snapshotname参数指定的名字。

    9.5 保存增量备份

    当使用一个相同的配置参数的时候,vbr.py自动创建增量的备份;

    9.6 什么时候vbr.py删除旧的备份

    当存在的备份数量超过restorePointLimit的时候,删除备份集。

    Running the vbr.py utility with the --taskbackup command deletes the oldest backup whenever

    the total number that exist exceeds the restorePointLimitvalue in the configuration file.

    如果restorePointLimit = 5,则只保留5份备份集。

    10 备份的目录结构和内容

    Multiple Restore Points

    11 创建Object-Level的备份

    注:缺点

    if you create an object-level backup containing two schemas, schema1 and

    schema2, and later want to restore schema1, you cannot do so without also restoring schema2.

    To restore a single object, you can create a single object backup.

     

    11.1 调起vbr.py Backup

    vbr.py --task backup --config-fileobjectbak.ini

    11.2 备份路径和命名

    全量备份和对象备份使用一个顶级的目录;

    注:

    全量备份和对象备份不能使用相同的名称

    Note: You must use unique names for full- and object-level backups stored at one location.

    Otherwise, creating successive backups will overwrite the previous version.

    11.3 Object-Level的最佳实践

    l Create one configuration file for each object-level backup

    l Create a different configuration file to create a full database backup

    l For best network performance, use one backup host per cluster node

    l Use one directory on each backup-node to store successive backups

    l For future reference, append the major Vertica version number to theconfiguration file name(mybackup7x)

    11.4 命名惯例

    AIR1_daily_arrivals_snapshot

    AIR2_hourly_arrivals_snapshot

    AIR2_hourly_departures_snapshot

    AIR3_daily_departures_snapshot

    11.5 并发创建备份

    he vbr.py utility currently permits only oneinstance of the backup script per initiator node.

    l Assign one initiator node to createbackup for a given tenant.

    l Give each object backup initiated on adifferent node a unique backup name.

    l Start the backup script on differentinitiator nodes to create their specific tenant backups

    concurrently.

    11.6 确定备份频率

    Always take backups after any event thatsignificantly modifies the database

    11.7 理解Object-Level的内容

    对象级别的备份包括:

    a.     存储: Data files belonging to the specified object (s)

    b.     元数据:Including the cluster topology, timestamp, epoch, AHM, and so on

    c.     Catalog片段:persistentcatalog objects serialized into the principal and dependent objects

     

    11.8 Making Changes After an Object-Level Backup

    表或者用户被删除,随后的备份中这个用户或者表也被删除。如果不保存归档,那么这个表永远的丢失了。After creating an object-level backup, dropping schemas and tablesfrom the database means the objects will also be dropped from subsequentbackups. If you do not save an archive of the object backup, such objects couldbe lost permanently.

     

    备份之后,改变一个表名,随后恢复,那么这个表不会被还原。

    Changing a table name after creating atable backup will not persist after restoring the backup.

     

    如果删除了一个用户,但是备份的表属于这个用户(表是依赖对象),那么还原的时候,这个用户也会被还原。If you a drop a user after a backup, and the user is the owner ofany selected or dependent objects, restoring the backup also restores the user.

     

    To restore a dropped table from a backup:

    1. Rename the newly created table from t1 to t2. –OID不同的,名称也不同

    2. Restore the backup containing t1.

    3. Restore t1. Tables t1 and t2 now coexist(共存了)

     

     

     

    11.9 理解Overwrite 参数

    Owerwrite参数处理,对象备份的还原时候,存在两个相同的OIDS的时候。

    情形1:

    1. Create an object backup of mytable.

    2. After the backup, rename mytable to mytable2.

    3. Restoring the backup causes mytable to overwrite mytable2 (Overwrite=true).

    即使表名不一样了,但是OIDS是相同的。

    creating a new table of the same name (witha different OID) is handled differently.

    此时,会报错,因为表名相同,但是OIDS不同,因此owerrite机制失效。

    1. Create a table backup of mytable.

    2. Drop mytable.

    3. Create a new table, called mytable.

    4. Restoring the backup does NOT overwritethe table, and causes an error, since there is an OID

    conflict.

    11.10 改变Principal 和依赖对象

    【1】

    备份了一个表,删除了这个表属于的用,如果还原这个表的时候,会创建这个用户,按照备份时候的权限创建用。

    if you drop the owner of a table includedin a backup, restoring the snapshot recreates the user, along with anypermissions that existed when the backup was taken.

    【2】

    还原父对象的时候,子对象会被删除,重新一起还原。

    11.11 考虑约束引用

    涉及到某个关联的约束条件的全部数据库对象必须都备份。

    同一个用户的下的约束可以被还原,但是如果备份一个用户的外键在其他用户,出发外键所在的其他用户也一起被备份,否则不能还原约束;

    For example, a schema

    with tables whose constraints referenceonly tables in the same schema can be backed up, but a

    schema containing a table with an FK/PK constrainton a table in another schema cannot, unless

    you include the other schema in the list ofselected objects

    11.12 对象基本备份的配置文件

    vbr.py默认的配置为:不同的备份文件名称,相同的备份目录;

    经常是创建一个集群的配置文件,多个对象的配置文件,指向相同的位置;

    保存相同位置的好处:vbr.py有个额外的条款保证,在全库恢复还原的时候,对象基本的备份可以被使用;

    Note: Attempting to restore a full database using an object-level configuration file fails,

    resulting in this error:

    VMart=> /tmp/vbr.py --config-file=Table2.ini -t restore

    Preparing...

    Invalid metadata file. Cannot restore.

    11.13 Backup Epochs

    Each backup includes the epoch to which itscontents can be restored. This epoch will be close to

    the latest epoch, though the epoch couldchange during the time the backup is being written. If an

    epoch change occurs while a backup is beingwritten, the storage is split to indicate the different

    epochs.

    The vbr.py utility attempts to create anobject-level backup five times before an error occurs and

    the backup fails.

     

    11.14 最大数量的备份集

    每个备份目录,最多500个备份集。

    This maximum is set

    by rsync, and does not include archives, sothe total number of saved backups at the same location

    can exceed 500.

    For example, if a database has 500 schemas,S1 – S499, the full database, including archives of

    earlier snapshots, can be backed up alongwith backups for each schema.

    12 创建Hard Link Local 备份

    需要确保:

    数据库是运行的

    用户比如dbadmin有读写备份目录的权限;

    When you create afull- or object-level hard link local backup, these are the backup contents:

    Backup Catalog Database files

    Full backup : Full Copy Hard file links to all database files

    Object-level backup :Full copy Hard file links for all objects

    例如:

    /opt/vertica/bin/vbr.py--task backup --config fullbak.ini

    12.1 指定Hard Link Local Backup的位置

    如果参数hardLinkLocal=True,但是备份路径在其他节点上,会报错,停止备份;

    12.2 创建Hard Link Local Backups for Tape Storage

    【1】创建配置文件:

    /opt/vertica/bin/vbr.py –setupconfig

    【2】修改配置文件:

    [Transmission]选项包含hardLinkLocal=True.

    【3】执行备份选项

    /opt/vertica/bin/vbr.py --task backup--config-file localbak.ini

    【4】复制the hard link local backup directory到其他外部存储介质

    【5】当需要恢复还原数据库的时候,

    复制备份集到their original backup directory

    【6】使用之前的配置文件,进行数据的恢复

    /opt/vertica/bin/vbr.py --task restore--config-file localbak.ini

     

    13 中断备份过程

    放弃备份,use Ctrl+C or send a SIGINT to the Python process running the backuputility

    中断之后:

    【1】    备份的文件仍然存在

    【2】    重新执行,会断点继续执行The next backup process picks up where the interrupted process leftoff.

    14 查看备份集

    【1】        vbr.py来查看备份集。

    【2】        监控备份过程查看DATABASE_SNAHPSHOTS

    【3】     查看历史的备份信息:DATABASE_BACKUPS

    14.1 通过vbr.py列出备份集

    dbadmin@node01 temp]$/opt/vertica/bin/vbr.py --task listbackup --config-file /home/dbadm

    in/table2bak.ini

    包括:

    backup OID, the epoch, which object(s) (ifapplicable)

    were backed up, and the backup host(192.168.223.33) used for each node

    14.2 监控database_snapshots

    VMart=> select * fromdatabase_snapshots;

    node_name | snapshot_name |is_durable_snapshot | total_size_bytes | storage_cost

    14.3 监控database_backups

    注:

    However, do not use the backup_timestamp value whenrestoring an archive.

    VMart=>select * from v_monitor.database_backups;

    15 还原Full Database Backups

    条件为:

    1The database is down

    【2】The node names and the IP addresses must also be identical

    【3】数据库必须在集群上创建了。

    【4】the database name matches the name in the backup, and all of thenode names match the names of the nodes in the configuration file, you canrestore to it.

    15.1 Restoring the Most Recent Backup

    使用数据库管理员账户,不能使用root用;

    Thefollowing example uses the db.ini configurationfile, which includes the superuser's

    password:

    >vbr.py--task restore --config-file db.ini

    Copying...

    1871652633out of 1871652633, 100%

    Allchild processes terminated successfully.

    restoredone!

    15.2 Restoring an Archive

    当我们保存了多个备份的时候,使用一个archive来还原;

    列出所有的archives,选择一个区还原

    vbr.py –listbackup 还需要指定一个配置文件;

    --archive参数 加上目录名称的时间的后缀,例如

    > vbr.py --task restore --config-file fullbak.ini --archive=20121111_205841

    因此--archive参数指定了archive的子目录,OID指定了archive中的backup;

    An archive can comprise multiple snapshots,including both fulland

    object-level backups.

     

    15.3 试图还原一个正在运行的节点;

    全库还原的时候,node必须为down状态的;

    如果node是up的,会报错的,报错信息如下:

    doc:tests/doc/tools $ vbr.py --config-file=doc.ini -t restore --nodes=v_doc_node0001

    Warning: trying to restore to an UP cluster

    Warning: Node state of v_doc_node0001 is UP; node must be DOWN for restore; ignoring

    restore on this node.

    Nothing to do

    restore done!

    15.4 试图还原数据库到一个新的集群中

    还原全库的时候,node name和ip必须和备份的时候完全一模一样才能还原;

    The vbr.py utility does NOT supportrestoring a full database backup to an

    alternate cluster with different host namesand IP addresses.

    16 还原对象级别的备份

    还原数据库对象的时候,数据库必须是运行的;

    另外,不能还原数据库对象到一个空白的数据库中;

    You cannot restore an object-level backupinto an empty database.

    而且,我们只能还原所有的备份,不能还原备份的一部分;

    16.1 备份的位置

    全库备份和对象备份表存放在一个位置的缺点是,还原全库之后,再还原对象会报错;

    Note: Using different backup locations in which to create full- or object-level backups results in

    incompatible object-level backups. Attempting to restore an object-level backup after restoring

    a full database will fail.

     

    16.2 数据库对象还原的集群要求;

    全库备份和对象备份存放在一个位置;数据库down,还原全库备份之后,数据库on,然后还原对象的备份;

    对象还原的时候,不用管node的状态,会自动更新,把node加入到集群中,并且启动node;

    Regardless of the node states when a backupwas taken, you do not have to manage node states

    before restoring an object-level backup.Any node that is DOWN when you restore an object-level

    backup is updated when the node rejoins thecluster and comes UP after an object-level restore.

    16.3 集群拓扑改变之后的还原对象

    向集群中添加节点之后,vbr.py支持对象级别的还原;而且新增的node可以被updated;

     

    但是删除node,更改node的name,更改node的ip,vbr.py是不支持还原的;

     

    16.4 Projection Epoch After Restore

    所有的对象基本的备份和还原事件被当做DDL事件;

    If a table does not participate

    in an object-level backup, possibly due toa node being down, restoring the backup has this effect

    on the projection:

    l Its epoch is reset to 0

    l It must recover any data that it does nothave (by comparing epochs and other recovery

    procedures)

    16.5 在备份还原期间Catalog被锁定

    HP Vertica交易遵循严格的锁机制来保证数据的完整性;

     

    When restoring an object-level backup intoa cluster that is UP, vbr.py begins by copying data and

    managing storage containers, potentiallysplitting the containers if necessary. While copying and

    managing data is the largest task in anyrestore process, it does not require any database locks.

     

    After completing data copying tasks, vbr.pyfirst requires a table object lock (O-lock), and then a

    global catalog lock (GCLX).

     

    如果其他数据库进程的DML语句获得了表级锁(O-lock on the table),

    vbr.py is blocked from progress until theDML statement completes and

    releases the lock。

    GCLX 保证了cataLog的数据一致性完整性问题;。

     

    Database system operations, such as the tuple mover (TM) transferringdata from

    memory to disk, are canceled to permit object-level restore to complete

     

    16.6 Catalog还原事件

    每个对象级别的备份都包含了一部分database catalog,称为snippet,它包含可选择对象,依赖对象,父对象等;由于catalog snippet的结构和database的database catalog结构相同,

    当对象还原的时候,catalog shippet也会更新local和global catalog;

    17 还原Hard Link Local Backups

    If you have created both full- andobject-level backups and the database fails, first restore the full

    database backup. You can then restore fromthe object-level backups.

    17.1 避免OID和Epoch的冲突

    If you create full- and object-level backups in the same backupdirectory (recommended),

    进行全库还原的时候,vbr.py也会自动识别最新的oid和epoch的数据库对象备份

    vbr.py determines the latest OID and epochof the object-level backups as

    well.

    例如:

    1.Create a full hard link local backup in backup directory /home/dbadmin/backups, with

    configurationfile mybak.ini:

    [dbadmin@node01~]$ /opt/vertica/bin/vbr.py --task backup --config-file mybak.ini

    2.Create an object-level hard link local backup for Table1 using the same backup directory, with

    configurationfile table1bak.ini:

    [dbadmin@node01 ~]$ /opt/vertica/bin/vbr.py--task backup --config-file table1bak.ini

    3.Create an object-level hard link local backup for Table2, using the same backup directory, with

    configurationfile table2bak.ini.

    [dbadmin@node01 ~]$ /opt/vertica/bin/vbr.py--task backup --config-file table2bak.ini

    目录为:

    还原的时候发生如下的情况:

    【1】

    vbr.py detects the maximum object ID (OID)and epochs,并且在还原的数据库中更新;

    This prevents OID and epoch conflicts from

    occurring when object-level backups arerestored after the newly restored database

     

    【2】

    If the database and object-level tablebackups are not in the same backup directory, vbr.py

    reverts the maximum OID and epoch for afull database restore back to the table OID and epoch.

    Further attempts to restore either table1or table2 backups will then fail, preventing any

    potential conflicts.

     

    17.2 Transferring Backups to and From Remote Storage

    to another storage media, such as tape。

    Completethe following steps to restore hard link local backups from external media:

    1. Ifthe original backup directory no longer exists on one or more local backup hostnodes,

    recreatethe directory. The directory structure into which you restore hard link backupfiles

    must beidentical to what existed when the backup was created. For example, if youcreated

    hardlink local backups at the following backup directory, then recreate that directorystructure:

    /home/dbadmin/backups/localbak

    2. Copythe backup files to their original backup directory, as specified for each nodein the

    configurationfile with the backupHostandbackupDir parameters. For example, this

    configurationfile shows the backupDirparameter forv_vmart_node0001:

    [Mapping0]dbNode= v_vmart_node0001

    backupHost = node03

    backupDir = /home/dbadmin/backups/localbak

    3. Torestore the latest version of the backup, move the backup files to thisdirectory:

    /home/dbadmin/backups/localbak/node_name/snapshotname

    4. Torestore a different backup version, move the backup files to this directory:

    /home/dbadmin/backups/localbak/node_name/snapshotname_archivedate_timestamp

    5. Whenthe backup files are returned to their original backup directory, use theoriginal

    configurationfile to invoke vbr.pyas follows:

    >/opt/vertica/bin/vbr.py--task restore --config-file localbak.ini

    If thephysical files are restored from tape into the correct directories, and you usethe

    configurationfile that specifies hardLinkLocal= true, restoring thebackup succeeds.

     

    18 还原数据库到相同的集群

    把一个全库备份还原一个相同的集群的数据库的一般步骤:

    1. Stopping thedatabase you intend to restore.

    Note: If you restore datato a single node, the node has already stopped. You do not need

    to stop the database.

     

    2. Restoring the Database (vbr.py).

     

    3. Starting thedatabase.

    Note: If you restored allthe nodes using the backup, you are using a manual recovery

    method. For moreinformation, see the Failure Recovery in the See Also section below.

    Administration Toolsreturns the message, "Database startup failed," after you attempt to

    restart the databaseand then offers to restart the database from an earlier epoch. Click

    Yes.

     

    4. After thedatabase starts, connect to it through the Administration Tools or MC andverify that it was successfully restored by running some queries.

    19 Removing Backups

    1.       Use vbr.py --task listbackupto identify the backup and archivenames that reside on the local or remote backup host (requires a configurationfile).

    2.      Delete the backup directories

    19.1 Deleting Backup Directories

    dbadmin@node01 temp]$/opt/vertica/bin/vbr.py --task listbackup --config-file /home/dbadm

    in/table2bak.ini

     

    snapshotName

     backupHost

     backupDir

    dbNode

     

    3. Connect to the backup host.

    4. Navigate to the backup directory (thebackupDir parameter value in the configuration file).

    5. To delete all backups, delete thetop-level snapshot directory

    -or-

    6. To delete an archive, navigate to thesubdirectory for each database node, located below the

    top-level snapshot directory, and deletethe archive directory.

     

    20 Copying the Database to Another Cluster

    例如,在生产环境和开发环境之间,复制数据库。

    存放HP Vertica catalog , data, and temp directories的存储路径,在目录库和源库之间,必须完全相同的。查看源库的目录结构:

    VMart=> \xExpanded display is on.

    VMart=> select node_name,storage_path, storage_usage from disk_storage;

    -[ RECORD 1 ]-+-----------------------------------------------------

    node_name | v_vmart_node0001

    storage_path | /home/dbadmin/VMart/v_vmart_node0001_catalog/Catalog

    storage_usage | CATALOG

    -[ RECORD 2 ]-+-----------------------------------------------------

    node_name | v_vmart_node0001

    storage_path | /home/dbadmin/VMart/v_vmart_node0001_data

    storage_usage | DATA,TEMP

    -[ RECORD 3 ]-+-----------------------------------------------------

    node_name | v_vmart_node0001

    storage_path | home/dbadmin/SSD/schemas

    storage_usage | DATA

    -[ RECORD 4 ]-+-----------------------------------------------------

    node_name | v_vmart_node0001

    storage_path | /home/dbadmin/SSD/tables

    storage_usage | DATA

    -[ RECORD 5 ]-+-----------------------------------------------------

    node_name | v_vmart_node0001

    storage_path | /home/dbadmin/SSD/schemas

    storage_usage | DATA

    -[ RECORD 6 ]-+-----------------------------------------------------

    node_name | v_vmart_node0002

    storage_path | /home/dbadmin/VMart/v_vmart_node0002_catalog/Catalog

    storage_usage | CATALOG

    -[ RECORD 7 ]-+-----------------------------------------------------

    node_name | v_vmart_node0002

    storage_path | /home/dbadmin/VMart/v_vmart_node0002_data

    storage_usage | DATA,TEMP

    -[ RECORD 8 ]-+-----------------------------------------------------

    node_name | v_vmart_node0002

    storage_path | /home/dbadmin/SSD/tables

    storage_usage | DATA

    20.1 Identifying Node Names for Target Cluster

    select node_name from nodes;

    You need to know the exact names thatAdmintools supplied to all nodes in the source database

    before configuring the target cluster.

    To run Admintools from the command line, enter a command suchas this for the VMart database:

    $ /opt/vertica/bin/admintools -t node_map -dVMART

    20.2 Configuring the Target Cluster

    l  Have the same number of nodes the sourcecluster.

    l  Have a database with the same name as thesource database. The target database can be

    completely empty.

    l  Have the same node names as the source cluster.The nodes names listed in the NODES

    system tables on both clusters must match.

    l  Be accessiblefrom the source cluster.

    l  Have the same database administrator account,and all nodes must allow a database

    administrator of the source cluster to login through SSHwithout a password.

     

    注:

    You need to configure each host in the targetcluster to accept the SSH

    authentication of the source cluster.

     

    l  Haveadequatedisk space for the vbr.py --task copycluster command to complete.

     

    20.3 Creating a Configuration File for CopyCluster

    You cannot use an object-level backup withthe copycluster command. You must use a full

    database backup.

     

    [Misc]

    snapshotName = CopyVmart

    verticaConfig = False

    restorePointLimit = 5

    tempDir = /tmp/vbr

    retryCount = 5

    retryDelay = 1

    [Database]

    dbName = vmart

    dbUser = dbadmin

    dbPassword = password

    dbPromptForPassword = False

    [Transmission]

    encrypt = False

    checksum = False

    port_rsync = 50000

    [Mapping]

    ; backupDir is not used for cluster copy

    v_vmart_node0001= test-host01:/home/dbadmin/backups

    v_vmart_node0002= test-host02:/home/dbadmin/backups

    v_vmart_node0003= test-host03:/home/dbadmin/backups

    20.4 Copying the Database

    The target cluster must be stopped beforeyou invoke copycluster

    目标集群需要stop

    To copy the cluster, run vbr.py from a nodein the source database using the database

    administrator account, passing the --taskcopycluster --config-file CopyVmart.ini

    command.

    > vbr.py --config-fileCopyVmart.ini --task copyclusterCopying...

    1871652633 out of 1871652633, 100%

    All child processes terminatedsuccessfully.

    copycluster done!

    21 Backup and Restore Utility Reference

    21.1 VBR Utility Reference

    语法:

    /opt/vertica/bin/vbr.py { command }

    ... [ --archive file ]

    ... [ --config-file file ]

    ... [ --debug <em+>level</em>]

    ... [ --nodes node1 [, noden, ...] ]

    ... [ --showconfig ]

    【1】

    --setupconfig

    【2】

    --task {backup| copycluster| listbackup|restore }

    backup creates afull-database, or object-level backup,

    depending on what you have specified in the

    configuration file

    l copycluster copiesthe database to another HP

    Vertica cluster.

    l listbackup displaysthe existing backups associated

    with the configuration file you supply. Use the

    information in this display to get the name of a snapshot

    you want to restore. See the Related Tasks section for

    more infromation about restoring the database.

    l restore Restoresa full- or object-level database

    backup. Requires a configuration file.

    【3】

    --archive file Used with --task backup or--task restore commands

    【4】

    --config-file file

    【5】

    --nodes node1[,...]

    【7】

    --debug level

    【6】

    --showconfig

    21.2 VBR Configuration File Reference

    21.2.1 [Misc] Miscellaneous Settings

    【1】snapshotName

    【2】tempDir /tmp

    【3】verticaBinDir /opt/vertica/bin

    【4】verticaConfig False 

    Indicates whether the HP Verticaconfiguration file is

    included in the backup, in addition to thedatabase data.

    【4】    restorePointLimit 1

    【5】    overwrite True

    【6】    retryCount 2

    【7】    retryDelay 1

    21.2.2 [Database] Database Access Settings

    21.2.3 [Transmission] Data Transmission During Backup

    port_rsync 50000

    hardLinkLocal False

    port_ssh_backup 22

    21.2.4 [Mapping]

    [Mapping]

    v_vmart_node0001 =127.0.0.1:/home/dbadmin/backups

     

     

    **************************************************************
    ** 欢迎转发,注明原文:blog.csdn.net/clark_xu   徐长亮的专栏
    ** 谢谢您的支持,欢迎关注微信公众号:clark_blog 
    **************************************************************

     

    展开全文
  • MongoDB的数据库如何备份和恢复

    千次阅读 2017-07-07 13:56:33
    摘要: MongoDB数据库如何备份恢复MongoDB数据库应如何操作?最近数据库多灾多难,这些问题也成为开发者关注的重点。2016年12月爆出MongoDB数据库安全问题(见MongoDB黑客赎金事件解读及防范)。 MongoDB...
  • Oracle DB 执行用户管理的备份和恢复

    千次阅读 2013-10-13 17:27:54
    • 说明用户管理的备份和恢复与服务器管理的备份和恢复之间的差异 • 执行用户管理的数据库完全恢复 • 执行用户管理的数据库不完全恢复 备份和恢复的使用类型 数据库备份和恢复的类型包括: • 用户管理的...
  • MySQL数据库的维护、备份和恢复

    千次阅读 2015-05-20 12:35:33
    MySQL的备份恢复 预防性维护 激活mysql服务器的自动恢复能力 定期对数据表进行检查 在线维护数据库只适用于MyISAM 只读方式锁定 读写方式锁定 制定一份数据库备份计划 1 用mysqldump程序制作文本备份 2 使用...
  • MySQL 数据库备份和恢复探讨(全量mysqldump 增量mysqlbinlog)
  • Ubuntu14.04如何备份和恢复系统

    千次阅读 2014-12-20 14:04:53
    Ubuntu14.04如何备份和恢复系统 安装好Ubuntu之后,别忘了安装 for linux 防火墙杀毒软件。 在备份系统前,请保证系统是无错干净的: 本人操作系统是ubuntu14.04,不知道是系统出了问题还是装的...
  • PX-Backup — K8S上备份和恢复应用的最佳方式 Portworx近期发布了最新版本的PX-Backup。PX-Backup允许用户通过简单的点击即可备份和恢复所有的Kubernetes应用,从而提供了强有力的数据保护,而数据保护对DevOps...
  • 在这种情况下,系统软件数据备份和恢复就成为我们平时日常操作中一个非常重要的措施,本文从系统软件备份和恢复、常用软件备份和恢复两个方面提供了完整的解决方案。 <br />一、Windows XP系统备份/恢复方案...
  • 1、电脑qq聊天记录的备份恢复的方法 2、电脑WeChat聊天记录的恢复:  这个恢复方法是建立在你电脑中还有该聊天记录的数据的前提下。  如果 WeChat 安装在C盘,需拷贝出下图中的文件管理路径中的 All User ...
  • postgres物理备份恢复

    千次阅读 2016-04-11 17:08:28
    postgres物理备份恢复 学习环境:centos 6.5 64  数据库:postgres 9.5.1 1冷备份恢复 文件系统级别的备份是冷备份,需要停止数据库。 1.1操作步骤 (1)停止数据库 pgdb_ctl -D /pgdb/data stop -m fast  (2)...
  • 首先我们得把老服务器上的Gitlab整体备份,使用Gitlab一键安装包安装Gitlab非常简单, 同样的备份恢复与迁移也非常简单. 使用一条命令即可创建完整的Gitlab备份。 gitlab-rake gitlab:backup:create...
  • Oracle®数据库备份和恢复快速入门指南 10g第2(10.2) B14193-03 2005年11月 Oracle数据库备份和恢复快速入门指南有三个目的: 。介绍Oracle数据库的备份和恢复的基本概念,恢复管理器(RMAN),以及Oracle...
  • etcd 备份恢复

    千次阅读 2018-01-06 11:46:10
    etcd 是一款开源的分布式一致性键值...etcd 目前最新的版本的 v3.1.1,但它的 API 又有 v3 v2 之分,社区通常所说的 v3 与 v2 都是指 API 的版本号。从 etcd 2.3 版本开始推出了一个实验性的全新 v3 版本 AP
  • 使用xtrabackup对MySQL进行备份和恢复

    万次阅读 热门讨论 2011-08-12 16:04:11
    Xtrabackup 是percona公司的开源项目,用以实现类似innodb官方的热备份工具InnoDB Hot Backup的功能,能够非常快速地备份恢复mysql数据库。 Xtrabackup中包含两个工具: xtrabackup是用于热备份innodb, xtradb表...
  • BAREOS(来自于BAckup and REcovery Open Sourced的缩写)是源于...我们选用Bareos的主要原因是Bareos的Web界面支持完整的备份和恢复功能(不支持配置,配置仍需要通过CLI完成),另一个原因是Bareos的社区较为活跃。
  • Oracle DB 备份和恢复的概念

    千次阅读 2013-10-11 14:22:31
    • 说明检查点、重做日志文件归档日志文件的重要性 • 配置快速恢复区 • 配置ARCHIVELOG模式   部分工作内容 数据库管理员的职责包括: • 尽量避免数据库出现故障 • 延长平均故障间隔时间(MTBF) • 通过...
  • gitlab备份恢复

    万次阅读 2018-09-03 09:51:18
    因为公司代码仓库是用gitlab,最近一直在想数据丢失了如何处理,硬盘坏了如何处理,今天好好研究了下,发现gitlab备份还是挺简单的。 首先设定备份目录我设置的本地目录是/usr/backup vim /etc/gitlab/gitlab.rb ...
  • Oracle数据库的备份恢复 在Oracle数据库的使用过程中,备份恢复是经常遇到的操作。Oracle中的备份分为两大类:逻辑备份和物理备份。其中物理备份又分为两类:冷备份和备份。本节将简要讲述如何利用各种备份...
  • Svn备份恢复

    千次阅读 2012-08-28 22:30:20
    Svn备份恢复有感  今天的主要任务是对svn的备份恢复进行测试,但是测试的过程中,也出现的一些问题,现在写出来与大家进行分享,希望对大家有所帮助。 这里我介绍两种备份方式:完全备份和增量备份。 首先...
  • Ghost 系统备份恢复(图解)

    千次阅读 2013-04-25 20:58:54
    但是自从Ghost9之后,它就只能在windows下面运行,提供数据定时备份、自动恢复与系统备份恢复的功能。  本文将要介绍的是Ghost 11.x系列(最新为11),它在DOS下面运行,能够提供对系统的完整备份恢复,支持的...
  • gitlab备份恢复

    千次阅读 2016-07-29 16:46:50
    使用Gitlab一键安装包安装Gitlab非常简单, 同样的备份恢复与迁移也非常简单. 使用一条命令即可创建完整的Gitlab备份: gitlab-rake gitlab:backup:create 使用以上命令会在/var/opt/gitlab/backups目录下创建一...
  • 添加镜像地址的目的是为了提高国内用户软件下载的速度,编辑(新建)文件gitlab-ce.repo,指令: vi /etc/yum.repos.d/gitlab-ce.repo 输入: [gitlab-ce] name=gitlab-ce # 清华大学的镜像源 baseurl=...
  • oracle dbf恢复 Oracle 11g R2 备份恢复

    千次阅读 2018-07-19 14:30:47
    如何从另一个节点上将Rman备份恢复到本地不同的目录结构中 环境条件 Rman备份在节点1上 数据库不得不将备份恢复到节点2上 节点2节点1上的目录结构并不相同。 Rman备份不得不传输到节点2的新的位置上进行使用...
  • 不要在应用商店下载最新版本安装,使用刚备份的安装包安装) 恢复Soul应用的数据文件到新手机上 adb restore D:\adb\soulbackup.ab D:\adb\ 备份数据文件的保存目录 soulbackup.ab 备份文件的名字,ab是扩展名 须知 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 62,266
精华内容 24,906
关键字:

备份和恢复最新版下载