ru

Резервное копирование PostgreSQL в офшор

Резервное копирование PostgreSQL - не опция, а обязанность. Поломки дисков, ошибки разработчиков (случайный DROP TABLE), вымогательские атаки, сбои питания - всё это может уничтожить базу. Правильная стратегия backup включает несколько уровней: ежедневные full bакапы, continuous WAL archiving, off-site хранение, regular restore tests. Шифрование GPG, офшорное S3.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

pg_dump vs pg_basebackup vs continuous archiving

PostgreSQL поддерживает три типа резервного копирования. pg_dump - logical backup, SQL команды воссоздающие схему и данные. Преимущества: portable между версиями Postgres, можно сделать частичный (отдельная база или таблицы), сжимаемый. Недостатки: медленный (минуты на каждый GB), нагружает production во время бэкапа, не позволяет PITR. pg_basebackup - physical backup, копия data directory целиком. Быстрый (зависит от диска), не нагружает CPU. Можно использовать только для восстановления на ту же major версию Postgres. Continuous WAL archiving - сохранение Write-Ahead Log сегментов после каждого commit. В сочетании с pg_basebackup даёт Point-in-Time Recovery - можно восстановиться на любую секунду в прошлом. Рекомендуемая стратегия: еженедельный pg_basebackup + continuous WAL archiving + ежедневный pg_dump одной важной базы для logical recovery в emergency.

Point-in-Time Recovery (PITR)

PITR - возможность восстановить базу на точный момент времени в прошлом. Например, разработчик удалил критическую таблицу в 14:23 пятницы - восстанавливаемся на 14:22 без потери остальных изменений. Как работает: Base backup через pg_basebackup делается раз в неделю или ежедневно. WAL files создаются Postgres каждый раз когда заполняется 16 MB transaction log. archive_command копирует каждый WAL в безопасное место (S3 bucket, NFS, отдельный сервер). Restore: распаковываем base backup, конфигурируем recovery.signal и postgresql.conf с restore_command (откуда брать WAL) и recovery_target_time (до какого момента восстановить). Postgres стартует, накатывает WAL до указанного времени, останавливается. Точность: на любую секунду в пределах retention WAL архива. Типичный retention 30 дней. Альтернативный таргет: recovery_target_xid (до конкретной транзакции), recovery_target_name (до restore point созданного pg_create_restore_point).

Шифрование и офшорное хранение

Бэкап содержит ту же чувствительную информацию что и production база. Хранение в plain text на чужих серверах - риск утечки. Шифрование на стороне клиента: pg_dump | gpg --encrypt --recipient backup-key > backup.sql.gpg. Только владелец private key может расшифровать. Storage провайдер видит только бинарный мусор. Restic - современный backup tool с встроенным AES-256 шифрованием, дедупликацией, и поддержкой S3/Backblaze/Storj. Шифрует chunks до отправки. BorgBackup - похожий tool с лучшей дедупликацией для частых небольших изменений. Офшорное хранилище: Storadera Estonia (юрисдикция ЕС вне Five Eyes), Wasabi EU (Frankfurt), Storj (decentralized), Backblaze B2 (US но дёшево для encrypted blobs). 3-2-1 правило: 3 копии бэкапа, на 2 разных носителях, 1 off-site. Применительно к Postgres: 1 копия на том же VPS, 1 копия на отдельном backup VPS, 1 копия в S3. Restore tests: раз в месяц обязательно делать full restore на тестовый сервер и проверять что данные читаются. Untested backup это no backup.

Why Anubiz Host

100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Anubiz Chat AI

Online