精华内容
下载资源
问答
  • 备份和恢复最新版下载
    千次阅读
    2019-07-18 14:05:10

    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

    更多相关内容
  • 特征备份和还原主题数据备份和还原消费者组偏移量当前仅支持到/从本地文件系统备份/还原作为jar文件发布或打包为Docker映像入门选项A)下载二进制文件下载最新版本并解压缩。 选项B)使用Docker映像从提取最新的...
  • 可以从备份镜像中,选出您需要恢复的个人文件文件夹,而不需要完整地恢复整个备份。 Outlook恢复 为Outlook ExpressOutlook 2003/2007/2010/2013提供完善的恢复方案。 PXE 服务器 无需启动媒介,PXE服务器进行...
  • 10.4 备份恢复目录 206 10.5 恢复目录视图 206 10.5.1 RC_ARCHIVED_LOG(V$ARCHIVED_LOG) 207 10.5.2 RC_BACKUP_CONTROLFILE(V$BACKUP_DATAFILE) 207 10.5.3 RC_BACKUP_CORRUPTION(V$BACKUP_CORRUPTION)...
  • 1.「新」iOS备份的资料「无法」恢复到旧的iOS系统上; 2.「旧」iOS备份的资料「能够」恢复到新版iOS系统上。 (注:「新」指升级后的新版本号;「旧」指升级前的版本号) 所以升级「新」iOS前最重要...


    新买的iPhone,如何将老款iPhone里的资料恢复到新iPhone?

    也有一些小伙伴提出万一苹果手机突然坏了,该如何恢复资料?

    防患于未然,因而资料备份显得尤为重要。

    谈及备份,首先要了解iOS 备份资料恢复机制

    1.「新」版iOS备份的资料「无法」恢复到旧版的iOS系统上;

    2.「旧」版iOS备份的资料「能够」恢复到新版iOS系统上。

    (注:「新」版指升级后的新版本号;「旧」版指升级前的版本号)

    所以升级「新」版iOS前最重要工作是先备份「旧」版iOS上的资料!下面教大家如何做好iPhone资料备份

    牛学长苹果数据管理工具备份、iCloud备份(基本不用)、iTunes 备份的利与弊

    iCloud备份:(不介绍了)

    优点:通过无线网络可以将备份的资料同步到你登陆同个 Apple ID 的设备上。

    缺点:iCloud容量有限只有5G免费容量,如果手机内部资料过多,则需要付费增加额外容量。且备份受网速限制比较大。

    牛学长苹果数据管理工具备份:

    优点:比较灵活,可自由选择全备份和分类备份,选择性比较大,能自由选择备份和恢复的数据。

    备份步骤:

    步骤:打开牛学长苹果数据管理工具,将iPhone连接到电脑,点“备份/恢复-设备”,在备份数据界面中可以选择性将你需要的数据都单独备份到电脑,可备份和恢复的项目有照片、音乐、通讯录、应用等,然后点“备份”按钮即可。

    iTunes备份:

    优点:作为苹果官方软件,备份更安全,可以对备份数据进行加密,增加安全性。

    缺点:无法单独将备份中的数据进行导出,如果只需要某一首音乐或一段视频,无法单独导出,只能将备份完全导出。

    备份步骤:

    在电脑端/Mac端下载最新版本iTunes

    安装成功后,打开iTunes,连接上自己的iPhone设备,左上角会跳出「iPhone图案」点选一下那按钮。(如果iTunes跳出有可更新系统,先点击取消,待备份过后再更新)

    点开将会看到iPhone设备相关信息,在备份区域选单中,备份方式选择「这部电脑」,随后再点右方的「立即备份」按钮,这时iTunes就会开始将这台设备内所有资料进行备份,等全部备份跑完即可完成资料备份。

    等待备份完成过后,即可放心更新刷到「新」版iOS。

    备份资料还可以恢复到新的iPhone上,恢复系统完成后也可以用 iTunes 恢复备份。

    展开全文
  • 我们将重新下载用户的所有应用,并为每个参与备份和恢复的应用传输多达 2GB 的数据。 △ 云备份恢复数据 如果用户的旧设备目前不在身边,则可以从之前创建的云备份恢复数据。这是因为 Android 设备上的应用数据...

    随着移动设备厂商不断推出新的型号,用户更换设备的频率也越来越频繁。替换新机时,最让用户头疼的问题之一就是数据迁移了。那么不完善的数据迁移会给用户带来哪些糟糕体验呢?我们从下面的案例来看看用户的烦恼。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fvpqBuZP-1643273213844)(https://devrel.andfun.cn/devrel/posts/2022/01/lrjbPj.jpg)]

    Sally 的烦恼

    她叫 Sally,Sally 是一位食品微生物学家,她有一份很棒的工作,这份工作让她很忙碌,甚至精疲力尽。

    在实验室辛苦工作一天后回到家,她最喜欢的就是在手机上玩休闲游戏。

    Sally 喜欢她的手机,她在 2017 年买了这部手机,方便她在上下班路上刷美剧 The Good Place (善地)。不过现在她主要在手机上玩游戏。然而这部手机已经没有之前那么好用了。

    Sally 去了当地的手机专卖店,经验丰富的店员 Hakeem 向她推荐了一款非常棒的新款 Android 手机。

    Sally 回到家后就马上开始设置新手机,她很轻松地就将旧手机中的所有应用、照片、消息和设置传输到了新手机, 这让她感到很高兴。

    传输完成后,她想看看喜欢的一些游戏在这部很棒的新手机上的运行效果。她最喜欢的休闲游戏是 Super Soccer Goalie Catch 2。她花了几个月时间才达到 123 级,迫不及待地想在新手机上打通这一关。

    不幸的是,当她打开游戏时发现所有游戏进度都没有了。Sally 需要花几天时间才能升到原来的级别,她感到很灰心丧气,她觉得不值得付出这么多时间回到原等级。于是卸载了这款游戏,并安装了该游戏的主要竞争对手 Soccer Goalie 3D 应用。

    Sally 并没有气馁,她打开了 Protein Shake Tracker 应用。Sally 喜欢喝蛋白粉,喜欢给它们打分,并跟踪自己摄入了多少营养。当 Sally 打开该应用时系统提示她登录,但 Sally 不记得自己的登录信息,也没有使用密码管理器。她也很确定自己已经更换过电子邮件地址。她有些不知所措。

    相信大家已经猜到了,Sally 卸载了该应用并决定尝试另一款名为 ProteinMate 的新的出色应用。这款应用在她的 Instagram 动态消息上投放了大量广告。

    Sally 喜欢她的新手机也喜欢手机上的大多数应用,但部分应用无法传输之前的数据,这让她很失望。

    Javier 遇到的困惑

    这是 Javier,Javier 使用 iPhone 给晚辈们发消息。他的手机中有很多晚辈们的照片,这对他来说意味着一切。

    Javier 喜欢尝鲜,并且经常会购买新款手机。他很喜欢新买的可折叠 Android 手机的外观,这样的设计使他有更多的屏幕空间来发消息和玩游戏,并且可以向朋友们炫耀。

    Javier 将他的所有应用、联系人和照片从 iPhone 手机传输到新的可折叠 Android 手机上。传输完成后,他马上打开了所用的即时通讯应用,希望在大屏幕上看看晚辈们的照片。

    但他发现这款即时通讯应用并没有将 iPhone 上的消息传输过来,这让他很受打击。他在想,或许应该换一款即时通讯应用。

    现在,您可能会认为所有这些都是在散布恐慌。但在 Google 我们对切换体验进行了大量研究,结果显示用户对切换体验并不满意。

    这是卫报近期刊登的一篇文章中的一段话,与我们的研究结果相吻合。

    △ 真实的用户反馈

    △ 真实的用户反馈

    这位用户将手机忘在了车顶上,当他发现游戏进度没有传输到新设备上时,就卸载了这款游戏。我们在研究中听到很多类似的声音。

    △ 研究成果摘要

    △ 研究成果摘要

    这是我们研究结果的总结。让用户感到不解的是,应用不能延续旧手机原有的状态。他们对自己的个人数据丢失感到不安,用户不会责怪 Android 或 OEM,而会责怪应用或他们自己。

    在新机配置过程中只有 30% 的设备以新设备进行设置,绝大多数用户希望能够将旧手机中的数据传输到新设备。如果不能这样做,用户会感到不安,从而导致 Play 商店中的应用评分降低,并直接造成用户流失。

    不要像这位开发者一样,完全不了解为什么用户会流失。这些用户是您一开始努力争取到的,当用户更换新设备时,一定要留住他们。

    幸运的是,在 Android 上将应用数据传输到新设备非常简单,甚至可以免费将数据备份到云端,通过用户信任的高质量应用,帮助您扩大用户群,最终增加收入。

    关于 Android 备份和恢复

    我们来看两种用例: 从 iOS 切换到 Android 和从 Android 切换到 Android。

    如果用户之前使用的是 iOS 手机,可以用数据线将旧手机连接到新的 Android 设备,然后进行设备到设备的迁移,简称 D2D。在 D2D 期间我们将查看用户的 iOS 设备上有哪些应用,然后尝试在 Play 商店中找到对应的 Android 应用,并自动安装这些应用。对于部分应用,还可以传输应用数据。如果您对 iOS 和 Android 版应用之间的数据传输感兴趣,请通过该 电子邮件地址 联系我们。

    △ 通过数据线连接设备进行备份和恢复

    △ 通过数据线连接设备进行备份和恢复

    对于从 Android 切换到 Android 的用例,用户也可以通过数据线连接设备。我们将重新下载用户的所有应用,并为每个参与备份和恢复的应用传输多达 2GB 的数据。

    △ 云备份中恢复数据

    △ 云备份中恢复数据

    如果用户的旧设备目前不在身边,则可以从之前创建的云备份中恢复数据。这是因为 Android 设备上的应用数据会定期备份到云端。这些应用数据备份在运行 Android Pie 及更高版本的设备上受到端到端加密保护,前提是用户已设置用于解锁屏幕的 PIN 码、图案或密码。在这种模式下,我们将为设备上的每个相关应用备份多达 25MB 的数据。

    Android M 及更高版本上的所有应用都已启用了备份和恢复,除非您明确选择禁用该功能。您可以很轻松地控制和自定义所需的行为,我们将在稍后介绍如何做到这一点。

    在这里您可能会想,我已经使用某种解决方案来保持用户数据同步到云端。比如 Firebase 或自定义后端,为什么还需要备份和恢复?

    首先,为了使用应用内云同步功能用户需要登录到您的应用。而备份和恢复功能处理的数据在此之前就已经可用,因为我们已经通过用户的 Google 帐号识别用户的身份。

    其次,也许是更重要的一点,有很多数据是设备独有的,而不属于应用中的帐号。应用通常不会将这些数据同步到云端。例如,假设您有一个入门教程,在每个设备上显示一次而不是每个帐号中如此。或者,假设您的应用中有一个设置屏幕,用户可以通过设置自定义应用在此特定设备上的外观和行为。这样的例子还有很多。

    但重点在于,当用户首次在新手机上启动应用时,他们真的希望所有这些首选项都已经正确配置。现在,我们来看看如何为 Android 应用配置备份和恢复。

    自动备份 (Auto Backup)

    默认情况下,所有应用都参与自动备份。这意味着,您的大部分应用数据将包含在云备份和 D2D 传输中。我们将只排除缓存目录和特殊的非备份文件夹,您可以在其中放置不希望备份或传输的内容。

    自定义自动备份

    这是自动备份中可以自定义的配置:

    • 设置规则规定云备份或设备传输中应包含哪些文件或目录
    • 指定只有当设备支持端到端 (E2E) 加密时,才需要进行云备份
    • 为云端和 D2D 设置不同的规则

    要完成所有这些任务,只需创建一个包含所需配置的 XML 文件。

    <data-extraction-rules>
        <cloud-backup disableIfNoEncryptionCapabilities=”true”>
            <exclude path=”my_prefs/device_specific_prefs”/>
            <exclude path=”downloaded/temp” />
        </cloud_backup>
        <device-transfer>
            <exclude path=”my_prefs/device_specific_prefs” />
        </device-transfer>
    </data-extraction-rules>
    

    如上述代码所示,该配置包含两个部分: 一部分用于云备份,另一部分用于设备传输。在每个部分中,可以设置要排除或包含哪些文件或目录的规则。

    <data-extraction-rules>
        <cloud-backup disableIfNoEncryptionCapabilities=”true”>
            <exclude path=”files/my_firebase_token”/>
            <exclude path=”files/downloaded” />
        </cloud_backup>
        <device-transfer>
            <exclude path=”my_prefs/device_specific_prefs” />
        </device-transfer>
    </data-extraction-rules>
    

    在本例中,我们将 Firebase 推送令牌排除在云备份之外,因为它在任何其他设备上都无法使用。将特定设备之外无法复用的数据排除是非常合理的。我们还排除了一个较大的可下载文件,如果可以很容易地从某个位置重新下载特定的数据,那么将其包含到云备份中毫无意义。

    此外,对于云备份,我们已将 disableIfNoEncryptionCapabilities 标志设置为「true」。这意味着,除非提供端到端加密,否则不会将数据备份到云端。

    最后,我们为设备到设备传输定义了更宽松的配置,因为在这个过程中不涉及云存储。

    <uses-sdk android:targetSdkVersion=”31” />
    <application
            ... 
            android:dataExtractionRules=”my_rules.xml”>
    

    完成配置后,需要使用 dataExtractionRules 属性在 AndroidManifest 文件中指向该配置。另外,不要忘了将 Android 12 作为目标平台,因为该属性是从这个版本才引入的。

    如需获取有关配置自动备份的更详细说明,请参阅 官方文档

    键值对备份 (Key/Value Backup)

    接下来,我们简单看一下我前面提到的另一种方法,即键值对备份 (K/V backup)。

    void onBackup(ParcelFileDescriptor oldState, BackupDataOutput data,
                    ParcelFileDescriptor newState) {
           boolean isEncrypted = data.getTransportFlags
                 & BackupAgent.FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
           boolean isD2d = data.getTransportFlags
                 & BackupAgent.FLAG_IS_DEVICE_TO_DEVICE_TRANSFER
           if (isEncrypted || isD2d) {
                  //在这里包含需要备份的数据:要么使用端到端加密,要么不上传任何数据到云端
           }
    }
    

    在这里,需要扩展一个名为 BackupAgent 的类,并实现您希望的备份和恢复行为。作为备份事件的一部分您可以检查相同的条件,比如是否提供端到端加密以及当前正在进行的操作是云备份还是设备传输,以便更好地确定应该包括哪些键值对。

    <application
            ... 
            android:backupAgent=”MyBackupAgent”>
    

    同样,当备份代理就绪后,不要忘了在 AndroidManifest 中指向该代理。如果您对键值对备份感兴趣,请参阅 实现键值对备份的分布指南

    使用 BlockStore 传输用户凭证

    接下来我们介绍一个特定类别的应用数据。当用户在新设备上启动一款应用时,面临的最大障碍之一是再次登录。用户甚至有可能不记得自己的登录名和密码。如果您的应用能够自动识别用户,让他们能够从旧设备上离开应用的位置继续,这不是很好吗?

    为了实现这一点可以使用 BlockStore。它允许您将识别用户身份所需的任何登录凭据传输到新设备作为设备到设备迁移的一部分。BlockStore 不依赖自动备份和键值对备份等功能。即使您不使用备份和恢复进行任何其他操作,仍可以使用 BlockStore 来传输身份验证令牌。我们快速了解一下它是如何工作的。

    val client = Blockstore.getClient(this)
    val data = StoreBytesData.Builder()
            .setBytes(/* 二进制数组 */)
            .build()
    client.storeBytes(data)
            .addOnSuccessListener{ result ->
                Log.d(TAG, “Stored: ${result.getBytesStored()}”)
            }
    

    每当用户登录到您的应用并生成一个身份验证令牌或任何其他登录凭据时,只需将这些数据保存到 BlockStore 中,BlockStore 将对这些数据进行加密并安全存储。

    val client = Blockstore.getClient(this)
    client.retrieveBytes()
            .addOnSuccessListener{ result ->
                Log.d(TAG, “Retrieved: ${String(result)}”)
    }
    

    在完成设备到设备迁移后,当您的应用在新设备上启动时,您可以向 BlockStore 请求之前保存的凭据,并在不要求用户输入登录名和密码的情况下登录应用。

    如需了解有关 BlockStore 的更多信息,请参阅。

    测试

    在您根据需要完成所有配置后,无论是使用自动备份还是键值对备份,都应进行一些测试,以确保在恢复后首次启动应用时,获得所需的状态,这一点非常重要。

    测试非常简单,您可以通过特殊的工作流使用单个设备或模拟器专门模拟应用的云备份和设备到设备传输。

    如需获得关于测试的详细说明,请参阅 官方文档

    持续更新您的实现方式

    最后,使您的配置保持最新版本同样很重要。随着应用不断演化并增加新功能,请确保备份和恢复涵盖新增的内容。如果您使用的是自动备份可能不需要执行任何操作,默认情况下会包含所有新数据。如果您使用的是键值对备份,请更新 BackupAgent 以包含任何相关的信息。

    关于 Android 12 的重要更新

    应用开发者向我们反馈,他们担心 adb 备份会导致应用数据轻易被提取。为了解决这个问题,我们已经关闭了所有应用的 adb 备份。因此,启用备份和恢复不会使您的应用受到 adb 备份的影响。但您仍然可以根据需要将 adb 备份用于测试和开发目的。

    其次,我们引入了 dataExtractionRules 配置,作为控制自动备份的新方法。我们正在逐步淘汰旧的方法,即 allowBackup 标志和 fullBackupContent 配置。建议您在 Android 12 及更高版本中使用 dataExtractionRules。同时为早期操作系统版本保留 fullBackupContent 配置。

    如需获得上述更新的详细说明,请参阅 官方文档

    总结

    我相信当您的应用数据同步到新设备上时是十分令人振奋的。好消息是,目前已有超过 20 亿台 Android 设备支持免费备份到云端。从 2022 年 1 月起 Wi-Fi 和数据线传输将扩展到所有新的 Android 设备。所有这些都将默认生效,建议您确保这些功能已开启。如果您有大量数据或敏感数据,可以对导出的内容进行微调。不要忘了新的 BlockStore API,您可以使用它安全地处理密码。

    希望这些内容对您有帮助,同时希望您利用备份和恢复为用户提供更好的体验。

    欢迎您 点击这里 向我们提交反馈,或分享您喜欢的内容、发现的问题。您的反馈对我们非常重要,感谢您的支持!

    展开全文
  • PostgreSQL 数据库备份恢复介绍

    千次阅读 2022-04-19 20:57:09
    因此关于数据库的备份恢复的策略方法,在数据库上线之前就应该有充分的设计测试。 数据库备份和恢复策略必须针对各种可能出现的灾难性的故障,进行规划设计。例如硬件设备故障(如硬盘损坏)、基础设施的维护...

    防止数据库数据丢失的最重要的方法就是备份。造成数据丢失可能的原因有很多种,例如服务器的硬件损坏,而有的是人为的原因导致的(例如误删数据),还有的就是应用程序的bug导致数据误删。因此关于数据库的备份与恢复的策略和方法,在数据库上线之前就应该有充分的设计和测试。

    数据库备份和恢复策略必须针对各种可能出现的灾难性的故障,进行规划和设计。例如硬件设备故障(如硬盘损坏)、基础设施的维护(如操作系统故障)、位置灾难(如数据中心断电)、操作错误(rm -rf 数据文件)、数据损坏(应用程序误删)和合规性要求。

    因此对数据库进行备份应该是一个常见的任务,以防止数据丢失。

    备份和恢复策略考虑的因素

    备份和恢复必须综合考虑和平衡对业务的影响和成本因素,例如:

    • How long will recovery take? 数据库恢复的时间
    • How long do we need to store backup data? 数据库备份
    • How much will data storage cost?
    • Will an outage effect our Brand? 数据库服务中断会有什么影响?
    • Can any part of the database remain operational whilst I recover elsewhere?
    • Do I know when the problem I am recovering from started?

    可能导致数据丢失的原因

    • Downtime Scenarios •  Device Failure •  Maintenance •  Site Failure •  Operator Error •  Data Corruption •  Compliance
    • Device Failure •  Loss of Machine •  Loss of Disk •  Loss Of Power
    • Maintenance •  Hardware upgrades •  O/S upgrades
    • Site Failure •  Datacenter Failure •  Network Failure •  Office Break-In
    • Operator Error •  Update error •  Dropped table •  Dropped schema •  Deletion of datafile
    • Data Corruption •  Application introduces poor code and in turn corrupts the data •  Disk level corruption
    • Compliance •  Data Retention Periods •  Readable data •  Writeable data •  Storage of data

    Postgresql 数据备份的几种方法

    目前Postgresql提供了3种最基本的策略来实现备份。

    • 逻辑备份
    • 物理备份文件系统级别的备份(File system level backup)
    • 连续归档(Continuous Archiving)

    逻辑备份(pg_dump)

    在Postgresql中提供了pg_dump, pg_dumpall工具进行数据库的逻辑备份。pg_dumpall是备份全库,而pg_dump可以选择一个数据库或部分表进行备份。

    特点

    • pg_dump 不会阻塞正常的数据库读写,可以在数据库处于使用状态时进行完整的一致的备份,备份可以简单看作是pg_dump开始运行时的数据库的快照。
    • pg_dump的备份文件可以是SQL脚本,也可以是归档文件。用psql执行SQL脚本文件可以重建该数据库,甚至不依赖特定的基础设施(例如操作系统,),脚本修改后甚至可以恢复到非postgres数据库。但是如果是归档文件,则只能用pg_store来重建数据库。
    • pg_dump和pg_restore可以选择性的备份或恢复部分表或数据库对象。
    • pg_dumpall 对db cluster中的每个数据库调用pg_dump来完成该工作,还会还转储对所有数据库公用的全局对象(pg_dump不保存这些对象)。 目前这包括适数据库用户和组、表空间以及适合所有数据库的访问权限等属性。注意pg_dumpall只能导出脚本文件。

    实战

    1. 当连接一个本地的数据库时,可以使用如下命令:
    [postgres@localhost logic]$ pg_dump -U postgres osdba > osdba_dump1.sql
    Password: 
    [postgres@localhost logic]$ 
    [postgres@localhost logic]$ 
    [postgres@localhost logic]$ ll
    total 84564
    -rw-r--r--. 1 postgres postgres 86591748 Oct  6 16:51 osdba_dump1.sql
    [postgres@localhost logic]$ head -n 100 osdba_dump1.sql 
    --
    -- PostgreSQL database dump
    --
    
    -- Dumped from database version 13.3
    -- Dumped by pg_dump version 13.3
    
    SET statement_timeout = 0;
    SET lock_timeout = 0;
    SET idle_in_transaction_session_timeout = 0;
    SET client_encoding = 'UTF8';
    SET standard_conforming_strings = on;
    SELECT pg_catalog.set_config('search_path', '', false);
    SET check_function_bodies = false;
    SET xmloption = content;
    SET client_min_messages = warning;
    SET row_security = off;
    
    SET default_tablespace = '';
    
    SET default_table_access_method = heap;
    
    --
    -- Name: company; Type: TABLE; Schema: public; Owner: postgres
    --
    
    CREATE TABLE public.company (
        id integer,
        name character varying(32)
    );
    
    
    ALTER TABLE public.company OWNER TO postgres;
    
    --
    -- Name: people; Type: TABLE; Schema: public; Owner: postgres
    --
    
    CREATE TABLE public.people (
        id integer,
        name character varying(32),
        age integer,
        grade numeric(4,2),
        birthday date,
        logintime timestamp without time zone
    );
    
    
    ALTER TABLE public.people OWNER TO postgres;
    
    --
    -- Data for Name: company; Type: TABLE DATA; Schema: public; Owner: postgres
    --
    
    COPY public.company (id, name) FROM stdin;
    1	2d5e81d30b201cae28e51c3bda7f1e08
    2	1c367e0fe7172addf79903dfd9bdfe06
    3	01f09ce43ddea1a8207a33e0c2969297
    ...
    
    1. 可以使用pg_dump备份一个远程的数据库。
    ## 远程到192.168.146.132
    [postgres@localhost logic]$ ssh 192.168.146.132
    The authenticity of host '192.168.146.132 (192.168.146.132)' can't be established.
    ECDSA key fingerprint is SHA256:pg1sNWe72JI56IqPW3ZCAme0pL9mNUJvRNkV8peif4A.
    Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
    Warning: Permanently added '192.168.146.132' (ECDSA) to the list of known hosts.
    postgres@192.168.146.132's password: 
    Activate the web console with: systemctl enable --now cockpit.socket
    
    Last login: Thu Oct  7 00:38:32 2021
    [postgres@localhost ~]$ ls
    backups  data  initdb_postgresql.log
    [postgres@localhost ~]$ cd backups/
    [postgres@localhost backups]$ ls
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ pg_dump -h 192.168.146.131 -U postgres osdba > osdba.sql
    Password: 
    ## 这里查看导出文件第40行到60行的内容
    [postgres@localhost backups]$ head -n 60 osdba.sql | tail -n 20
        name character varying(32),
        age integer,
        grade numeric(4,2),
        birthday date,
        logintime timestamp without time zone
    );
    
    
    ALTER TABLE public.people OWNER TO postgres;
    
    --
    -- Data for Name: company; Type: TABLE DATA; Schema: public; Owner: postgres
    --
    
    COPY public.company (id, name) FROM stdin;
    1	2d5e81d30b201cae28e51c3bda7f1e08
    2	1c367e0fe7172addf79903dfd9bdfe06
    3	01f09ce43ddea1a8207a33e0c2969297
    4	e746f65209317296e56b12db276f9bfc
    5	2d043d4cb9210c98084bdb00d8f4cfb3
    
    1. 自定义格式的备份文件 使用-Fc参数,-F就是format的意思。
    [postgres@localhost backups]$ pg_dump -Fc -h 192.168.146.131 -U postgres osdba > osdba131.dump
    Password: 
    [postgres@localhost backups]$ ll -h
    total 116M
    -rw-r--r--. 1 postgres postgres 33M Oct  7 01:06 osdba131.dump
    -rw-r--r--. 1 postgres postgres 83M Oct  7 01:02 osdba.sql
    
    

    把osdba131.dump文件恢复到132这台机器的osdba2数据库中。

    [postgres@localhost backups]$ createdb -E 'UTF-8' osdba2 ; 
    Password: 
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ pg_restore -d osdba2 osdba131.dump 
    Password: 
    [postgres@localhost backups]$ createdb -E 'UTF-8' osdba2 ; 
    Password: 
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ pg_restore -d osdba2 osdba131.dump 
    Password: 
    [postgres@localhost backups]$ psql osdba2
    Password for user postgres: 
    psql (13.3)
    Type "help" for help.
    
    osdba2=# select count(0) from people;
      count  
    ---------
     1000000
    (1 row)
    
    osdba2=# select count(0) from company;
     count 
    -------
       100
    (1 row)
    
    osdba2=# 
    
    
    1. 备份指定的表 使用-t 和 -T 用来设置要include与exclude的表。
    [postgres@localhost backups]$ pg_dump -t 'company' -h 192.168.146.131 -U postgres osdba > osdba131-company.dump
    Password: 
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ 
    [postgres@localhost backups]$ ll -h
    total 116M
    -rw-r--r--. 1 postgres postgres 4.4K Oct  7 01:13 osdba131-company.dump
    -rw-r--r--. 1 postgres postgres  33M Oct  7 01:06 osdba131.dump
    -rw-r--r--. 1 postgres postgres  83M Oct  7 01:02 osdba.sql
    
    
    1. pg_dumpall的简单使用
    [postgres@localhost dump]$ pg_dumpall -h 127.0.0.1 -p 5432 -U postgres -c -f all_db_bak.sql
    Password: 
    Password: 
    Password: 
    [postgres@localhost dump]$ pg_dump -h 127.0.0.1 -p 5432 -U postgres -c -C -f postgres_db_bak.sql postgres
    Password: 
    [postgres@localhost dump]$ ll -h
    total 821M
    -rw-r--r--. 1 postgres postgres 309M Oct  6 16:14 all_db_bak.sql
    -rw-r--r--. 1 postgres postgres 309M Oct  6 16:15 postgres_db_bak.sql
    [postgres@localhost dump]$ wc -l all_db_bak.sql 
    1910237 all_db_bak.sql
    [postgres@localhost dump]$ wc -l postgres_db_bak.sql 
    1910104 postgres_db_bak.sql
    [postgres@localhost dump]$ 
    
    

    大型数据库pg_dump使用

    在一些旧的操作系统,会对文件的大小有一定的限制,例如windows XP的NTFS文件系统限定文件最大为64G。Linux中ext2文件系统的最大文件为2TB,ext3单文件最大16TB。如果数据库非常巨大,pg_dump可能因为操作系统的限制导致备份失败。

    一些Linux的工具可以实现文件的压缩和分割。

    pg_dump dbname | gzip > filename.gz
    pg_dump dbname | split -b 1m - filename
    

    物理备份

    最简单的物理备份就是冷备份。所谓冷备份就是先把数据库停下来,然后拷贝数据库的PGDATA目录。因为PostgreSQL把实例相关的配置文件和数据文件都放在PGDATA目录下,所以冷备份很简单,就是文件拷贝。

    物理冷备份

    下面很简单的演示冷备份。

    ## 停止数据库服务
    [jack@localhost ~]$ sudo systemctl stop postgresql.service 
    [sudo] password for jack: 
    [jack@localhost ~]$ systemctl status postgresql.service 
    ● postgresql.service - PostgreSQL database server
       Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor >
       Active: inactive (dead) since Thu 2021-10-07 01:44:58 CST; 2s ago
      Process: 37220 ExecStart=/usr/bin/postmaster -D ${PGDATA} (code=exited, statu>
      Process: 37217 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (>
     Main PID: 37220 (code=exited, status=0/SUCCESS)
    ## 备份${PGDATA}文件夹
    [jack@localhost ~]$ su - postgres 
    Password: 
    [postgres@localhost ~]$ 
    [postgres@localhost ~]$ echo ${PGDATA}
    /var/lib/pgsql/data
    [postgres@localhost ~]$ 
    [postgres@localhost ~]$ 
    [postgres@localhost ~]$ cd backups/
    [postgres@localhost backups]$ pwd
    /var/lib/pgsql/backups
    ## 备份文件夹
    [postgres@localhost backups]$ tar -cf backup.tar /var/lib/pgsql/data
    tar: Removing leading \`/\' from member names
    [postgres@localhost backups]$ ll
    total 323540
    -rw-r--r--. 1 postgres postgres 210452480 Oct  7 01:47 backup.tar
    -rw-r--r--. 1 postgres postgres      4483 Oct  7 01:13 osdba131-company.dump
    -rw-r--r--. 1 postgres postgres  34249605 Oct  7 01:06 osdba131.dump
    -rw-r--r--. 1 postgres postgres  86591748 Oct  7 01:02 osdba.sql
    [postgres@localhost backups]$ 
    ## 恢复
    [postgres@localhost ~]$ tar -xvf backups/backup.tar
    [postgres@localhost ~]$ ls
    backups  initdb_postgresql.log  var
    [postgres@localhost ~]$ mv var/lib/pgsql/data/ ./
    postgres@localhost ~]$ rm -rf var
    [postgres@localhost ~]$ ls
    backups  data  initdb_postgresql.log
    
    ## 重启服务
    [jack@localhost ~]$ sudo systemctl start postgresql.service 
    [sudo] password for jack: 
    
    [jack@localhost ~]$ psql -U postgres osdba2
    Password for user postgres: 
    psql (13.3)
    Type "help" for help.
    
    osdba2=# 
    osdba2=# 
    osdba2=# select count(0) from people;
      count  
    ---------
     1000000
    (1 row)
    

    冷备份必须要先停止数据库,以避免数据不一致的情况,例如WAL写进程正在写一半,造成数据库的不完整性。然后物理冷备份不能实现按数据库对象进行选择性备份。

    物理热备份

    还有一种物理备份的方法是在不停止数据库的情况下完成,称之为热备份或在线备份。在Postgres中通常的热备份有以下两种方法:

    • 连续归档与PIRT
    • 使用文件系统或块设备级别的快照功能,该方法要求数据库建立在LVM上。

    连续归档与PIRT

    我们知道PostgreSQL在data目录的pg_wal子目录(10版本前是pg_xlog)中始终维护一份WAL日志文件。该日志文件记录了数据库数据文件的每次改变。当数据库异常崩溃以后,能够通过重放(replay)最后一次检查点(checkpoint)之后的日志记录,就能把数据库推到最终一致的状态。因此我们如果有了最初的数据库备份Base,再加上此备份时间点后的所有数据库的WAL日志,相当于数据库的改变量Δ,然后直接重放Δ就能实现数据库的恢复。

    具体来说就是把一个文件系统级别的全量备份和WAL(预写式日志)级别的增量备份结合起来。当需要恢复时,我们先恢复文件系统级别的备份,然后重放备份的WAL文件,把系统恢复到之前的某个状态。

    虽然直接复制数据库数据文件,由于复制文件的时间有先后,可能会导致数据文件之间存在不一致的情况。但是由于有了WAL日志,即使备份出来的数据块不一致,也可以通过重放来实现最终的一致性。

    连续归档有以下的几个特点:

    • 不需要完美的一致性的备份,备份中的任何非一致性数据都可以通过重放WAL日志文件得以纠正。
    • 可以结合一个无穷长的WAL日志序列用于重放,可以通过简单的归档WAL文件来达到连续备份。
    • 不需要重放WAL日志到最后,可以在任何点停止重放,并使数据库恢复到某个时间点的一致性状态,这就是基于时间点的备份,英文为"Point-In-Time Recovery"简称“PITR”。
    • 可以连续的将一系列WAL文件输送给另外一台已经载入了相同基础备份文件的机器,得到一个实时的热备份系统。

    把WAL日志传送到另外一台机器的方法有2种,一种是通过WAL归档日志方法;另外一种是PostgreSQL9.X以后开始提供的被称为流复制的方法。在后续的文章种将详细介绍流复制。

    基础备份

    使用简单的cp命令或其他命令把数据库在线复制出来的备份,称为基础备份,从基础备份操作开始之后产生的WAL日志和基础备份本身就构成了一个完整的备份。我们当然也可以直接cp的方式来备份,但是PosggreSQL提供了pg_basebackup命令行工具来实现更加灵活和安全的方式完成基础备份。

    pg_basebackup工具把整个数据库实例的全部数据都物理的复制出来(包括配置文件),而不是也不能是只把实例种的部分内容单独备份出来例如只备份某些表。该工具使用流复制的协议连接到主数据库上,所以数据库上必须允许replication连接。

    pg_hba.conf

    host    replication     all             0.0.0.0/0               md5
    

    下面简单介绍其用法:

    1. 备份本机的数据库

    -D 指定备份的目标目录,可以不用预先创建。 -Ft 指定备份文件的格式为tar,相当于把备份文件输出到一个tar文件中。 -z 仅仅与tar输出模式配合使用,就是对tar文件进行gzip压缩,便于传输。 -P 用来输出备份的进度

    pg_basebackup -D base20211007 -Ft -z -P
    
    [postgres@raw140 backups]$ pwd
    /var/lib/pgsql/backups
    [postgres@raw140 backups]$ pg_basebackup -D base20211007 -Ft -z -P
    479078/479078 kB (100%), 1/1 tablespace
    [postgres@raw140 backups]$ ls
    base20211007
    [postgres@raw140 backups]$ cd base20211007/
    [postgres@raw140 base20211007]$ ll -h
    total 188M
    -rw------- 1 postgres postgres 133K Oct  6 23:22 backup_manifest
    -rw------- 1 postgres postgres 188M Oct  6 23:22 base.tar.gz
    -rw------- 1 postgres postgres  17K Oct  6 23:22 pg_wal.tar.gz
    [postgres@raw140 base20211007]$ 
    

    这里backup_manifest文件是备份的元文件,包括备份的一些基础信息,例如CRC校验等等。

    1. 远程备份
      下面这个例子在141这台机器上备份140机器上的数据库。
      -l label 用来指定备份的一个标识。便于以后维护人员识别该备份。
    pg_basebackup -h 192.168.203.140 -Upostgres -Ft -z -P -D pg140_base_backup -l pg140_base_20211007
    [postgres@raw141 backups]$ pwd
    /var/lib/pgsql/backups
    [postgres@raw141 backups]$ pg_basebackup -h 192.168.203.140 -Upostgres -Ft -z -P -D pg140_base_backup -l pg140_base_20211007
    Password: 
    479078/479078 kB (100%), 1/1 tablespace
    [postgres@raw141 backups]$ ll
    total 0
    drwx------ 2 postgres postgres 69 Oct  6 23:34 pg140_base_backup
    [postgres@raw141 backups]$ cd pg140_base_backup/
    [postgres@raw141 pg140_base_backup]$ ll -h
    total 188M
    -rw------- 1 postgres postgres 133K Oct  6 23:34 backup_manifest
    -rw------- 1 postgres postgres 188M Oct  6 23:34 base.tar.gz
    -rw------- 1 postgres postgres  18K Oct  6 23:34 pg_wal.tar.gz
    

    我们可以自己添加一个定时任务,在每天业务空闲的时段,来对数据库进行全量备份。

    WAL日志连续归档

    在完成了数据库的基础备份之后,还要对数据库WAL日志进行连续归档,因为默认PostgreSQL的WAL文件只有16个大小为16M的段, 当16个seq写完后,PG会重复利用旧的seq并覆盖原先的内容。因此必须在wal的段文件覆盖之前把他备份到其他的地方,这就需要WAL日志归档功能。

    所谓把WAL日志归档,其实就是把在线的已写完的WAL日志复制出来。可以通过配置postgresql.conf文件中的archive_mode和archive_command来打开WAL日志归档。其中archive_command就是一个操作系统的命令,该命令把WAL日志文档复制到其他地方,也包括远程的主机。

    postgresql.conf

    # - Archiving -
    archive_mode = on               # enables archiving; off, on, or always
                                    # (change requires restart)
    archive_command = 'cp %p /var/lib/pgsql/backups/pg_wall_archive/%f '            # command to use to archive a logfile segment
                                    # placeholders: %p = path of file to archive
                                    #               %f = file name only
                                    # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
    

    archive_mode=on表示打开归档备份,archive_command中的命令就是完成归档日志的备份。命令中的%p表示在线WAL日志的全路径名,%f表示不包括路径的WAL文件名。当然也可以通过scp命令来把归档日志备份到其他机器上。

    下面来通过一个小实验简单验证一下日志归档的功能。

    打开归档功能后,我们给jack_test表插入大量的数据。

    [postgres@raw140 data]$ psql
    Password for user postgres: 
    psql (13.3)
    Type "help" for help.
    postgres=#
    postgres=# create table jack_test ( id integer primary key not null, name varchar(128), others text );
    CREATE TABLE
    postgres=# select count(0) from jack_test;
     count 
    -------
     10001
    (1 row)
    
    postgres=# insert into jack_test (id, name, others)
    postgres-# select generate_series(100000,200000) as id,
    postgres-# md5(random()::text) as name,
    postgres-# random_string(128);
    INSERT 0 100001
    postgres=# select count(0) from jack_test;
     count  
    --------
     110002
    (1 row)
    postgres=# insert into jack_test (id, name, others)
    select generate_series(200001,1000000) as id,
    md5(random()::text) as name,
    random_string(128);
    INSERT 0 800000
    postgres=# select count(0) from jack_test;
     count  
    --------
     910002
    (1 row)
    
    postgres=# 
    
    postgres=# insert into jack_test (id, name, others)
    select generate_series(1000001,2000000) as id,
    md5(random()::text) as name,
    random_string(128);
    INSERT 0 1000000
    postgres=# select count(0) from jack_test;
      count  
    ---------
     1910002
    (1 row)
    
    postgres=# 
    

    我们对比一下wal日志目录和wal归档目录,发现所有历史的wal日志都已经保存起来,wal目录由于文件重用的关系,只保留了16个文件。

    [postgres@localhost pg_wal]$ tree -Lp 1
    .
    ├── [-rw-------]  000000010000000000000011
    ├── [-rw-------]  000000010000000000000012
    ├── [-rw-------]  000000010000000000000013
    ├── [-rw-------]  000000010000000000000014
    ├── [-rw-------]  000000010000000000000015
    ├── [-rw-------]  000000010000000000000016
    ├── [-rw-------]  000000010000000000000017
    ├── [-rw-------]  000000010000000000000018
    ├── [-rw-------]  000000010000000000000019
    ├── [-rw-------]  00000001000000000000001A
    ├── [-rw-------]  00000001000000000000001B
    ├── [-rw-------]  00000001000000000000001C
    ├── [-rw-------]  00000001000000000000001D
    ├── [-rw-------]  00000001000000000000001E
    ├── [-rw-------]  00000001000000000000001F
    ├── [-rw-------]  000000010000000000000020
    ├── [-rw-------]  000000010000000000000021
    ├── [-rw-------]  000000010000000000000022
    ├── [-rw-------]  000000010000000000000023
    ├── [-rw-------]  000000010000000000000024
    ├── [-rw-------]  000000010000000000000025
    ├── [-rw-------]  000000010000000000000026
    ├── [-rw-------]  000000010000000000000027
    ├── [-rw-------]  000000010000000000000028
    ├── [-rw-------]  000000010000000000000029
    ├── [-rw-------]  00000001000000000000002A
    ├── [-rw-------]  00000001000000000000002B
    ├── [-rw-------]  00000001000000000000002C
    └── [drwx------]  archive_status
    
    1 directory, 28 files
    [postgres@localhost pg_wal]$ 
    
    [postgres@localhost pg_wall_archive]$ pwd
    /var/lib/pgsql/backups/pg_wall_archive
    [postgres@localhost pg_wall_archive]$ tree -Lp 1
    .
    ├── [-rw-------]  000000010000000000000001
    ├── [-rw-------]  000000010000000000000002
    ├── [-rw-------]  000000010000000000000003
    ├── [-rw-------]  000000010000000000000004
    ├── [-rw-------]  000000010000000000000005
    ├── [-rw-------]  000000010000000000000006
    ├── [-rw-------]  000000010000000000000007
    ├── [-rw-------]  000000010000000000000008
    ├── [-rw-------]  000000010000000000000009
    ├── [-rw-------]  00000001000000000000000A
    ├── [-rw-------]  00000001000000000000000B
    ├── [-rw-------]  00000001000000000000000C
    ├── [-rw-------]  00000001000000000000000D
    ├── [-rw-------]  00000001000000000000000E
    ├── [-rw-------]  00000001000000000000000F
    ├── [-rw-------]  000000010000000000000010
    ├── [-rw-------]  000000010000000000000011
    ├── [-rw-------]  000000010000000000000012
    ├── [-rw-------]  000000010000000000000013
    ├── [-rw-------]  000000010000000000000014
    ├── [-rw-------]  000000010000000000000015
    ├── [-rw-------]  000000010000000000000016
    ├── [-rw-------]  000000010000000000000017
    ├── [-rw-------]  000000010000000000000018
    ├── [-rw-------]  000000010000000000000019
    ├── [-rw-------]  00000001000000000000001A
    ├── [-rw-------]  00000001000000000000001B
    ├── [-rw-------]  00000001000000000000001C
    ├── [-rw-------]  00000001000000000000001D
    ├── [-rw-------]  00000001000000000000001E
    ├── [-rw-------]  00000001000000000000001F
    ├── [-rw-------]  000000010000000000000020
    ├── [-rw-------]  000000010000000000000021
    └── [-rw-------]  000000010000000000000022
    
    0 directories, 34 files
    [postgres@localhost pg_wall_archive]$ 
    

    简单来说要开启日志归档,需要修改如下配置:

    • wal_level 必须设置为archive或replica(高版本)
    • archive_mode 必须设置为on
    • archive_command 必须是有效的归档命令
    1. 总结 实现在线联机热备,需要以下几点
    • 定期基础备份(每天或者每周)
    • 开启WAL日志的连续归档

    基础备份+wal日志数据库恢复

    物理热备与恢复实战

    pg数据库机器: 192.168.203.140 backup机器: 192.168.203.141
    Step1. 140开启postgres用户免密登录141。

    [postgres@raw140 data]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/var/lib/pgsql/.ssh/id_rsa): 
    Created directory '/var/lib/pgsql/.ssh'.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /var/lib/pgsql/.ssh/id_rsa.
    Your public key has been saved in /var/lib/pgsql/.ssh/id_rsa.pub.
    The key fingerprint is:
    SHA256:4nVAX2sAOLo05VjVE4/Cx47MSZd297HtYNyvv+iWjDs postgres@raw140.jack007.com
    The key's randomart image is:
    +---[RSA 3072]----+
    |       o+oo..    |
    |      =o oo* .   |
    |     * .= O.= .. |
    |    = .+ X o o o+|
    |   . o. S o   +.+|
    |    .. o .   . o.|
    |      .     o . o|
    |           E +.. |
    |           .=o.oo|
    +----[SHA256]-----+
    [postgres@raw140 data]$ 
    [postgres@raw140 data]$ ssh-copy-id -i ~/.ssh/id_rsa.pub postgres@192.168.203.141
    /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/var/lib/pgsql/.ssh/id_rsa.pub"
    The authenticity of host '192.168.203.141 (192.168.203.141)' can't be established.
    ECDSA key fingerprint is SHA256:lh9uH9d0WGG740IJ+73DSI1Jm7/CW7jxQeeQFd7w4IQ.
    Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
    /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
    /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    postgres@192.168.203.141's password: 
    
    Number of key(s) added: 1
    
    Now try logging into the machine, with:   "ssh 'postgres@192.168.203.141'"
    and check to make sure that only the key(s) you wanted were added.
    
    [postgres@raw140 data]$ ssh 192.168.203.141
    Last login: Wed Oct  6 23:17:19 2021
    [postgres@raw141 ~]$ 
    

    Step2. 140数据库开启日志归档,并设置归档命令为scp到远程。 开始远程归档前,可以测试一下scp命令是否允许正常,然后确保远程的备份文件夹已经准备好。

    ## postgresql.conf
    archive_mode = on               # enables archiving; off, on, or always
                                    # (change requires restart)
    archive_command = 'scp %p postgres@192.168.203.141:/var/lib/pgsql/backups/pg140_wal_archive/%f'         # command to use to archive a logfile segment
    

    Step3. 设置pg_hba.conf,允许其他主机允许pg_basebackup连接,重启数据库

    host    replication     all             0.0.0.0/0               md5
    [jack@raw140 ~]$ sudo systemctl stop postgresql
    [jack@raw140 ~]$ sudo systemctl start postgresql
    
    

    Step4. 在141上执行基础备份。

    [postgres@raw141 backups]$ ll
    total 4
    drwxr-xr-x 2 postgres postgres 4096 Oct  7 02:33 pg140_wal_archive
    [postgres@raw141 backups]$ pg_basebackup -h 192.168.203.140 -Upostgres -Ft -z -P -D pg140_base_backup -l pg140_base_20211007
    Password: 
    923157/923157 kB (100%), 1/1 tablespace
    [postgres@raw141 backups]$ ll -h
    total 4.0K
    drwx------ 2 postgres postgres   69 Oct  7 02:38 pg140_base_backup
    drwxr-xr-x 2 postgres postgres 4.0K Oct  7 02:38 pg140_wal_archive
    

    Step5. 在141上恢复数据库 确保141的pg是停止状态。

    [jack@raw141 ~]$ sudo systemctl stop postgresql 
    [sudo] password for jack: 
    [jack@raw141 ~]$ 
    [jack@raw141 ~]$ 
    [jack@raw141 ~]$ 
    [jack@raw141 ~]$ sudo systemctl status postgresql 
    ● postgresql.service - PostgreSQL database server
       Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
       Active: inactive (dead) since Thu 2021-10-07 02:54:39 EDT; 53min ago
    

    解压全量备份的包到数据库的目录。

    [postgres@raw141 pg140_base_backup]$ ll
    total 457748
    -rw------- 1 postgres postgres    137054 Oct  7 02:38 backup_manifest
    -rw------- 1 postgres postgres 468571788 Oct  7 02:38 base.tar.gz
    -rw------- 1 postgres postgres     17729 Oct  7 02:38 pg_wal.tar.gz
    [postgres@raw141 pg140_base_backup]$ echo $PGDATA
    /var/lib/pgsql/data
    ## 解压base.tar.gz到主目录
    [postgres@raw141 pg140_base_backup]$ tar -zxvf base.tar.gz -C $PGDATA
    backup_label
    ...
    ## 解压wal文件到pg_wal目录
    [postgres@raw141 pg140_base_backup]$ tar -zxvf pg_wal.tar.gz -C $PGDATA/pg_wal
    00000001000000000000004D
    archive_status/00000001000000000000004D.done
    [postgres@raw141 pg140_base_backup]$ 
    
    [postgres@raw141 data]$ vim postgresql.conf
    ## 在postgresql.conf中取消掉140的wal归档设置
    # - Archiving -
    
    # archive_mode = on             # enables archiving; off, on, or always
                                    # (change requires restart)
    # archive_command = 'scp %p postgres@192.168.203.141:/var/lib/pgsql/backups/pg140_wal_archive/%f'               # command to use to archive a logfile segment
    

    启动141的数据库

    Step 6. 在141上应用最新的wal归档

    #首先停止141数据库,因为当前数据库的状态是pg_basebackup运行时的状态。如果要想获得较新的更新,就必须把140的wal归档文件在当前数据库能够进行自动重放(replay)。
    
    [jack@raw141 ~]$ sudo systemctl stop postgresql 
    [sudo] password for jack: 
    [jack@raw141 ~]$ sudo systemctl status postgresql 
    ● postgresql.service - PostgreSQL database server
       Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
       Active: inactive (dead) since Thu 2021-10-07 04:00:04 EDT; 5s ago
    

    因此需要修改postgresql.conf参数,添加与恢复相关的参数。我们知道140的wal归档路径为141的/var/lib/pgsql/backups/pg140_wal_archive目录。

    restore_command = 'cp /var/lib/pgsql/backups/pg140_wal_archive/%f %p'           # command to use to restore an archived logfile segment
                                    # placeholders: %p = path of file to restore
                                    #               %f = file name only
                                    # e.g. 'cp /mnt/server/archivedir/%f %p'
                                    # (change requires restart)
    recovery_target_timeline = 'latest'     # 'current', 'latest', or timeline ID
                                    # (change requires restart)
    

    在$PGDATA目录下创建一个信号文件

    [postgres@raw141 data]$ touch recovery.signal
    [postgres@raw141 data]$ 
    [postgres@raw141 data]$ ll recovery.signal 
    -rw-r--r-- 1 postgres postgres 0 Oct  7 04:17 recovery.signal
    

    启动数据库

    [jack@raw141 ~]$ sudo systemctl start postgresql 
    [sudo] password for jack: 
    [jack@raw141 ~]$ 
    [jack@raw141 ~]$ 
    [jack@raw141 ~]$ 
    [jack@raw141 ~]$ psql -U postgres
    Password for user postgres: 
    psql (13.3)
    Type "help" for help.
    
    postgres=# 
    postgres=# select count(0) from jack_test;
      count  
    ---------
     2000000
    (1 row)
    
    展开全文
  • Ghost 操作:还原(R)备份高级选项:自定义 Ghost 核心(C) 忽略 CRC 错误(I)快速还原昨日重现,不用害怕被病毒或者木马感染破坏系统,能够快速恢复到刚安装系统时的最佳状态,支持多种分区格式WIN操作系统;...
  • 恢复最新 vi /pgdata/9.6/poc/data/recovery.conf restore_command = 'bunzip2 < /data/pgdb_backups/increment_backup/wal_db_back/%f.bz2 > %p' recovery_target = 'immediate' $.恢复到某个时间 vi /pgdata/9.6...
  • 循序渐进Oracle:数据库管理、优化与备份恢复(第二) 基本信息 作者: 盖国强 出版社:人民邮电出版社 ISBN:9787115253170 上架时间:2011-7-13 出版日期:2011 年8月 开本:16开 页码:633 版次:1-1 编辑...
  • Xtrabackup备份恢复

    千次阅读 2021-05-28 15:12:54
    在实际生产环境中增量备份是非常实用的,如果数据大于50G或100G,存储空间足够的情况下,可以每天进行完整备份,如果每天产生的数据量较大,需要定制数据备份策略。例如每周实用完整备份,周一到周六实用增量备份。...
  • 最近有个BRETT的任务,需要使用pg_dumppg_restore来备份和恢复PROD的QLIK SENSE repository database ,目标版本postgress 9.6 (其实教程是通用的,无论9.6或者11 12 23). 逻辑备份一般用pg_dump或者pg_dumpall –...
  • 两台MAC时间机器的备份和系统恢复

    千次阅读 2022-02-21 09:55:32
    因某些需要,两台电脑的内容系统需要互换,过程踩了很多坑,也花了很多时间,特记录一下以帮助后来者。
  • Oracle数据库的备份恢复常用方法 详解

    万次阅读 多人点赞 2019-03-12 08:49:26
    Oracle数据库的备份恢复 在Oracle数据库的使用过程中,备份恢复是经常遇到的操作。Oracle中的备份分为两大类:逻辑备份和物理备份。其中物理备份又分为两类:冷备份和备份。本节将简要讲述如何利用各种备份...
  • es数据备份和恢复

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

    千次阅读 2018-01-06 11:46:10
    etcd 是一款开源的分布式一致性键值...etcd 目前最新的版本的 v3.1.1,但它的 API 又有 v3 v2 之分,社区通常所说的 v3 与 v2 都是指 API 的版本号。从 etcd 2.3 版本开始推出了一个实验性的全新 v3 版本 AP
  • oracle12数据备份和恢复

    万次阅读 2020-12-05 01:19:11
    cmd管理员输入: imp testuser/userpw@databasesname file=d:/databasesname.dmp fromuser=testuser full=y statistics=none 若导入失败,请用最新版plsql:工具-导入表-选择dmp文件导入即可。
  • 本篇博文不会涉及非常详细的操作步骤,仅把备份恢复的关键步骤记录,等后续有真正的使用场景的时候,再来实操。 hadoop hdfs分布式文件存储系统介绍 简单介绍下Hadoop生态圈中非常常用的几个组件: hdfs...
  • 添加镜像地址的目的是为了提高国内用户软件下载的速度,编辑(新建)文件gitlab-ce.repo,指令: vi /etc/yum.repos.d/gitlab-ce.repo 输入: [gitlab-ce] name=gitlab-ce # 清华大学的镜像源 baseurl=...
  • EMC公司今天宣布推出新一代备份恢复解决方案,进一步拓展了该公司业内最广泛的备份恢复产品组合。新推出的解决方案包括世界最大的单一系统虚拟磁带库(VTL),业界领先的重复数据删除、复制备份软件之最新版本,并...
  • MySQL 数据库备份可以用于系统崩溃、硬件故障或者用户误删除数据时的...本文介绍了 MySQL 的各种备份方式、策略实际案例,包括mysqldump、mysqlpump 逻辑备份与还原、Xtrabackup 物理全备、增量备份与时间点恢复
  • MongoDB的数据库如何备份和恢复

    千次阅读 2017-07-07 13:56:33
    摘要: MongoDB数据库如何备份恢复MongoDB数据库应如何操作?最近数据库多灾多难,这些问题也成为开发者关注的重点。2016年12月爆出MongoDB数据库安全问题(见MongoDB黑客赎金事件解读及防范)。 MongoDB...
  • Day526.数据库备份恢复 -mysql

    千次阅读 2022-02-01 16:34:23
    物理备份恢复速度比较快,但占用空间比较大,MySQL中可以用 xtrabackup 工具来进行物理备份。 逻辑备份: 对数据库对象利用工具进行导出工作,汇总入备份文件内。逻辑备份恢复速度慢,但占用空间小,更灵活。MySQL...
  • BAREOS(来自于BAckup and REcovery Open Sourced的缩写)是源于...我们选用Bareos的主要原因是Bareos的Web界面支持完整的备份和恢复功能(不支持配置,配置仍需要通过CLI完成),另一个原因是Bareos的社区较为活跃。
  • PX-Backup — K8S上备份和恢复应用的最佳方式 Portworx近期发布了最新版本的PX-Backup。PX-Backup允许用户通过简单的点击即可备份和恢复所有的Kubernetes应用,从而提供了强有力的数据保护,而数据保护对DevOps...
  • 下面是从csdn上看到的一篇好文章,转载自欧阳鹏先生于2017年08月10日分享的gitlab备份,操作过程超详细。 在此感谢众多热心分享的人。 (本来我也想补充一下gitlab相关的总结,看到这篇后直接放弃自己写了,就进行了...
  • 本书是关于RMAN 备份恢复最新版本。Oracle Database 11g 是值得信赖的数据库版本,其RMAN 对先前版本进行了改进,增加了一些新的功能出色的新特性。从Oracle 8版本开始,多年来RMAN 不断地进行改进以期获得...
  • MySQL——备份恢复(MDP、XBK)

    千次阅读 2020-03-11 01:21:52
    文章目录一、备份恢复的计划与策略备份的种类二、逻辑备份与恢复逻辑备份命令及参数逻辑备份的工具三、物理备份与恢复物理备份的命令及参数物理备份的工具 一、备份恢复的计划与策略 备份恢复所需要考虑的因素: 1、...
  • Android adb命令备份恢复手机信息

    千次阅读 2021-06-04 03:01:23
    假设你已经在Windows下安装了Android SDK,并且更新到最新版步骤:1.通过USB连接你的设备,打开命令行2.一般地,输入”adb devices“检测设备是否连接正常有个命令“ adb backup”(简化写法)可以使你备份整个系统。...
  • 这款软件能够快速安全帮大家恢复iOS设备数据,如删除的照片、视频、信息、通讯录等,支持删除恢复、iTunes备份恢复以及iCloud备份恢复三种恢复方式,适用于目前所有的iPhoneiPad 软件特色 万能iOS数据恢复 你...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 71,196
精华内容 28,478
关键字:

备份和恢复最新版下载