Linux + Резервное копирование

Дошли наконец-то руки сделать персональный сервер бэкапов, который будет стоять не у меня дома. С этой мыслью я уже несколько лет хожу, делал несколько подходов, но вот наконец-то звёзды сошлись — у меня и железка под него образовалась, и дисков в достаточном количестве, и ОС наконец-то более-менее подобрал.

В качестве железа выбрал старенький HP Microserver Gen7. Продавать большого смысла не видел, куда-то в продакшн ставить тоже — он почти на любой чих под 100% загружается, если какие-то сервисы вешать или просто в несколько потоков файлы по гигабитной сети копировать. А вот с простым хранением файлов он ещё справится.

Это не пошаговая инструкция, это небольшой отчёт на тему «как можно сделать», может кто для себя идеи почерпнёт.

Если же закрыть глаза на процессор, то в остальном из микросервера получается вполне достойный NAS — четыре-пять слотов под 3.5″ диски, плюс можно внутри корпуса кинуть SSD, благо имеется пять SATA-портов и внешний e-SATA, который я завёл внутрь.

Первый раз я более-менее серьёзно пытался подойти к задаче в начале года, поставил было на него TrueNAS Scale. Но по дискам у меня тогда была сборная солянка от 3 до 6 терабайт, да ещё самые большие диски были SMR. А TrueNAS — это zfs. А zfs — это враг черепичных дисков (ну или черепичные диски — враг SMR). Плюс, даже если считать, что диски все CMR, собирать массивы на zfs из разных дисков нерационально. Либо большие потери, либо придётся кроить и попадать на потерю ёмкости или головную боль при возможной замене дисков.

Потому TrueNAS снёс, сервер отложил. В начале лета снова вернулся, решив поставить на него Open Media Vault 7.

Объединил диски при помощи mergerfs, а избыточность захотел получить при помощи snapraid. Некоторое время поигрался со всем этим и понял, что сегодняшний OMV мне нравится ещё меньше, чем TrueNAS. От системы плагинов уже почти ушли, а к нормальной поддержке докера всё ещё не пришли. Да и веб-интерфейс его мне никогда особо не нравился. Хотя чего у OMV не отнять — это того, что он на любой табуретке запускается, к ресурсам совершенно не требователен. Но, в остальном, у меня создаётся ощущение, что разработчики сами пока не знают, что хотят получить в итоге. Потому для меня OMV — это дистрибутив для простейшей файлопомойки на слабом железе для тех случаев, когда хочется иметь хоть какой-то веб-интерфейс и не хочется использовать zfs. Если же железо позволяет — лучше смотреть на другие варианты.

Но тут у меня наконец-то образовалась пачка одинаковых по объёму дисков, да ещё и не черепичных. Потому решил дать TrueNAS второй шанс. Тем более, что в свежей бете (Electric Eel) они наконец-то прикрутили более-менее нормальную поддержку докера, переходя на него c kubrnetes.
Что совпало со смертью каталога приложений TrueCharts, который до этого был основным источником контейнеров для TrueNAS Scale.

Для меня, как человека, который и с докером-то пару-тройку лет назад только общаться начал, а про kubernetes слышал только что «это какие-то контейнеры для энтерпрайза», такое стечение обстоятельство только на пользу.

Железо у меня в итоге получилось такое:

HP Microserver Gen7, с процессором AMD Turion(tm) II Neo N40L — 1,5GHz, 2 ядра (по производительности это примерно Rasperry Pi4).
16 GB оперативной памяти (обычной, не ECC)
4 диска по 6TB, один диск на 4TB и SSD на 500GB.
Дополнительно поставил USB-контроллер и вторую сетевую карту (пока гигабит, потом на 2.5 заменю).

ОС — TrueNAS SCALE 24.10

Про установку писать не буду, там всё несложно — загрузился с CD, поставил ОС, зашел через веб-интерфейс — пользуешься. Разве что по мелочи:

