Comments 17
Добрый день
А сравнивали вашу утилиту с утилитой от postgrespro?
Добрый день.
Немного изучал, давно еще. Сейчас освежил воспоминания, и действительно, функционал во многом похож.
Но все же, мне кажется, она больше подходит для куда более профессионального управления резервным копированием. Много возможностей порождает много сложностей, а PSQLBuddy был создан с задумкой на простоту и применение в небольших компаниях.
Также я не нашел навскидку возможности резервного копирования в S3 хранилище. Изучу детальнее, спасибо за наводку.
Ну и ноу-хау, конечно, это простенький бот для восстановления бэкапа :)
Звучит как что-то глупое, но лично меня всяческие "нам очень хочется посмотреть именно сейчас архив" и прочие авралы ловят аккурат где-нибудь на пляже, в горах, в тундре. Закон подлости, который я задумал немножко отвести :)
Сколько выполняется резервное копирование БД размером хотя бы 300Гб, и самое главное - сколько выполняется восстановление БД такого размера?
Автор же написал "PSQLBuddy был создан с задумкой на простоту и применение в небольших компаниях." А 300Гб бекапьте локально и будет вам счастье. ☺
Тут все зависит не от утилитки, а от самих механизмов pg_dump & pg_restore, которые находятся под катом. А они, насколько мне известно, с большими объемами работают не очень хорошо. И хотя 300 гб не такой большой объем - все же здесь же на хабре, если мне не изменяет память, мелькала инфа, что у ребят на таких объемах были недостачи данных.
Скорость дампа упрется в производительность сервера, а выгрузка на s3 идет с максимальной скоростью, тут ограничений нет.
А эту утиль смотрели?
https://github.com/dimitri/pgcopydb
Сейчас посмотрел.
У них явно описана идея как "копия БД с одного сервера на другой настолько быстро, насколько возможно" и "pg_dump & pg_restore" на стероидах.
Моя же идея немного другая.
Так и есть да. Могут дампить как и все. А сохранить можно через fuse куда угодно.
Однако ваше решение достойно плюсика в карму 😉 и отсюда вопросы:
А есть ли мониторинг консистентности? То, что бекап восстанавливаем и его данные совпадают с оригиналом?
Какое предполагается решение для мониторинга, что бекап вообще случился? Допустим мы крон настроили неправильно. Следовательно, ошибки не пишутся, ибо бекапер не запускается.
Однако ваше решение достойно плюсика в карму 😉
Спасибо, приятно :)
А есть ли мониторинг консистентности? То, что бекап восстанавливаем и его данные совпадают с оригиналом?
Ничего подобного, к сожалению. Но спасибо за мысль, подумаю, как это можно сделать.
Какое предполагается решение для мониторинга, что бекап вообще случился? Допустим мы крон настроили неправильно. Следовательно, ошибки не пишутся, ибо бекапер не запускается.
Кстати, как вариант - можно сделать отбивку в боте о результатах бэкапов. Понимаю, это немножко не тот стандарт мониторинга, к которому все привыкли, но.. почему нет?)
Правильным, конечно, будет интегрирование в агенты какого-нибудь заббикса и аналогов.
Планирую вернуться к этому проекту через недельки две, как раз будет собран фидбэк и можно будет прикинуть, что еще хорошего за недолго можно сделать.
Если честно, у меня сама утилита заняла пару-тройку дней, а вот написать статью и привести ее в общеупотребимый вид - полторы недели)
Ещё одно ограничение pg_dump - нет возможно PITR (восстановление на заданный пользователем момент времени). Может вы планируете в этом направлении дорабатывать утилиту? (Пока алгоритма, кроме "развернуть бэкап-докидать wal- перекинуть восстановленную бд на целевой сервер" Я подсказать не могу.
Всё уже придумано - WAL-G
Спасибо, почитал - https://github.com/wal-g/wal-g/blob/master/docs/PostgreSQL.md я так понял, что это восстанавливает весь кластер, а не отдельную БД. Вот чего не понял - про какое облако речь? Хотелось бы внутри своей локальной сети складывать бэкапы.
Прекрасно работает он-прем. Да, только кластер целиком. Вообще хорошая практика - одно приложение - один кластер, избавит от многих проблем с бэкапами/восстановлением/управляемостью. В рамках одного сервера (ну или кластера патрони, если используете) можно делать несколько кластеров постгреса, аналогично именованным экземплярам MSSQL.
PSQLBuddy — резервное копирование и восстановление PostgreSQL