Резервное копирование 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.
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.
Related Services
Why Anubiz Host
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.