1. Загрузочным диском я выбрал USB-флэшку Sandisk Extreme на 32 гигабайта. Вообще, это не особо приветствуется, как я понял. Но Sandisk Extreme — очень выносливые флэшки, в отличие от всяких там Ultra. А флэшку на 32 гигабайта мне использовать особо некуда было, объём маловат. Так что пригодилась. Благо у сервера есть внутренний USB-разъём и снаружи ничего не торчит.

2. Когда установщик спрашивал про EFI, я решил было, что у меня система старая и пусть лучше Legacy-загрузчик сделает. Как выяснилось, это было ошибкой — установка прерывалась с сообщением «не могу найти sda3». Некоторое время повозился с конфигами (ошибка не особо редкая, рекомендовали вставить в скрипт установки sleep 20), но в итоге всё решилось просто ответом «Да» на вопрос про EFI.

3. Изначально я ставил стабильную версию, 24.04. После установки как раз и узнал про то, что каталог приложений TrueCharts помер, а сам TrueNAS Scale движется в сторону докера. Потому просто обновил систему через встроенный апдейтер до 24.10, даже переустанавливать не пришлось.

Диски

Четыре шеститерабайтника я собрал в массив raidz2, решил, что это будет надёжней, чем подобие raid10, пусть и менее производительно. Правда, после первой же перезагрузки я получил разваленный массив.

Не знаю, что тут конкретно виновато — я не туда нажимал или бета‑версия нахимичила. По ощущениям, Truenas собрал массив из четырёх дисков «виртуально» — после сборки массива он писал «доступно пять дисков вне пула». При этом один диск он в массив таки включил и что‑то на него писал и читал. Но только до перезагрузки. После перезагрузки же в массиве остался только один диск, справка писала «изя всё» и предлагала только восстановление из бэкапа. Потому, когда собрал новый массив, несколько раз перезагрузился для проверки. Новый массив больше не разваливался.

SSD используется для установки приложений.

А оставшийся диск на 4ТБ — под что-то типа архива и бэкапов бэкапов. Да, он будет работать без резервирования, но даже если помрёт, то на нём будут только копии копий находиться и вообще не особо важные данные вида «не хочется потерять, но не настолько важные, чтобы пихать их на основной массив».

Задачи сервера

Основная задача — оффсайтовый бэкап для домашнего сервера. Не всего подряд, само собой — дома у меня занято 30 терабайт, но того, что действительно жалко потерять, там порядка 3–4 терабайт. Пока эти бэкапы делаются в вандрайв (с шифрованием), но там подписка через год заканчивается и особого желания её продлять у меня нет — терабайтных облачных хранилищ у меня и так достаточно, офис 2010 или 2013, на которые у меня есть лицензии, для моих нужд ничем не хуже, чем офис365.

Вторичная — резервный сервер для некоторых сервисов, которые крутятся на домашнем сервере. К примеру, бывает полезно иметь второй инстанс сервиса, если к основному нет доступа. Пусть даже и БД этого инстанса не очень актуальна. Примеры — RSS-читалка (freshrss), vaultwarden (менеджер паролей), мониторинг аптайма (uptime kuma) и прочие мелочи, которые не требуют много процессорной мощности.

Установка приложений

Поскольку версия truenas пока ещё в бете, библиотека приложений тут достаточно ограничена, хотя и пополняется потихоньку — несколько дней назад было 96 приложений в каталоге, сейчас уже 102. А свои приложения так сразу непонятно, как добавлять. Раньше была кнопка «добавить контейнер», сегодня же её не видно. Конечно, можно зайти в консоль и оттуда вводить команды докера, но не затем я уходил с OMV, чтобы с консолью возиться.

В репозитории имеются portainer и dockge. Portainer лично мне кажется слишком уж замороченным для простой задачи «поставить контейнер». Он слишком много умеет и глаза от этого разбегаются. Потому я его максимум ставил для того, чтобы мониторить работу контейнеров. А конфиги писал и ставил всё из консоли.

А вот dockge прост и лаконичен, если речь идёт просто об запуске контейнера. Вставляешь в поле текст yml-файла, запускаешь. Либо скармливаешь ему команду вида docker run — он её преобразует в конфиг, читаешь — редактируешь по потребности — запускаешь.

