介绍
PostgreSQL是一个开源的数据库平台,网络和其易于维护,成本效益的移动应用开发者,并与其他开源技术的简单整合颇为流行。
维护PostgreSQL环境的一个关键任务是定期备份其数据库。 备份构成任何组织的灾难恢复(DR)过程的一部分。 这是重要的几个原因:
- 保护由于底层基础架构组件(如存储或服务器本身)故障而导致的数据丢失
- 保护数据损坏和不必要或恶意的数据丢失
- 将生产数据库迁移到开发或测试环境中
通常,数据库备份和恢复的责任落在DBA的肩上。 然而,在较小的组织或初创公司中,系统管理员,DevOps工程师或程序员经常必须创建自己的数据库后端。 因此,对于使用PostgreSQL的每个人来说,了解备份如何工作以及如何从备份中恢复非常重要。
在本教程中,您将设置Barman备份服务器,从主数据库服务器进行备份,并还原到备用服务器。
PostgreSQL备份方法简介
在启动Barman设置之前,让我们花一点时间来查看PostgreSQL可用的备份类型及其用途。 (有关备份策略更广阔的概述,请阅读我们关于文章的有效备份 。)
PostgreSQL提供两种类型的备份方法:
- 逻辑备份
- 物理备份
逻辑备份类似于数据库的快照。 这些是使用创建pg_dump
或者pg_dumpall
工具附带的PostgreSQL。 逻辑备份:
- 备份单个数据库或所有数据库
- 仅备份模式,只是数据,单个表或整个数据库(模式和数据)
- 以专有二进制格式或纯SQL脚本创建备份文件
- 可以使用恢复
pg_restore
实用工具,还附带的PostgreSQL - 不提供点即时恢复(PITR)
这意味着如果您在早上2:00 AM对数据库进行逻辑备份,那么当从中还原时,已还原的数据库将与上午2:00时一样。 没有办法在特定时间点停止恢复,例如1:30 AM。 如果您在上午10:00恢复备份,则已丢失了8小时的数据。
物理备份与逻辑备份不同,因为它们仅处理二进制格式,并进行文件级备份。 物理备份:
- 提供时间点恢复
- 备份PostgreSQL的数据目录和WAL(预写日志)文件的内容
- 占用更大的磁盘空间
- 使用PostgreSQL的
pg_start_backup
和pg_stop_backup
命令。 然而,这些命令需要脚本化,这使得物理备份是一个更复杂的过程 - 不要备份单个数据库,只有模式等。这是一个全有或全无的方法
WAL文件包含发生在一个数据库事务的列表(INSERT,UPDATE或DELETE)。 包含数据的实际数据库文件位于数据目录中。 因此,当涉及到从物理备份恢复到一个时间点时,PostgreSQL首先恢复数据目录的内容,然后从WAL文件播放其上的事务。 这使数据库在一致的时间状态。
Barman备份如何工作
传统上,PostgreSQL的数据库管理员会写自己的备份脚本和预定cron
作业来实现物理备份。 巴尔曼以标准化的方式做到这一点。
酒保或备份和恢复管理器是从免费的,开源PostgreSQL的备份工具2ndQuadrant -专业的Postgres的解决方案的公司。 Barman是用Python编写的,并为您的PostgreSQL实例提供了一种简单直观的物理备份和恢复方法。 使用Barman的一些好处是:
- 它是完全免费的
- 这是一个维护良好的应用程序,并提供从供应商的专业支持
- 从编写和测试复杂的脚本,并解放了DBA /系统管理员
cron
作业 - 可以将多个PostgreSQL实例备份到一个中央位置
- 可以恢复到相同的PostgreSQL实例或不同的实例
- 提供压缩机制以最小化网络流量和磁盘空间
目标
在本教程中,我们将创建三个DigitalOcean Droplet,在其中两个机器上安装PostgreSQL 9.4,并在第三个机器上安装Barman。
PostgreSQL服务器之一将是我们的主数据库服务器:这是我们将创建我们的生产数据库的地方。 第二个PostgreSQL实例将为空,并作为备用计算机处理,我们可以从备份中恢复。
Barman服务器将与主数据库服务器通信,并执行物理备份和WAL归档。
然后,我们将通过从我们的实时数据库中删除一个表来模拟一个“灾难”。
最后,我们将把备份的PostgreSQL实例从Barman服务器恢复到备用服务器。
先决条件
要学习本教程,您需要创建三个DigitalOceanDroplet(或您自己的Linux服务器),每个至少有2 GB的内存和2个CPU核心。 我们不会介绍创建Droplet的细节; 你可以找到更多的信息在这里 。
所有这三个服务器应具有相同的操作系统(CentOS 7位64位)。
我们将命名机器如下:
- 主数据库服务器 (我们将其记的IP地址作为主数据库服务器-IP)
- 待机DB服务器 (我们将其记的IP地址作为备用-DB-服务器IP)
- 酒保备份服务器 (我们将其记的IP地址作为酒保,备份服务器IP)
机器的实际IP地址可以从DigitalOcean控制面板找到。
您还应该在每个服务器上设置一个sudo用户,并将其用于一般访问。 大多数命令会两个不同的用户(Postgres的和酒保 )执行,但你需要在每个服务器上Sudo用户,以及这样你就可以切换到这些帐户。 要了解如何特权工作sudo的,看到这个关于启用sudo访问DigitalOcean教程 。
注:本教程将使用默认的Barman安装目录备份位置。 在CentOS的,这个位置是: /var/lib/barman/
。 2ndQuadrant建议最好保留默认路径。 在实际使用情况下,根据数据库的大小和要备份的实例数,应该检查托管此目录的文件系统是否有足够的空间。
警告: 你不应该从本教程在生产服务器上运行的任何命令,查询,或配置 。 本教程将涉及更改配置和重新启动PostgreSQL实例。 在没有适当规划和授权的情况下在活动环境中执行此操作将意味着您的应用程序中断。
第1步 - 安装PostgreSQL数据库服务器
首先,我们将在主数据库服务器和备用-DB的服务器上安装PostgreSQL 9.4设置我们的数据库环境。
请完成从PostgreSQL安装步骤这一LEPP栈教程 。 在本教程中,您需要:
- 按照部分第一步-安装PostgreSQL
- 按照部分第二步-配置的PostgreSQL
在第二步-配置PostgreSQL的 ,而不是在更改pg_hba.conf
文件,以允许对数据库的访问一个Web服务器,添加此行,酒保服务器可以连接,使用酒保备份服务器的 IP地址,然后/32
:
host all all barman-backup-server-ip/32 trust
这将配置PostgreSQL以接受来自Barman服务器的任何连接。
该部分中的其余说明可以按原样执行。
注意:安装PostgreSQL将创建一个操作系统用户称为数据库服务器上的Postgres。 此帐户没有密码; 你将从你的sudo用户切换到它。
请确保你已经安装PostgreSQL的主数据库服务器和备用-DB-服务器上,并且您已经允许从酒保备份的服务器上两者的访问。
接下来,我们将向主数据库服务器添加一些示例数据。
第2步 - 创建PostgreSQL数据库和表
一旦PostgreSQL的安装,并同时在机器配置,我们将一些示例数据添加到主数据库服务器来模拟生产环境。
在主数据库服务器 ,切换到用户的Postgres:
sudo su - postgres
启动psql
实用程序来访问数据库服务器:
psql
从psql
提示符下运行以下命令来创建一个数据库,并切换到它:
CREATE DATABASE mytestdb;
\connect mytestdb;
输出消息会告诉你,你现在连接到数据库mytestdb
为用户postgres
。
接下来,在数据库中添加两个表:
CREATE TABLE mytesttable1 (id integer NULL);
CREATE TABLE mytesttable2 (id integer NULL);
这些被命名为mytesttable1
和mytesttable2
。
退出通过键入客户端工具\q
,然后按ENTER
。
第3步 - 安装酒保
现在我们将在备份服务器上安装Barman,这将控制和存储我们的备份。
完成酒保备份的服务器上此步骤。
为此,您首先需要安装以下存储库:
- 企业Linux(EPEL)存储库的额外软件包
- PostgreSQL全球开发组RPM存储库
运行以下命令安装EPEL:
sudo yum -y install epel-release
运行这些命令来安装PostgreSQL仓库:
sudo wget http://yum.postgresql.org/9.4/redhat/rhel-7Server-x86_64/pgdg-centos94-9.4-1.noarch.rpm
sudo rpm -ivh pgdg-centos94-9.4-1.noarch.rpm
最后,运行此命令安装Barman:
sudo yum -y install barman
注意:安装Barman将创建一个操作系统,用户调用的酒保 。 此帐户没有密码; 您可以从您的sudo用户帐户切换到此用户。
酒吧安装! 现在,让我们确保服务器可以安全地连接到彼此。
第4步 - 配置服务器之间的SSH连接
在本节中,我们将建立一个主数据库服务器和酒保备份服务器 ,反之亦然之间的安全连接,密码的SSH密钥。
同样,我们将建立SSH密钥待机-DB服务器和酒保备份服务器之间,反之亦然。
这是为了确保PostgreSQL(在两个数据库服务器上)和Barman可以在备份和恢复期间彼此“交谈”。
在本教程中,您需要确保:
- Postgres的用户可以从主数据库服务器的远程连接到酒保备份服务器
- 用户可以Postgres的从待机-DB服务器远程连接到酒保备份服务器
- 用户可以酒保从酒保备份服务器远程连接到主数据库服务器
- 用户可以酒保从酒保备份服务器远程连接到备用数据库服务器
我们不会详细介绍SSH的工作原理。 有一个关于DigitalOcean很好的文章有关SSH的要领,你可以参考一下。
所有你需要的命令,包括在这里,虽然。
我们会告诉你如何设置为用户的Postgres连接从主数据库服务器到酒保备份服务器连接做一次。
从主数据库服务器 ,切换到用户的Postgres如果不是已经是当前用户:
sudo su - postgres
执行以下命令,生成SSH密钥对。
ssh-keygen -t rsa
按接受针对密钥文件的默认位置和名称ENTER
。
按ENTER
两次即可在无需任何密码的私钥。
一旦密钥生成,会有.ssh
postgres用户的主目录下创建的目录,里面有钥匙。
现在,您需要将SSH公钥复制到authorized_keys
酒保用户的下文件.ssh
目录酒保备份的服务器上。
注意:可惜你不能使用ssh-copy-id barman@ barman-backup-server-ip
这里命令。 这是因为该命令会要求酒保用户的密码,这是不是默认设置。 因此,您需要手动复制公用密钥内容。
运行以下命令输出的Postgres用户的公钥内容:
cat ~/.ssh/id_rsa.pub
复制输出的内容。
切换至连接酒保备份服务器的服务器和交换机到用户酒保控制台:
sudo su - barman
运行以下命令来创建.ssh
目录,设置其权限,公钥内容复制到authorized_keys
文件,并最终使该文件可读可写的:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "public_key_string" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
确保将开始漫长的公共密钥字符串ssh-rsa
引号之间,而不是public_key_string
。
您已将密钥复制到远程服务器。
现在,测试连接,切换回主数据库服务器 ,并从那里测试连接:
ssh barman@barman-backup-server-ip
有关远程服务器的真实性的初始警告之后没有被公知并且接受提示,连接应该从主数据库服务器服务器酒保备份服务器来建立。 如果成功,通过执行退出会话的exit
命令。
exit
你需要设置SSH密钥连接三次。你可以跳过制作.ssh
目录,如果它已经做(虽然这不是必要的)。
- 再次运行相同的命令,从待机-DB服务器此时酒保备份服务器
- 它们运行第三次,这次从酒保备份的服务器上的酒保用户发起,并打算postgres用户主数据库的服务器上
- 最后,运行命令的关键,从酒保用户酒保备份的服务器上复制到postgres用户待机-DB-服务器上
请确保以各种方式测试连接,以便您可以接受有关新连接的初始警告。
在待机状态下-DB服务器 :
ssh barman@barman-backup-server-ip
从酒保备份服务器 :
ssh postgres@main-db-server-ip
从酒保备份服务器 :
ssh postgres@standby-db-server-ip
注:确保所有的三个服务器之间的SSH连接是备份工作的要求。
第5步 - 配置Barman备份
您现在将配置Barman备份您的主PostgreSQL服务器。
对酒保的主配置文件是/etc/barman.conf
。 该文件包含一个全局参数部分,以及您要备份的每个服务器的单独部分。 默认的文件包含所谓的主要样本的PostgreSQL服务器,它被注释掉的部分。 您可以使用它作为指南来设置要备份的其他服务器。
分号( ;
)在一行的开头意味着行注释掉。 与大多数基于Linux的应用程序一样,Barman的注释掉配置参数意味着系统将使用默认值,除非您取消注释并输入其他值。
一个这样的参数是configuration_files_directory
,其具有一默认值/etc/barman.d
。 这意味着,在启用时,Barman将使用.conf
文件,在该目录中为不同的Postgres服务器的备份配置。 如果您发现主文件太长,可以为要备份的每个服务器单独创建文件。
为了简化本教程,我们将把所有内容放在默认配置文件中。
打开/etc/barman.conf
在文本编辑器为你的sudo用户 ( 酒保只读取权限):
sudo vi /etc/barman.conf
全局参数下的定义[barman]
部分。 在此部分下,进行以下更改。 完成的值显示在项目符号下面:
- 取消注释行
compression
并保留默认值gzip.
这意味着PostgreSQL的WAL文件-当备份目录下复制-将被保存在gzip压缩格式 - 注释为线
reuse_backup
和保留的默认值link
。 当创建PostgreSQL服务器的完整备份时,Barman将尝试通过创建文件级增量备份来节省备份目录中的空间。 这使用rsync和硬链接。 创建增量完全备份与任何数据重复数据删除方法具有相同的优点:节省时间和磁盘空间 - 取消注释行
immediate_checkpoint
并将其值设置为true
。 此参数设置可以确保当Barman开始完整备份,它将请求PostgreSQL的执行CHECKPOINT
。 检查点确保PostgreSQL的内存缓存中的任何修改数据都被写入数据文件。 从备份角度来看,这可以添加一些值,因为BARMAN将能够备份最新的数据更改 - 取消注释行
basebackup_retry_times
并设值为3
。 当创建完整备份时,如果复制操作由于某种原因失败,Barman将尝试连接到PostgreSQL服务器三次 - 注释为线
basebackup_retry_sleep
和保留的默认值30
。 每次重试之间将有30秒的延迟 - 取消对行
last_backup_maximum_age
并将其值设置为1 DAYS
新设置应如下所示:
[barman]
barman_home = /var/lib/barman
. . .
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link
. . .
immediate_checkpoint = true
. . .
basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS
我们在这里做的是这样:
- 保留默认备份位置
- 指定备份空间应保存。 WAL日志将被压缩,基本备份将使用增量数据复制
- 如果由于某种原因完全备份中途失败,Barman将重试三次
- PostgreSQL服务器的上次完整备份的时间不应大于1天
在文件的末尾,添加一个新的部分。 它的头应该说[main-db-server]
方括号内。 (如果要使用Barman备份更多数据库服务器,则可以为每个服务器创建一个类似这样的块,并为每个服务器使用唯一的标头名称。)
此部分包含数据库服务器的连接信息和几个唯一的备份设置。
在新块中添加以下参数:
[main-db-server]
description = "Main DB Server"
ssh_command = ssh postgres@main-db-server-ip
conninfo = host=main-db-server-ip user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main
该retention_policy
设置意味着Barman会覆盖旧的完整备份文件和WAL自动记录,同时保持足够的备份为7天恢复窗口。 这意味着我们可以在过去的七天时间整个数据库服务器恢复到任意时间点。 对于生产系统,你应该设置这个值越高,所以你手头上有旧的备份。
你需要在使用主数据库服务器的IP地址ssh_command
和conninfo
参数。 否则,您可以准确复制上述设置。
修改后的文件的最终版本应该是这样,减去所有的注释和未修改的设置:
[barman]
barman_home = /var/lib/barman
. . .
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link
. . .
immediate_checkpoint = true
. . .
basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS
. . .
[main-db-server]
description = "Main DB Server"
ssh_command = ssh postgres@main-db-server-ip
conninfo = host=main-db-server-ip user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main
保存并关闭文件。
接下来,我们将确保我们的主数据库服务器配置为进行备份。
第6步 - 配置postgresql.conf文件
还有就是被主数据库的服务器上做了一个最后的配置,对备份(或存档)模式切换。
首先,我们需要找到从酒保备份服务器传入备份目录的价值。 在Barman服务器,切换到用户酒保 :
sudo su - barman
运行此命令以查找传入备份目录:
barman show-server main-db-server | grep incoming_wals_directory
这应该输出这样:
barman show-server command outputincoming_wals_directory: /var/lib/barman/main-db-server/incoming
记下的值incoming_wals_directory
; 在这个例子中,它是/var/lib/barman/main-db-server/incoming
。
现在切换到主数据库服务器的控制台。
切换到用户的Postgres如果不是当前用户已经。
打开postgresql.conf
在文本编辑器文件中:
vi $PGDATA/postgresql.conf
对文件进行以下更改:
- 取消对
wal_level
参数并将其值设置为archive
,而不是minimal
- 取消对
archive_mode
参数,将其值设置on
,而不是off
- 取消对
archive_command
参数,并将其值设置为'rsync -a %p barman@ barman-backup-server-ip : /var/lib/barman/main-db-server/incoming /%f'
而不是''
使用Barman服务器的IP地址。 如果你得到了一个不同的值incoming_wals_directory
,使用一个替代
wal_level = archive # minimal, archive, hot_standby, or logical
. . .
archive_mode = on # allows archiving to be done
. . .
archive_command = 'rsync -a %p barman@barman-backup-server-ip:/var/lib/barman/main-db-server/incoming/%f' # command to use to archive a logfile segment
切换回你的sudo用户 。
重新启动PostgreSQL:
sudo systemctl restart postgresql-9.4.service
注意:如果要配置现有的生产PostgreSQL的情况下,有一个很好的机会,这三个参数将已经设置。 然后,您将不得不添加/修改只有archive_command
这样的PostgreSQL将其WAL文件复制到备份服务器参数。
第7步 - 测试酒保
它现在时间,以检查是否Barman具有正确设置所有配置,并可以连接到主数据库的服务器 。
在酒保备份服务器 ,切换到用户酒保 ,如果它不是当前用户。 运行以下命令测试与主数据库服务器的连接:
barman check main-db-server
需要注意的是,如果你在方括号中输入一个不同的Nameservers块/etc/barman.conf
文件中的第5步,你应该使用该名称来代替。
如果一切正常,输出应如下所示:
barman check command outputServer main-db-server:
PostgreSQL: OK
archive_mode: OK
wal_level: OK
archive_command: OK
continuous archiving: OK
directories: OK
retention policy settings: OK
backup maximum age: FAILED (interval provided: 1 day, latest backup age: No available backups)
compression settings: OK
minimum redundancy requirements: OK (have 0 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
不要担心备份的最大年龄FAILED
状态。 这是因为我们已配置Barman,以便最新的备份不应该超过1天。 没有备份,所以检查失败。
如果任何其他参数都处于FAILED
状态,您应该进一步调查,并继续之前解决问题。
检查失败可能有多个原因:例如,Barman无法登录到Postgres实例,Postgres未配置为WAL归档,SSH不能在服务器之间工作等。无论是什么原因,它需要固定之前备份可能发生。 运行前面的步骤,并确保所有的连接工作。
要获取使用Barman配置的PostgreSQL服务器的列表,请运行以下命令:
barman list-server
现在它应该显示:
main-db-server - Main DB Server
第8步 - 创建第一个备份
现在你已经准备好了酒保,让我们手动创建一个备份。
运行以下命令为酒保备份服务器 ,让您的第一次备份的酒保用户:
barman backup main-db-server
再次,在main-db-server
值是你如在服务器块的头部进入/etc/barman.conf
文件中的第5步。
这将启动PostgreSQL数据目录的完整备份。 因为我们的实例只有一个具有两个表的小型数据库,所以它应该很快完成。
Starting backup for server main-db-server in /var/lib/barman/main-db-server/base/20151111T051954
Backup start at xlog location: 0/2000028 (000000010000000000000002, 00000028)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup size: 26.9 MiB. Actual size on disk: 26.9 MiB (-0.00% deduplication ratio).
Backup end at xlog location: 0/20000B8 (000000010000000000000002, 000000B8)
Backup completed
Processing xlog segments for main-db-server
Older than first backup. Trashing file 000000010000000000000001 from servermain-db-server
000000010000000000000002
000000010000000000000002.00000028.backup
备份文件位置
那么备份会保存在哪里? 为了找到答案,列出的内容/var/lib/barman
目录:
ls -l /var/lib/barman
将有一个目录有: main-db-server
。 这是服务器Barman当前配置为备份,其备份生活在那里。 (如果配置Barman备份其他服务器,会有每个服务器创建一个目录)在main-db-server
目录中,将有三个子目录:
-
base
:这是基本备份文件的保存 -
incoming
:在PostgreSQL将其完成的WAL文件到这个目录进行归档 -
wals
:Barman复制的内容incoming
目录到wals
目录
在还原期间,Barman将从恢复内容base
目录复制到目标服务器的数据目录。 然后,它会使用文件从wals
目录申请交易的变化,并把目标服务器到一致状态。
列出备份
有一个特定的Barman命令列出服务器的所有备份。 这命令barman list-backup
。 运行以下命令来看看它返回我们的main-db-server
:
barman list-backup main-db-server
Outputmain-db-server 20151111T051954 - Wed Nov 11 05:19:46 2015 - Size: 26.9 MiB - WAL Size: 0 B
- 输出的第一部分是服务器的名称。 在这种情况下,
main-db-server
- 第二部分 - 长字母数字值 - 是备份的备份ID。 备用ID用于唯一标识任何备份Barman所做的。 在这种情况下,它的
20151111T051954
。 你需要为下一个步骤的备份ID - 第三条信息告诉您何时进行备份
- 第四部分是基本备份的大小(在这种情况下为26.9 MB)
- 字符串的第五个和最后一部分给出了备份的WAL归档的大小
要了解更多详细信息有关备份,执行使用服务器的名称这个命令,(备份ID 20151111T051954
从先前的命令在我们的例子):
barman show-backup main-db-server backup-id
将显示一组详细的信息:
OutputBackup 20151111T051954:
Server Name : main-db-server
Status : DONE
PostgreSQL Version : 90405
PGDATA directory : /var/lib/pgsql/9.4/data
Base backup information:
Disk usage : 26.9 MiB (26.9 MiB with WALs)
Incremental size : 26.9 MiB (-0.00%)
Timeline : 1
Begin WAL : 000000010000000000000002
End WAL : 000000010000000000000002
WAL number : 1
WAL compression ratio: 99.84%
Begin time : 2015-11-11 05:19:44.438072-05:00
End time : 2015-11-11 05:19:46.839589-05:00
Begin Offset : 40
End Offset : 184
Begin XLOG : 0/2000028
End XLOG : 0/20000B8
WAL information:
No of files : 0
Disk usage : 0 B
Last available : 000000010000000000000002
Catalog information:
Retention Policy : VALID
Previous Backup : - (this is the oldest base backup)
Next Backup : - (this is the latest base backup)
要向下钻取更多内容以查看哪些文件进入备份,请运行以下命令:
barman list-files main-db-server backup-id
这将提供从特定备份还原所需的基本备份和WAL日志文件的列表。
第9步 - 计划备份
理想情况下,您的备份应按计划自动进行。
在此步骤中,我们将自动执行备份,我们会告诉Barman对备份执行维护,以便删除保留策略之前的文件。 为使调度,为酒保备份的服务器上的酒保用户(切换到如果需要该用户)运行以下命令:
crontab -e
这将打开一个crontab
为用户酒保文件。 编辑文件,添加这些行,然后保存并退出:
30 23 * * * /usr/bin/barman backup main-db-server
* * * * * /usr/bin/barman cron
第一个命令将每天晚上11:30 PM运行主数据库服务器的完整备份。 (如果你使用的服务器不同的名称/etc/barman.conf
文件,使用该名称来代替。)
第二个命令将每分钟运行一次,并对WAL文件和基本备份文件执行维护操作。
第10步 - 模拟“灾难”
您现在将看到如何从刚刚创建的备份还原。 为了测试恢复,让我们先模拟一个“灾难”的场景,在那里你已经丢失了一些数据。
我们在这里放一张桌子。 不要在生产数据库上执行此操作!
返回到主数据库服务器的控制台,并切换到用户的Postgres如果不是已经是当前用户。
启动psql
实用程序:
psql
从psql
提示符下,执行下面的命令来切换数据库上下文mytestdb
:
\connect mytestdb;
接下来,列出数据库中的表:
\dt
输出将显示您在本教程开头创建的表:
Output List of relations
Schema | Name | Type | Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres
现在,运行此命令删除其中一个表:
drop table mytesttable2;
如果现在执行的\dt
再次命令:
\dt
你会看到只有mytesttable1
遗体。
这是您要从备份还原的数据丢失情况的类型。 在这种情况下,你会恢复备份到一个单独的服务器: 待机-DB服务器 。
第1步1 - 恢复或迁移到远程服务器
您可以按照此部分还原备份,或将最新的PostgreSQL备份迁移到新服务器。
转到待机-DB服务器 。
首先,以sudo用户身份停止PostgreSQL服务。 (如果您尝试在服务正在运行时运行恢复,重新启动将会阻塞)。
sudo systemctl stop postgresql-9.4.service
一旦服务站,去酒保备份服务器 。 切换到用户酒保如果不是已经是当前用户。
让我们找到最新备份的详细信息:
barman show-backup main-db-server latest
Backup 20160114T173552:
Server Name : main-db-server
Status : DONE
PostgreSQL Version : 90405
PGDATA directory : /var/lib/pgsql/9.4/data
Base backup information:
. . .
Begin time : 2016-01-14 17:35:53.164222-05:00
End time : 2016-01-14 17:35:55.054673-05:00
从输出,记下打印在第一行(备份ID 20160114T173552
上文)。 如果latest
备份有你想要的数据,你可以使用latest
的备份ID。
同时检查备份时,从Begin time
字段( 2016-01-14 17:35:53.164222-05:00
以上)。
接下来,运行此命令从酒保备份服务器 到备用数据库服务器恢复指定的备份:
barman recover --target-time "Begin time" --remote-ssh-command "ssh postgres@standby-db-server-ip" main-db-server backup-id /var/lib/pgsql/9.4/data
这里有很多选项,参数和变量,所以让我们解释一下。
-
--target-time " Begin time "
:使用从开始时间show-backup
命令 -
--remote-ssh-command "ssh postgres@ standby-db-server-ip "
使用待机DB服务器的IP地址 -
main-db-server
:从你使用的数据库服务器的名称/etc/barman.conf
文件 -
backup-id
:从使用备份IDshow-backup
命令,或使用latest
,如果这就是你想要的 -
/var/lib/pgsql/9.4/data
:要恢复你想要备份的路径。 此路径将成为备用服务器上Postgres的新数据目录。 在这里,我们在CentOS中选择了Postgres的默认数据目录。 对于实际用例,请选择适当的路径
要成功恢复操作,您应该收到如下输出:
Starting remote restore for server main-db-server using backup backup-id
Destination directory: /var/lib/pgsql/9.4/data
Doing PITR. Recovery target time: Begin time
Copying the base backup.
Copying required WAL segments.
Generating recovery.conf
Identify dangerous settings in destination directory.
IMPORTANT
These settings have been modified to prevent data losses
postgresql.conf line 207: archive_command = false
Your PostgreSQL server has been successfully prepared for recovery!
现在切换到备用数据库服务器的控制台一次。 由于sudo的用户 ,启动PostgreSQL服务:
sudo systemctl start postgresql-9.4.service
这应该是!
让我们验证我们的数据库是否已启动。 切换到用户的Postgres并启动psql
实用程序:
sudo su - postgres
psql
切换数据库上下文mytestdb
并列出它的表:
\connect mytestdb;
\dt
List of relations
Schema | Name | Type | Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres
(2 rows)
该列表应该在数据库中显示两个表。 换句话说,你刚刚恢复了删除的表。
根据您的更大的恢复策略,你现在可能要故障转移到备用数据库服务器 ,或者你可能要检查恢复的数据库是否正常工作,然后通过运行本节再次恢复到主DB-服务器 。
要恢复到任何其他服务器,只需确保您已安装PostgreSQL并与Barman服务器建立了适当的连接,然后使用目标恢复服务器的IP地址来跟踪此部分。
结论
在本教程中,我们已经了解了如何安装和配置Barman来备份PostgreSQL服务器。 我们还学习了如何从这些备份中恢复或迁移。
With careful consideration, Barman can become the central repository for all your PostgresSQL databases. It offers a robust backup mechanism and a simple command set. However, creating backups is only half the story. You should always validate your backups by restoring them to a different location. This exercise should be done periodically.
Some questions for fitting Barman into your backup strategy:
- How many PostgreSQL instances will be backed up?
- Is there enough disk space on the Barman server for hosting all the backups for a specified retention period? How can you monitor the server for space usage?
- Should all the backups for different servers start at the same time or can they be staggered throughout off-peak period? Starting backups of all servers at the same time can put unnecessary strain on the Barman server and the network
- Is the network speed between the Barman server and Postgres servers reliable?
Another point to be mindful of is that Barman cannot backup and restore individual databases. It works on the file system level and uses an all-or-nothing approach. During a backup, the whole instance with all its data files are backed up; when restoring, all those files are restored. Similarly, you can't do schema-only or data-only backups with Barman.
We therefore recommend you design your backup strategy so it makes use of both logical backups with pg_dump
or pg_dumpall
and physical backups with Barman. That way, if you need to restore individual databases quickly, you can use pg_dump
backups. For point-in-time recovery, use Barman backups.