Комментарии 15
Коротко и ясно. Спасибо, Ян. Это в стандартном репозитории или в epel?
UPD. Не внимательно читал. Там все есть!)
UPD. Не внимательно читал. Там все есть!)
.
В чем преимущество перед gem backup?
Каждый вправе выбирать себе инструмент по вкусу. На мой взгляд, преимущество в нескольких моментах:
Но если вы используете Ruby на своих серверах — то gem backup — отличное решение, не уступающее в скорости развертывания Holland.
- Для работы Holland требуется Python, который уже установлен «из коробки» во многих системах.
- Установка пакета требует минимум зависимостей, требующих загрузки. Список зависимостей gem backup заставляет вздрогнуть.
- Не очень хочется использовать Ruby после некоторых статей
Но если вы используете Ruby на своих серверах — то gem backup — отличное решение, не уступающее в скорости развертывания Holland.
про зависимости — вы не учли, что backup умеет делать очень много
1. Разные стораджи (включая s3, scp и др)
2. Разные синхронизаторы (rsync, s3)
Отсюда и много зависимостей. Если в Holland навернуть такой же функционал — будет примерно столько же.
1. Разные стораджи (включая s3, scp и др)
2. Разные синхронизаторы (rsync, s3)
Отсюда и много зависимостей. Если в Holland навернуть такой же функционал — будет примерно столько же.
Согласен. Поэтому я акцентировал внимание на модульности этого решения.
Сколько бы возможностей не было бы представлено — они не будут устанавливаться вместе, и сразу.
Сколько бы возможностей не было бы представлено — они не будут устанавливаться вместе, и сразу.
И, да, Holland — не панацея. Это еще одна программа со свои преимуществами и недостатками.
Я люблю что бы программа делала лишь то что от нее требуется. За это я и люблю Linux. Мне не нужно ставить комбайн в 25Гигов (винда) для того что бы запустить ftp сервер. Именно по этому я люблю когда каждая программа занимается своим делом. Связкой таких программ легче управлять. Кажется это называется декомпозицией?
Мне одному кажется это один из худших костылей?
Если уж взяли систему бекапа то она должна хотя бы оповещать о не успешном бекапе.
Из самого тупого я могу заменить эту систему на две строчки в скрипте, mysqldump и find delete и также добавить их в крон.
Из самого нужного нет возможность настроить приоритет бекапа, то есть если база большая то оно положит сервер.
Как минимум бекапиться все должно на другой сервер, а не сюда же.
Если уж взяли систему бекапа то она должна хотя бы оповещать о не успешном бекапе.
Из самого тупого я могу заменить эту систему на две строчки в скрипте, mysqldump и find delete и также добавить их в крон.
Из самого нужного нет возможность настроить приоритет бекапа, то есть если база большая то оно положит сервер.
Как минимум бекапиться все должно на другой сервер, а не сюда же.
Возможно, не одному.
Только это не система. Это инструмент, который снижает порог входа в область резервного копирования неопытным системным администраторам.
Я не сомневаюсь, есть люди которым легче написать две строчки в скрипте и добавить их в крон. Но когда это сделали за вас, почему бы этим не воспользоваться? Однажды выпущенная программа снижает вероятность ошибки, которую может допустить человек, пишущий скрипт.
Не все обладают квалификацией и знаниями, что бы сходу написать нужные строки с нужными флагами в нужном порядке. Не все готовы разбираться в синтаксисе и структуре конфигураций систем резервного копирования типа Bacula или Amanda.
Приоритезация и хранение копий в другом месте — дельные мысли. Только не у всех есть «другой сервер». И у большинства небольшие базы. Администратор большой БД понимает, что делает, и воспользуется другим инструментом.
В случае неудачи во время бекапа Holland любезно вернет вам ненулевой код возврата и лог. Письмо отправит Postfix, а удаленное хранилище обеспечит, например, NFS.
Поверьте, принцип KISS сэкономит немало времени в будущем.
Только это не система. Это инструмент, который снижает порог входа в область резервного копирования неопытным системным администраторам.
Я не сомневаюсь, есть люди которым легче написать две строчки в скрипте и добавить их в крон. Но когда это сделали за вас, почему бы этим не воспользоваться? Однажды выпущенная программа снижает вероятность ошибки, которую может допустить человек, пишущий скрипт.
Не все обладают квалификацией и знаниями, что бы сходу написать нужные строки с нужными флагами в нужном порядке. Не все готовы разбираться в синтаксисе и структуре конфигураций систем резервного копирования типа Bacula или Amanda.
Приоритезация и хранение копий в другом месте — дельные мысли. Только не у всех есть «другой сервер». И у большинства небольшие базы. Администратор большой БД понимает, что делает, и воспользуется другим инструментом.
В случае неудачи во время бекапа Holland любезно вернет вам ненулевой код возврата и лог. Письмо отправит Postfix, а удаленное хранилище обеспечит, например, NFS.
Поверьте, принцип KISS сэкономит немало времени в будущем.
Посмотрите ещё пакет backupninja. Тоже очень простой. Мастер ninjahelper позволяет практически не имея никаких знаний и за пару минут создать задания. Это самое простое из того, что я видел. По крайней мере при начале работы с этим инструментом не возникло никаких затруднений ВООБЩЕ.
Бэкапит, если я правильно понимаю, только в «холодном» режиме?
Самая больная тема в бэкапировании того же PostgreSQL, как проверить целостоность БД перед бэкапом, что мы не делаем бэкап кривой БД.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Holland — бекапы MySQL/PostgreSQL без головной боли