Та же командная строка, просто в браузере. На страничке можно контейнер остановить, запустить, обновить, в шелл контейнера зайти, логи почитать…

При этом dockge видит «чужие» контейнеры (которые truenas ставил), но рулит только своими. Это мне кажется удобным компромиссом — что можно ставишь из админки truenas, что нельзя — через dockge. Когда это что-то добавится в truenas — ну или когда там вернут полноценную работу с контейнерами — можно будет аккуратно мигрировать.

Доступ к серверу «из мира»

Я не стал выставлять сервер в мир, он смотрит только в провайдерскую сеть и имеет приватный IP, что в данном случае меня вполне устраивает — дома есть подключение к тому же провайдеру, потому можно не задумываться о пробросах портов и т.п.

С другой стороны — к некоторым сервисам хочется иметь доступ извне, если уж делать тут резервный инстанс. Можно было бы сделать проброс портов с моего vps, допустим, но в данном случае мне проще было воспользоваться туннелями Cloudflare (cloudflared). Да, это опять привязка к третьей стороне, от которой я как бы ухожу, но, в данном случае, она не критичная. Если вдруг cloudflare отвалится, никто не мешает вернуться к вариантам с VPN, пробросом портов или просто купить реальный IP.

Технически это всё выглядит следующим способом:

В админке Cloudflare в разделе Zero Tier создаёте туннель, он вам говорит ID туннеля.

На своём сервере (или вообще на любом компьютере) ставите демон cloudflared и в настройках ему указываете ID туннеля. И дальше со стороны Cloudflare указываете поддомен, через который хотите обращаться к сервису и локальный IP:порт этого сервиса.
Единственное ограничение — доменом должен рулить cloudflare. Не обязательно его там покупать (хотя я купил специально под это дело отдельный домен), но DNS должен быть прописан тамошний.

Тут два туннеля — на админку и на контейнер с librespeed.

Скорость, по ощущениям, режется втрое, но тут мне сложно сказать, кто виноват — туннель такой медленный или микросервер не тянет. Впрочем, на меня одного для доступам к мелким сервисами типа пинговалки или vaultwarden’a такого туннеля вполне хватит.

Если измерять скорость через вышеупомянутый librespeed, то при прямом подключении внутри провайдерской сети — практически заявленные 100 мегабит.

А вот через туннель 40 мегабит — это максимум, который удалось получить. Чаще же в районе 25-30 болтается. Впрочем, это для меня вполне терпимо, если не качать большие объёмы данных. А их я пока что качаю через локальную сеть провайдера.

Если cloudflare сломают или захочется большей скорости — тогда уже и буду решать вопрос, благо способов много, этот просто был самый простой.

Бэкап как таковой

Можно пользоваться чем нравится, я пока что остановился на двух методах.

Самое большое и важное, что мне надо сохранять — это фотографии за много лет, которых уже порядка двух с половиной терабайт. Раньше они у меня через syncthing копировались на домашний сервер, а оттуда при помощи duplicati заливались в onedrive. Так что просто добавить ещё один инстанс syncthing’a смотрелось вполне логично. Ну и дальнейшую работу, наверное, большей частью буду в рамках syncthing’a организовывать. Хотя можно и любые другие протоколы использовать при необходимости.

Syncthing есть в каталоге приложений, ставится без вопросов. Само собой, надо в контейнер папку подмонтировать, куда бэкапы складывать. Сперва я посмотрел, как оно работает через глобальное обнаружение и посредников — вышло не очень. Максимум видел порядка 50 мегабит скорость, а так вообще колебалась в районе 10-20 мегабит. Два-три терабайта так качать совсем не хотелось.

Потому настроил прямое соединение с домашним компьютером, выставив наружу порт syncthing’a на домашнем роутере. Так добился полной скорости — 100 мегабит, больше провайдер не предоставляет. Загрузка процессора при синхронизации колеблется в районе 50–70%, но особых лагов в админке не ощущается.

