Comments 18
Кстати, шифровать можно и с помощью openssl.
Главная проблема pg_basebackup — отсутствие бинарной совместимости между версиями, а иногда приходится восстанавливать бекапы лайвовых баз на девелоперских машинах, где версия постгреса может отличаться… Не могли бы посоветовать статьи по оптимизации создания бекапа по средствам pg_dump? Надеюсь, что увеличение гранулярности базы — не единственный способ уменьшить время бекапа
Почему не рассмотрены способы бэкапирования бинарных логов? Никакая нагрузка на базу и сеть, восстановление на любой момент времени, малый размер.
А разве работа на момент снятия копии не должна быть полностью приостановлена?
Нет, останавливать ничего не нужно.
И где тогда гарантия, что вы не заберете базу между двумя зависимыми транзакциями?
Во время бэкапа (с pg_basebackup) открывается доп. соединение (при использовании -X stream) которое тянет WAL в бэкап, либо WAL сегменты могут быть подтянуты в конце резервного копирования (при -X fetch). Так что все выполненные транзакции также попадут в бэкап.
При запуске постгреса с этого бэкапа, WAL журналы будут проиграны при старте и база достигнет состояния на момент времени когда закончилось выполнение pg_basebackup.
При запуске постгреса с этого бэкапа, WAL журналы будут проиграны при старте и база достигнет состояния на момент времени когда закончилось выполнение pg_basebackup.
Нет, останавливать ничего не нужно.
>> Почему не рассмотрены способы бэкапирования бинарных логов?
Не совсем понимаю что именно там можно рассматривать. Хм, вобще не думал что с этим могут быть какие-то вопросы/проблемы, там на мой взгляд все довольно просто.
И там кстати, можно использовать те же подходы что описаны выше.
>> восстановление на любой момент времени,
Восстановление надо рассматривать отдельным топиком))) т.к. там много нюансов можно рассмотреть
Не совсем понимаю что именно там можно рассматривать. Хм, вобще не думал что с этим могут быть какие-то вопросы/проблемы, там на мой взгляд все довольно просто.
И там кстати, можно использовать те же подходы что описаны выше.
>> восстановление на любой момент времени,
Восстановление надо рассматривать отдельным топиком))) т.к. там много нюансов можно рассмотреть
А как же такой способ?
1) SELECT pg_start_backup('label');
2) делаем снапшот файловой системы
3) SELECT pg_stop_backup();
4) спокойно копируем снапшот куда подальше.
1) SELECT pg_start_backup('label');
2) делаем снапшот файловой системы
3) SELECT pg_stop_backup();
4) спокойно копируем снапшот куда подальше.
Всё это круто конечно, но вот как проверять целостность БД? — По мне так не один из этих инструментов нормально не может. Например pg_dump, если делает бэкап и допустим где-то БД не целостная, ну например где-то ключ посеяли, он доходит до этого места и просто создает не целостный архив, а точнее кривой. К сожалению инструменты проверки целостности БД в PostgreSQL увы отсутствуют и надо их писать самому…
Я раньше пользовался pg_basebackup и pg_dump для создания резервных копий, но этот способ не очень удобен когда мне нужно делать резервную копию каждые 4 часа и отправлять бэкапы на Google Drive. Я нашел эту программу, которая может это делать, может кому-то пригодиться — http://postgresql-backup.com/
Sign up to leave a comment.
10 способов сделать резервную копию в PostgreSQL