pgBackRest и barman одинаково умеют складывать WAL-архив и бэкапы в S3, но оба выросли из эпохи, когда основным хранилищем была локальная файловая система, а объектное хранилище — опциональный репозиторий поверх. WAL-G спроектирован наоборот: он написан на Go и с первого дня целится именно в object storage как основной репозиторий, без промежуточного слоя абстракций под POSIX-пути. ...
Barman и pgBackRest оба бэкапят PostgreSQL, но по-разному устроены внутри. Исторически Barman строился вокруг rsync поверх SSH: backup_method = rsync копирует файлы кластера по ssh-соединению, а archiver = on принимает WAL-сегменты через archive_command, которая переносит их на сервер бэкапов. Со стороны PostgreSQL это полностью агентless-модель — отдельный процесс не нужен, достаточно ssh-доступа. ...
pg_basebackup делает ровно одну вещь — снимает физическую копию кластера, а всё остальное (расписание, ретеншн, инкременты, сжатие в несколько потоков) приходится дописывать самому в обвязке на bash. pgBackRest с самого начала проектировался как отдельный инструмент именно под эти задачи, а не как обёртка вокруг pg_basebackup. ...
rsync копирует не файлы целиком, а дельты — при повторном запуске на тот же адресат передаёт по сети только изменившиеся блоки. Это база большинства скриптовых бэкапов, где pg_probackup/pgBackRest — оверкилл, а tar каждый день целиком — слишком дорого по месту и трафику. ...
vzdump — встроенный инструмент бэкапа VM/CT в Proxmox VE, но без явной настройки retention он ничего не удаляет: по умолчанию действует keep-all=1, бэкапы копятся вечно, пока не кончится место на диске. Retention задаётся через prune-backups: vzdump 101 --prune-backups keep-last=3,keep-daily=7,keep-weekly=4 Тот же параметр есть в Datacenter → Backup job — не нужно городить отдельный cron-скрипт для чистки старых архивов. Уведомления о падении/успехе задания раньше настраивались флагом --mailto, но он объявлен deprecated — актуальный способ - notification targets (Datacenter → Notifications), --notification-mode переключает между auto, legacy-sendmail и notification-system. ...
Point-in-time recovery в PostgreSQL строится на непрерывном архиве WAL-сегментов — без него pg_basebackup даёт снимок на момент бэкапа, и всё, что случилось после, потеряно безвозвратно. Минимум в postgresql.conf: wal_level = replica archive_mode = on archive_command = 'test ! -f /archive/%f && cp %p /archive/%f' %p — путь к сегменту, %f — имя файла. test ! -f не даёт молча перезаписать уже сохранённый сегмент. С PostgreSQL 12 recovery_target_time и restore_command идут прямо в postgresql.conf, режим восстановления включает файл recovery.signal в PGDATA — отдельного recovery.conf больше нет. restore_command — обратный путь: читает сегменты из архива в pg_wal. ...
Три утилиты, три разных уровня бэкапа — путаница возникает, когда пытаются взаимозаменить логический и физический бэкап там, где это не работает. pg_dump -Fc mydb > mydb.dump # логический дамп одной БД pg_restore -d mydb_new --clean --if-exists mydb.dump pg_basebackup -D /backup/base -Ft -z -P -U replicator # физическая копия кластера pg_dump — логический: SQL-представление данных, можно восстановить одну таблицу из дампа целой БД, версии источника и назначения могут отличаться. pg_basebackup — физический: побайтовая копия PGDATA, восстанавливается только целиком, зато на её основе строится репликация и point-in-time recovery через WAL. Для одной таблицы — pg_dump -t, для кластера с минимальным RPO — pg_basebackup плюс архив WAL. ...
Веб-интерфейс Proxmox прячет vzdump за формой с чекбоксами, но это обычная CLI-утилита — дёргается из cron без похода в GUI. Режимы snapshot/suspend/stop по-разному балансируют простой VM и консистентность данных. # snapshot — VM не останавливается, бэкап через ZFS/LVM snapshot vzdump 101 --mode snapshot --storage local --compress zstd # suspend — короткая пауза VM на момент снятия снапшота vzdump 102 --mode suspend --mailto admin@example.com # несколько VM разом, с ограничением по bandwidth vzdump 101 102 103 --bwlimit 50000 --storage nfs-backup Восстановление — разные команды по типу гостя: qmrestore backup.vma.zst 101 --storage local для VM, pct restore 101 backup.tar.zst --storage local для контейнеров. ...
borg дедуплицирует бэкапы, но требует SSH-доступа к хранилищу или локального пути. restic — та же дедупликация и шифрование, но из коробки говорит с S3, Backblaze B2, SFTP и локальным диском, без отдельного backup-сервера. # инициализация репозитория (тот же синтаксис для S3/SFTP) restic init --repo /mnt/backup/restic-repo # бэкап директории restic -r /mnt/backup/restic-repo backup /etc /var/lib/postgresql/data # снапшоты и восстановление restic -r /mnt/backup/restic-repo snapshots restic -r /mnt/backup/restic-repo restore latest --target /tmp/restore Пароль репозитория задаётся при init — без него бэкапы не восстановить, хранить его нужно отдельно. Дедупликация на уровне блоков: повторный бэкап после мелких правок в большом файле занимает не весь объём, а только изменённые куски. ...
tar + cron работает, но каждый полный бэкап занимает столько же места, сколько предыдущий, а инкременты вручную собирать неудобно. borg дедуплицирует контент на уровне блоков — повторяющиеся куски между снапшотами не хранятся дважды, при этом каждый снапшот выглядит как полный. apt install borgbackup borg init --encryption=repokey /mnt/backup/repo borg create /mnt/backup/repo::'{hostname}-{now}' /etc /var/www /home borg list /mnt/backup/repo borg extract /mnt/backup/repo::myhost-2026-07-10T09:00:00 borg prune --keep-daily=7 --keep-weekly=4 /mnt/backup/repo Ключ шифрования (repokey) хранится внутри репозитория — держи отдельную копию passphrase, без неё восстановление невозможно. ...