Второй способ — копирование данных с линуксовых серверов через rsync. Тут всё просто, был бы доступ к серверу по ssh. В настройках TrueNAS есть rsync tasks, просто добавляешь туда что, откуда и куда копировать, настраиваешь расписание — и вперёд.

Версионность — через снапшоты zfs. На каждую папку с бэкапами я создаю отдельный датасет, потому могу снапшоты настраивать достаточно гибко, где каждый час, а где — каждую неделю.

Планы на будущее

Из аппаратного:
Постараюсь заменить память на ECC. Раньше я к этом относился "хорошо, но не обязательно, а вот после приколов с домашним сервером стал относиться более серьёзно. Но новую память по 7000 за модуль брать жаба не даёт, а али завалено регистровой памятью, которую микросервер не понимает. Так что придётся искать ECC UDIMM на барахолках, что дело не быстрое.

Заменю гигабитную сетевушку на 2.5 гигабита. Это для «внутренней» связи — на работе кроме микросервера у меня стоит небольшой вебсервер, который я перепрофилирую в ноду proxmox — с него тоже надо будет делать бэкапы, так что пусть они делаются на большей скорости. Ну и свой рабочий компьютер тоже добавлю сетевушку на 2.5 и воткну в тот же свитч.

Может быть, сниму контроллер usb-3 и поставлю вместо него переходник на nvme-диск — под кэш для массива.

По самому микросерверу — я не могу его рекомендовать, если вы собираете сервер совсем с нуля. В gen7 из полезного — только корпус на 4-5 дисков. Но нормально он себя ведёт только в связке с родной материнкой, если же её захочется обновить — то усилий по допиливанию корпуса под mini-ITX будет затрачено довольно много. По мне так проще потратиться на какой-нибудь китайский корпус и там уже собрать систему на нормальном железе. Или взять готовый NAS на x86 и поставить на него интересную вас ОС. Я микросервером воспользовался только по той причине, что он у меня имелся и по производительности более-менее устраивал. Иначе бы взял Jonsbo N2, очень симпатичный корпус, хоть и не очень бюджетный. Или N1.

Из программного:

Дождусь релиза TrueNAS 24.10. Прикручу бэкапы со своих облаков, которыми пока пользуюсь (вандрайв, мэйл, яндекс). Настрою бэкап почты с тех же gmail’ов и яндексов. Ну и настрою обратный бэкап на домашний сервер. Бэкапов много не бывает.

В остальном я не вижу каких-то серьёзных путей для развития. Основное всё сделано, а дальше уже только использование по назначению остаётся. Все эксперименты и тяжелые задачи пойдут на второй сервер (который с proxmox’ом). Но это отдельная история, отдельной статьи не заслуживающая. Материалов на тему «как я поставил proxmox» в сети навалом в любых видах.

WAL-G — прекрасный, быстрый, простой и эффективный инструмент для резервного копирования БД (PostgreSQL/MySQL/MariaDB/MongoDB/FoundationDB и т.п.) в почти любые облака (Amazon S3/MinIO, Yandex Object Storage, Google Cloud Storage, Azure Storage, Swift Object Storage и просто на файловую систему).

Исходники на github, собранные rpm под CentOS.

Расскажу на примере PostgreSQL и MongoDB, как пользоваться этой штукой. Версии актуальны на август 2022 года.

Все бэкапы складываю в MinIO — легкое хранилище объектов, совместимое с Amazon S3.

В местном редакторе не предусмотрен тег для кода, поэтому буду оформлять его в цитаты.

PostgreSQL

Для теста на одном из хостов поднимем PostgreSQL12:

yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL- 7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install postgresql12-server
/usr/pgsql-12/bin/postgresql-12-setup initdb
systemctl enable postgresql-12 && systemctl start postgresql-12

создаю тестовую базу:

su — postgres
psql
create database test1;
\c test1;
CREATE TABLE indexing_table(created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());

Генерирую и вливаю в тестовую базу данные размером около 1 Гб:

