是一个简单有效的将 PostgreSQL 备份到云端的工具。 就其主要功能而言，它是流行工具的继承者 ，但用 Go 重写。 但 WAL-G 有一个重要的新功能——增量副本。 增量副本 存储自上一个备份版本以来已更改的文件页面。 WAL-G 实现了相当多的并行备份技术。 WAL-G 比 WAL-E 快得多。
有关 wal-g 工作原理的详细信息可以在文章中找到：
S3 存储协议已成为流行的数据存储方式。 S3 的优势之一是能够通过 API 进行访问，这允许您组织与存储的灵活交互，包括公共读取访问，而存储中的信息更新只能由授权人员进行。
有几种在 S3 协议上运行的存储的公共和私有实现。 今天我们将介绍一种流行的小型存储解决方案 - Minio。
单个 PostgreSQL 服务器足以测试 wal-g，并且使用 Minio 作为 S3 的替代品。
迷你服务器
Minio安装
yum -y install yum-plugin-copr
yum copr enable -y lkiesow/minio
yum install -y minio编辑 /etc/minio/minio.conf 中的 AccessKey 和 SecretKey
vi /etc/minio/minio.conf如果你在Minio之前不会使用nginx，那么你需要改变
--address 127.0.0.1:9000--address 0.0.0.0:9000启动 Minio
systemctl start minio进入Minio网页界面 并创建一个存储桶（例如，pg-backups）。
数据库服务器
WAL-G rpm 是由我（Anton Patsev）组装的。 , .
如果没有基于 RPM 的系统，请使用官方的 通过安装。
除了 wal-g 二进制文件之外，rpm 还包含从 /etc/wal-gd/server-s3.conf 文件导入变量的脚本。
backup-fetch.sh
backup-list.sh
backup-push.sh
wal-fetch.sh
wal-g-run.sh
wal-push.sh安装沃尔格。
yum -y install yum-plugin-copr
yum copr enable -y antonpatsev/wal-g
yum install -y wal-g检查 wal-g 版本。
wal-g --version
wal-g version v0.2.14根据您的需要编辑 /etc/wal-gd/server-s3.conf。
数据库集群使用的配置文件和数据文件传统上一起存储在集群数据目录中，通常称为 PGDATA
#!/bin/bash
export PG_VER="9.6"
export WALE_S3_PREFIX="s3://pg-backups" # бакет, который мы создали в S3
export AWS_ACCESS_KEY_ID="xxxx" # AccessKey из /etc/minio/minio.conf
export AWS_ENDPOINT="http://ip-адрес-сервера-minio:9000"
export AWS_S3_FORCE_PATH_STYLE="true"
export AWS_SECRET_ACCESS_KEY="yyyy" # SecretKey из /etc/minio/minio.conf
export PGDATA=/var/lib/pgsql/$PG_VER/data/
export PGHOST=/var/run/postgresql/.s.PGSQL.5432 # Сокет для подключения к PostgreSQL
export WALG_UPLOAD_CONCURRENCY=2 # Кол-во потоков для закачки
export WALG_DOWNLOAD_CONCURRENCY=2 # Кол-во потоков для скачивания
export WALG_UPLOAD_DISK_CONCURRENCY=2 # Кол-во потоков на диске для закачки
export WALG_DELTA_MAX_STEPS=7
export WALG_COMPRESSION_METHOD=brotli # Какой метод сжатия использовать.
配置 WAL-G 时，您可以指定 WALG_DELTA_MAX_STEPS - 增量备份相对于基础备份的最大步数，并指定增量复制策略。 您可以从最后一个现有增量创建副本，也可以从原始完整备份创建增量。 如果数据库中的同一组件始终在更改，即相同的数据不断更改，则这是必要的。
安装数据库。
yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.
noarch.rpm
yum install -y postgresql96 postgresql96-server mc我们初始化数据库。
/usr/pgsql-9.6/bin/postgresql96-setup initdb
Initializing database ... OK如果您在 1 台服务器上进行测试，则需要重新配置 wal_level 参数以对低于版本 10 的 PostgreSQL 进行存档，以及对 PostgreSQL 版本 10 及更早版本进行副本。
wal_level = archive让我们使用 PostgreSQL 本身每 60 秒备份一次 WAL 存档。 在产品上，您将拥有不同的 archive_timeout 值。
archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Каждые 60 секунд будет выполнятся команда archive_command.启动 PostgreSQL
systemctl start postgresql-9.6在一个单独的控制台中，我们查看 PostgreSQL 日志中的错误：（将 postgresql-Wed.log 更改为当前日志）。
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log我们来看看 psql。
su - postgres
psql在psql中创建数据库
在数据库test1中创建表。
create database test1;切换到数据库测试。
postgres=# c test1;我们创建表indexing_table。
test1=# CREATE TABLE indexing_table(created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());添加数据。
我们开始插入数据。 我们等待10-20分钟。
#!/bin/bash
# postgres
while true; do
psql -U postgres -d test1 -c "INSERT INTO indexing_table(created_at) VALUES (CURRENT_TIMESTAMP);"
sleep 60;
done请务必进行完整备份。
su - postgres
/usr/local/bin/backup-push.sh我们查看数据库test1中表中的记录
select * from indexing_table;
2020-01-29 09:41:25.226198+
2020-01-29 09:42:25.336989+
2020-01-29 09:43:25.356069+
2020-01-29 09:44:25.37381+
2020-01-29 09:45:25.392944+
2020-01-29 09:46:25.412327+
2020-01-29 09:47:25.432564+
2020-01-29 09:48:25.451985+
2020-01-29 09:49:25.472653+
2020-01-29 09:50:25.491974+
2020-01-29 09:51:25.510178+该字符串是当前时间。
查看完整备份列表
/usr/local/bin/backup-list.sh回收率测试
通过滚动所有可用的 WAL 进行完全恢复。
停止 Postgresql。
删除 /var/lib/pgsql/9.6/data 文件夹中的所有内容。
以 postgres 用户身份运行 /usr/local/bin/backup-fetch.sh 脚本。
su - postgres
/usr/local/bin/backup-fetch.sh备份提取完成。
将 recovery.conf 添加到 /var/lib/pgsql/9.6/data 文件夹，其中包含以下内容。
restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'我们启动 PostgreSQL。 PostgreSQL 将从存档的 WAL 开始恢复过程，然后数据库才会打开。
systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log恢复一定时间。
如果我们想要将数据库恢复到某一分钟，那么我们将recovery_target_time参数添加到recovery.conf - 我们指示在什么时间恢复数据库。
restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'
recovery_target_time = '2020-01-29 09:46:25'恢复后查看表indexing_table
2020-01-29 09:41:25.226198+00
2020-01-29 09:42:25.336989+00
2020-01-29 09:43:25.356069+00
2020-01-29 09:44:25.37381+00
2020-01-29 09:45:25.392944+00我们启动 PostgreSQL。 PostgreSQL 将从存档的 WAL 开始恢复过程，然后数据库才会打开。
systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log测试
按照此处所述生成 1GB 数据库
生成1GB数据后请求bucket大小。
postgres=# SELECT pg_size_pretty(pg_database_size('test1'));
pg_size_pretty
----------------
1003 MBs4cmd 是一个免费的命令行工具，用于处理驻留在 Amazon S3 存储中的数据。 该实用程序是用 python 编程语言编写的，因此它可以在 Windows 和 Linux 操作系统中使用。
安装 s4cmd
pip install s4cmdLZ4
s4cmd --endpoint-url=http://ip-адрес-сервера-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822 s3://pg-backups/wal_005/
840 МБ в формате lz4 только WAL логов
Полный бекап с lz4 - 1GB данных
time backup_push.sh
real 0m18.582s
Размер S3 бакета после полного бекапа
581480085 s3://pg-backups/basebackups_005/
842374424 s3://pg-backups/wal_005
581 МБ занимает полный бекапLZMA
После генерации 1ГБ данных
338413694 s3://pg-backups/wal_005/
338 мб логов в формате lzma
Время генерации полного бекапа
time backup_push.sh
real 5m25.054s
Размер бакета в S3
270310495 s3://pg-backups/basebackups_005/
433485092 s3://pg-backups/wal_005/
270 мб занимает полный бекап в формате lzmaBrotli
После генерации 1ГБ данных
459229886 s3://pg-backups/wal_005/
459 мб логов в формате brotli
Время генерации полного бекапа
real 0m23.408s
Размер бакета в S3
312960942 s3://pg-backups/basebackups_005/
459309262 s3://pg-backups/wal_005/
312 мб занимает полный бекап в формате brotli
图表上结果的比较。
如您所见，Brotli 的大小与 LZMA 相当，但备份是在 LZ4 时间内执行的。
俄语 PostgreSQL 社区的聊天：
如果您使用请给Github一个star
来源： habr.com