CREATE TABLE large_for_test (num1 bigint, num2 double precision, num3 double precision);
INSERT INTO large_for_test (num1, num2, num3)
SELECT round(random()*10), random(), random()*142
FROM generate_series(1, 20000000) s(i);
EXPLAIN (analyse, buffers)
SELECT num1, avg(num3) as num3_avg, sum(num2) as num2_sum
FROM large_for_test
GROUP BY num1;

Чтобы архиватор внутри базы сам заливал WAL-журналы в облако и восстанавливался из них (в случае необходимости) настраиваю некоторые параметры в postgresql.conf:

wal_level=replica
archive_mode=on
archive_command=’/usr/local/bin/wal-g wal-push \”%p\” >> /var/log/postgresql/archive_command.log 2>&1'
archive_timeout=60
restore_command=’/usr/local/bin/wal-g wal-fetch \”%f\” \”%p\” >> /var/log/postgresql/restore_command.log 2>&1'

Подробнее обо всех этих параметрах можно прочитать в переводе официальной документации.

И рестартую PostgreSQL:

systemctl restart postgresql-12

На тот же хост, где и PostgreSQL, ставлю WAL-G версии 0.2.15 (по сути — это просто один бинарник, без внешних зависимостей):

curl -L https://github.com/wal-g/wal-g/releases/download/v0.2.15/wal... -o wal-g.linux-amd64.tar.gz
tar -xzf wal-g.linux-amd64.tar.gz
mv wal-g /usr/local/bin/

Для конфигурирования WAL-G нужно положить файл .walg.json (пример файла здесь) в домашнюю директорию пользователя postgres:

cat > /var/lib/pgsql/.walg.json << EOF
{
"AWS_ENDPOINT": "http://minio:9000",
"WALG_S3_PREFIX": "s3://pgbackup",
"AWS_ACCESS_KEY_ID": "admin",
"AWS_SECRET_ACCESS_KEY": "password",
"AWS_S3_FORCE_PATH_STYLE": "true",
"WALG_COMPRESSION_METHOD": "brotli",
"WALG_DELTA_MAX_STEPS": "5",
"PGDATA": "/var/lib/pgsql/12/main",
"PGHOST": "/var/run/postgresql/.s.PGSQL.5432"
}
EOF

Не забываем поменять владельца этого файла:

chown postgres: /var/lib/pgsql/.walg.json

Проверяю создание полного бэкапа: в WAL-G это аргумент запуска backup-push. Для начала выполняю эту команду вручную от пользователя postgres, чтобы убедиться что всё хорошо (не забудьте сначала создать бакет с именем из WALG_S3_PREFIX):

time su — postgres -c ‘/usr/local/bin/wal-g backup-push /var/lib/pgsql/12/data’
INFO: 2020/08/17 06:05:00.211318 Couldn’t find previous backup. Doing full backup.
INFO: 2020/08/17 06:05:00.225448 Calling pg_start_backup()
INFO: 2020/08/17 06:05:01.819922 Walking …
INFO: 2020/08/17 06:05:01.820466 Starting part 1 …
INFO: 2020/08/17 06:05:21.049285 Finished writing part 1.
INFO: 2020/08/17 06:05:21.049323 Starting part 2 …
INFO: 2020/08/17 06:05:21.149069 Finished writing part 2.
INFO: 2020/08/17 06:05:21.659995 Starting part 3 …
INFO: 2020/08/17 06:05:21.660060 /global/pg_control
INFO: 2020/08/17 06:05:21.660309 Finished writing part 3.
INFO: 2020/08/17 06:05:21.662065 Calling pg_stop_backup()
INFO: 2020/08/17 06:05:23.878346 Starting part 4 …
INFO: 2020/08/17 06:05:23.878460 backup_label
INFO: 2020/08/17 06:05:23.878490 tablespace_map
INFO: 2020/08/17 06:05:23.878635 Finished writing part 4.
INFO: 2020/08/17 06:05:24.924564 Wrote backup with name base_00000001000000000000007E
real 0m24.829s
user 0m20.669s
sys 0m2.323s

Бэкап ~1 Гб БД выполняется очень быстро.

В MinIO в нужном бакете появляются бэкапы, 1 Гб БД ужимается до 351.92 Мб.

Если всё прошло без ошибок, то далее можно добавить периодический запуск этой команды в crontab. Необходимо учесть, что хранение всех бэкапов вечно не имеет никакого смысла, поэтому нужно настроить удаление старых резервных копий (можно в том же кроне).

Восстановление

Попробуем восстановиться по-взрослому, удалив все данные (БД и пользователей).

Останавливаю PostrgeSQL:

systemctl stop postgresql-12

Удаляю все данные из текущей базы:

rm -rf /var/lib/pgsql/12/data

Скачиваю резервную копию и разархивирую её:

su — postgres -c ‘/usr/local/bin/wal-g backup-fetch /var/lib/pgsql/12/data LATEST’

От имени пользователя postgres помещаю рядом с базой специальный файл-сигнал для восстановления (подробнее здесь) :

su — postgres -c ‘touch /var/lib/pgsql/12/data/recovery.signal’

Запускаю базу данных, чтобы она инициировала процесс восстановления:

systemctl start postgresql-12 && systemctl status postgresql-12

Смотрим логи, там красота :)

2020–08–17 08:57:55.281 EDT [25536] LOG: starting archive recovery
2020–08–17 08:57:55.876 EDT [25536] LOG: restored log file “000000010000000100000044” from archive
2020–08–17 08:57:56.617 EDT [25536] LOG: redo starts at 1/44000028
2020–08–17 08:57:56.834 EDT [25536] LOG: restored log file “000000010000000100000045” from archive
2020–08–17 08:57:58.006 EDT [25536] LOG: consistent recovery state reached at 1/45000050
2020–08–17 08:57:58.007 EDT [25533] LOG: database system is ready to accept read only connections
2020–08–17 08:57:58.223 EDT [25536] LOG: restored log file “000000010000000100000046” from archive
2020–08–17 08:57:59.811 EDT [25536] LOG: redo done at 1/46000148
2020–08–17 08:58:00.096 EDT [25536] LOG: restored log file “000000010000000100000046” from archive
2020–08–17 08:58:00.740 EDT [25536] LOG: selected new timeline ID: 2
2020–08–17 08:58:02.291 EDT [25536] LOG: archive recovery complete
2020–08–17 08:58:07.408 EDT [25533] LOG: database system is ready to accept connections

Проверяем, что все на месте, размеры совпадают. Все отлично работает.

Восстановление на определенное время

Если нужно восстановить базу на определенную минуту, то в recovery.conf добавляем параметр recovery_target_time (задается в формате YYYY-MM-DD HH:mm:ss)— указываем на какое время восстановить базу:

restore_command = ‘/usr/local/bin/wal-fetch.sh “%f” “%p”’
recovery_target_time = ‘2020–08–14 09:00:00’

Резюмируя по Postgres:

- На каждом хосте с Postgres устанавливаем WAL-G

- на каждом хосте с Postgres правим postgresql.conf

- в home пользователя postrges кладем .walg.json

ставим команду резервного копирования (и зачистки ненужных старых бэкапов) в cron

Чтобы в дальнейшем все было красиво, я у себя для каждого хоста с БД создаю отдельный бакет (например, по имени хоста).

MongoDB

Для тестов на одном из хостов поднимаю MongoDB 4.4 и использую тот же инстанс MinIO c созданным под эти цели бакетом mongo.

Заливаю в Монгу тестовые данные:

curl -LO https://raw.githubusercontent.com/mongodb/docs-assets/primer...
mongoimport — db test — collection restaurants — file /tmp/primer-dataset.json
2020–08–18T06:05:46.661–0400 connected to: mongodb://localhost/
2020–08–18T06:05:48.746–0400 25359 document(s) imported successfully. 0 document(s) failed to import.

Бэкап

В директории пользователя, от имени которого запускается бэкап, должен лежать файл .walg.json c примерно следующим содержимым (подробное описание параметров в документации):

{
“WALG_S3_PREFIX”: “s3://mongo”,
“AWS_ACCESS_KEY_ID”: “minioadmin”,
“AWS_SECRET_ACCESS_KEY”: “minioadmin”,
“AWS_ENDPOINT”: “http://minio:9000",
“AWS_S3_FORCE_PATH_STYLE”: “true”,
“WALG_STREAM_CREATE_COMMAND”: “mongodump — archive — uri=\”mongodb://127.0.0.1:27017\””,
“WALG_STREAM_RESTORE_COMMAND”: “mongorestore — archive — drop — uri=\”mongodb://127.0.0.1:27017\””,
“MONGODB_URI”: “mongodb://127.0.0.1:27017”,
“WALG_SENTINEL_USER_DATA”: “{\”key\”: \”value\”}”,
“OPLOG_ARCHIVE_TIMEOUT_INTERVAL”: “5s”,
“OPLOG_ARCHIVE_AFTER_SIZE”: “1048576”,
“WALG_COMPRESSION_METHOD”: “brotli”,
“WALG_DISK_RATE_LIMIT”: “41943040”,
“WALG_NETWORK_RATE_LIMIT”: “10485760”,
“WALG_LOG_LEVEL”: “DEVEL”,
“WALG_UPLOAD_CONCURRENCY” : 1,
“OPLOG_PITR_DISCOVERY_INTERVAL”: “168h”
}

Особо нужно обратить внимание на параметр MONGODB_URI, который используется для подключения к инстансу MongoDB — например, при необходимости подключения к определенной БД, при необходимости указать пользователя/логин/пароль для подключения и т.п. (документация).

Для бэкапа нужно выполнить команду

wal-g backup-push
2020–09–05T03:51:21.247–0400 writing admin.system.version to archive on stdout
2020–09–05T03:51:21.252–0400 done dumping admin.system.version (1 document)
2020–09–05T03:51:21.252–0400 writing test.restaurants to archive on stdout
2020–09–05T03:51:21.324–0400 done dumping test.restaurants (25359 documents)
INFO: 2020/09/05 03:51:21.504031 FILE PATH: stream_20200905T075121Z/stream.br
INFO: 2020/09/05 03:51:21.511747 Removing sigmask. Shutting down

После выполнения команды бэкап появляется в бакете.

Для периодичного бэкапа можно запускать эту команду в cron’e (и опять же, не забываем удалять старые бэкапы).

Смотрим командой wal-g backup-list список имеющихся у нас бэкапов:

wal-g backup-list
name last_modified wal_segment_backup_start
stream_20200905T075121Z 2020–09–05T07:51:21Z ZZZZZZZZZZZZZZZZZZZZZZZZ
stream_20200905T082140Z 2020–09–05T08:21:40Z ZZZZZZZZZZZZZZZZZZZZZZZZ

и командой wal-g backup-fetch backup-name восстанавливаем нужный нам бэкап:

wal-g backup-fetch stream_20200905T075121Z
2020–09–05T04:11:39.297–0400 preparing collections to restore from
2020–09–05T04:11:40.295–0400 reading metadata for test.restaurants from archive on stdin
2020–09–05T04:11:40.319–0400 restoring test.restaurants from archive on stdin
2020–09–05T04:11:40.717–0400 no indexes to restore
2020–09–05T04:11:40.717–0400 finished restoring test.restaurants (25359 documents, 0 failures)
2020–09–05T04:11:40.717–0400 25359 document(s) restored successfully. 0 document(s) failed to restore.
INFO: 2020/09/05 04:11:40.720019 Removing sigmask. Shutting down

Все прекрасно работает.

Чем WAL-G лучше того же pg_dump (или pg_basebackup или Barman и т.п.) хорошо написано здесь (очень хорошая статья для понимания, как это устроено и работает), если вкратце — то это инструмент разработчика и он не предназначен для работы с высоконагруженной БД.

Рекомендую попробовать, уверен, что понравится :) Если что - спрашивайте!