Комментарии 34
в почту, да еще и каждый день, бесполезно… :(
я в свое время обязательным порядком создавал зеркало минус день, важного работающего сервера, на него ночью все изменения быстро копировал rsyncом, а от туда уже архивировал, собственно таким образом «вчерашний» бекап всегда был на зеркале, и проверить его работоспособность достаточно просто…
ну можно на зеркало разворачивать бекап :)
то есть делать бекап, потом его разворачивать на зеркало, и раз в неделю заходить проверять, работает ли зеркало, если работает, тогда и бекап вроде как гарантированно работает :)
но это все так накалено, не знаю как в промышленных маштабах :)
я в свое время обязательным порядком создавал зеркало минус день, важного работающего сервера, на него ночью все изменения быстро копировал rsyncом, а от туда уже архивировал, собственно таким образом «вчерашний» бекап всегда был на зеркале, и проверить его работоспособность достаточно просто…
ну можно на зеркало разворачивать бекап :)
то есть делать бекап, потом его разворачивать на зеркало, и раз в неделю заходить проверять, работает ли зеркало, если работает, тогда и бекап вроде как гарантированно работает :)
но это все так накалено, не знаю как в промышленных маштабах :)
По-моему, заходить на зеркало каждого сервера и проверять несколько напряжнее, чем читать сводную аналитику в письме. Впрочем, да, ваш способ я тоже считаю жизнеспособным, он у меня так же указан. «Те же яйца, вид сбоку» =)
База должна иметь достаточно констрейнтов что бы быть уверенным в ее целостности при успешном накате.
В крайнем случае на автомате же запустить пачку тестов.
В крайнем случае на автомате же запустить пачку тестов.
НЛО прилетело и опубликовало эту надпись здесь
Ну как вариант (например, для mysql) — сделать служебную таблицу, в нее писать текущую дату перед началом бэкапа. Делать полный бэкап, развернуть бэкап на зеркале, проверить наличие текущей даты в служебной таблице и послать письмо. Все вроде можно сделать автоматом.
НЛО прилетело и опубликовало эту надпись здесь
Знакомая тема. Попросил админов сделать пробник nagios на актуальность бэкапов.
Пока ни слуху, не духу.
Пока ни слуху, не духу.
Для бекапов использую bacula. мониторю успешность прохождения бекапов при помощи zabbix. проверяю на ошибки и на нулевой размер бекапов. очень удобно. раз в квартал/полгода неплохо проводить «учения» по восстановлению данных из бекапов — это, как уже писали выше самый безотказный способ, так же широко использующийся.
а нам она показалась тяжеловатой. Остановились на backupPC
Да и мониторинг из коробки
Да и мониторинг из коробки
Да ну, не сказал бы что бакула тяжелая.
3 демона (по 2Mb в оперативке) и одна SQL база данных.
Есть и веб-морды и Qt-шный клиент и апплет для трея.
3 демона (по 2Mb в оперативке) и одна SQL база данных.
Есть и веб-морды и Qt-шный клиент и апплет для трея.
При сколько-либо нетривиальных конфигах в bacula bacula-dir становится неподъемным для внесения изменений…
Тут дело в изначальном планировании конфигурации бакулы. Я тоже столкнулся с этой же проблемой сначала. Тоже сначала казалось, что бакула очень проблематична в конфигурации. Но потом сделал так: основной конфиг бакулы описывает ТОЛЬКО общие параметры, а для каждого хоста делается отдельный файл, который потом инклудится в основной конфиг. Там описывается свой пул для каждого хоста, джобы и сами хосты. И поврьте — это ОЧЕНЬ удобно. Добавление или переконфигурирование того или иного хоста занимает примерно 5 минут. И при использовании инклудов все наглядно и прозрачно. Если будут вопросы могу показать на примеров своих конфигов, как сделаны бекапы файлов, скуэль баз, лдап каталога и т.д.
Изначальное планирование — это конечно хорошо. Но уродский формат файлов (даже не описанный формально), гигантское количество скобочек удручают, когда приходится ЧАСТО менять формат таких бэкапов…
Так хотелось бы графический интерфейс для создания этих файлов или, на худой конец, хотя бы синтаксический проверщик их…
Так хотелось бы графический интерфейс для создания этих файлов или, на худой конец, хотя бы синтаксический проверщик их…
ну не знаю. в конфиге того же энджинкса скобочек не меньше. и никто не жалуется. мне кажется тут дело привычки.
в принципе я согласен — можно было бы сделать проще, но так захотелось разработчикам — ну и ладно. одно могу сказать, что мне бакула нравится. другой вопрос, что для «просто скопировать файлы» с компа на комп она может быть слишком навороченная.
в принципе я согласен — можно было бы сделать проще, но так захотелось разработчикам — ну и ладно. одно могу сказать, что мне бакула нравится. другой вопрос, что для «просто скопировать файлы» с компа на комп она может быть слишком навороченная.
Конфиги бакулы можно подсвечивать как bash код в редакторах (в том же Gedit).
Сама бакула при старте демонов выдает вполне вменяемые Warning's когда в конфиге находит синтаксические ошибки.
Ну и да, как уже заметили, в Nginx, Bind синтаксис конфигов довольно похожий))
Единственное что меня в первое время смутило — путался с именами и паролями, но довольно быстро разобрался.
Сама бакула при старте демонов выдает вполне вменяемые Warning's когда в конфиге находит синтаксические ошибки.
Ну и да, как уже заметили, в Nginx, Bind синтаксис конфигов довольно похожий))
Единственное что меня в первое время смутило — путался с именами и паролями, но довольно быстро разобрался.
Дружище, а не расскажешь подробнее, как ты бакулу с заббиксом дружил?
а все просто. написал скрипт на перле, который делает list jobs в бакуле за текущий день и смотрит статус для каждого из выполненных заданий, а также размер бекапа опять-таки для каждого из заданий. скрипт возвращает 0 если все задания прошли успешно и нет бекапов с нулевым размером, и 1 если хотя бы в одном задании ошибка. далее подключил этот скрипт к заббиксу в конфиге агента через UserParameter, и назначил соответсвующий ивент и триггер в графическом интерфейсе заббикса.
вот и все. будут еще вопросы — обращайся.
вот и все. будут еще вопросы — обращайся.
Замороченная штука. Слишком.
Использую fsbackup, который всё кидает на FTP.
Использую fsbackup, который всё кидает на FTP.
Правильная тема… к сожалению незнаю ответов и сам бы с удовольствием послушал идеи. Пока мой путь так же заббикс и тестовые развертки.
я для ms sql server настроил job-ы которые каждую ночь делают бэкап, потом его архивируют (баз много и большой размер) и копируют на другой сервак. Если происходит сбой на любой стадии, то приходит письмо.
контролировать целостность архива проблемно из-за его размера, но пока проблем нету, обычно нарушение целостности бэкапа происходит в случае ошибок при архивировании, а в этом случае приходят письма счастья.
контролировать целостность архива проблемно из-за его размера, но пока проблем нету, обычно нарушение целостности бэкапа происходит в случае ошибок при архивировании, а в этом случае приходят письма счастья.
Был ещё такой вариант у меня, отсоединился жесткий диск от «зеркала», но нигде об этом не сообщалось, так и работало пол года пока одинокий винт не начал подавать признаки скорого выхода из строя, спасло то, что винт умер не до конца и удалось с него бекап вытащить (это не моё хозяйство, я бекапы на разные сервера делаю). Поэтому для себя сделал вывод, что необходимо использовать нормальные RAID контроллеры с оповещением и делать бекапы на разные серверы. При достаточном финансировании я бы сделал у себя в конторе сервер с резервными копиями и, например, при выходе из строя одного из серверов его можно было бы в виртуальной машине развернуть (на том же резервном).
потратить время чтобы выучить bacula, узнать как в вашей системе делаются snapshots — не составит много времени и великого труда, %username%
Вспомнилось хокку по теме статьи:
Ещё момент: очень помогают информативные названия файлов бэкапов. Я формирую название файла из даты бэкапа, названия системы, названия конкретной её части и контрольной суммы конечного файла. Дату бэкапа пишу в формате YYYYMMDD для правильной сортировки. Как бонус имеется информация о размере файла, поэтому пустой файл бэкапа создаю руками, чтобы в глаза сразу бросались файлы с нулевым размером. Т.е., например, для (прости господи) эсочных баз, коих уже за 20, где-то так:
Файлы раскидываются по каталогам дата/тип_системы, но из названия файла эту информацию убирать нельзя — вне конкретного каталога будет сложно понять, что это за бэкап.
Вечны налоги,Может, просмотрел, но не увидел наиболее часто встречающуюся проблему: бэкапы настроены, делаются без ошибок и регулярно проверяются. Но, блин, хранятся на одном и том же сервере с данными, на одном и том же диске. Писать надо как минимум в два места, очень желательно, географически разнесённых. От налоговых, кстати, тоже спасает.
смерть и потеря данных.
Что на этот раз?
Ещё момент: очень помогают информативные названия файлов бэкапов. Я формирую название файла из даты бэкапа, названия системы, названия конкретной её части и контрольной суммы конечного файла. Дату бэкапа пишу в формате YYYYMMDD для правильной сортировки. Как бонус имеется информация о размере файла, поэтому пустой файл бэкапа создаю руками, чтобы в глаза сразу бросались файлы с нулевым размером. Т.е., например, для (прости господи) эсочных баз, коих уже за 20, где-то так:
20090531_1с_buhXXXXX_UNKNOWN.zip 0K
20090531_1с_buhYYYYYY_2bc29b36f623ba82aaf6724fd3b16718.zip 1213MФайлы раскидываются по каталогам дата/тип_системы, но из названия файла эту информацию убирать нельзя — вне конкретного каталога будет сложно понять, что это за бэкап.
Про «не хранить бекапы на том же сервере, что и данные» в статье озвучивал. Но это факт, очень важное условие.
Именование файлов вашим способом очень правильное: писать дату правильно в имя файлов очень правильно. А вот писать еще и размер файла в название — никогда не думал, но выглядит полезно. Спасибо.
Единственное что мне кажется сомнительным писать мд5 в названии. Думаю, что самого размера файла в названии было бы более чем достаточно.
Именование файлов вашим способом очень правильное: писать дату правильно в имя файлов очень правильно. А вот писать еще и размер файла в название — никогда не думал, но выглядит полезно. Спасибо.
Единственное что мне кажется сомнительным писать мд5 в названии. Думаю, что самого размера файла в названии было бы более чем достаточно.
По размеру файлов это я просто невнятно сформулировал — конечно, оно не отражается в имени, я имел в виду, что информация о размере файла отдается ОС и увидеть ее можно в любом файловом менеджере. Гораздо сложнее контролировать само наличие бэкапа, если их в одном каталоге достаточно много. Именно поэтому я создаю пустышки. Они мозолят глаза своими ноликами в колонке «размер файла».
По мд5 в имени — это просто старая привычка. Иногда сами системы и бэкап-сервер соединялись ненадёжными каналами, поэтому, при приёме мне надо было контролировать целостность файла. Отдавать контрольную сумму отдельным файлом, как это обычно делается, мне не нравится. Больше операций — больше вариантов ошибиться. Поэтому я всегда передавал его вместе с другими признаками как часть имени файла.
Кстати, сегодняшние каналы тоже иногда подводят. У меня товарищ недавно несколько дней мучался с установкой операционки на сервер, было какое-то дурацкое сообщение с ошибкой в каком-то конкретном драйвере. Интернеты по этому поводу безмолствовали. Решилось очень просто — выкачал и записал болванку еще раз. Оказалось, в первый раз образ скачался, но где-то при передаче он немного побился. Простая проверка контрольной суммы сэкономила бы в этом случае несколько рабочих дней.
По мд5 в имени — это просто старая привычка. Иногда сами системы и бэкап-сервер соединялись ненадёжными каналами, поэтому, при приёме мне надо было контролировать целостность файла. Отдавать контрольную сумму отдельным файлом, как это обычно делается, мне не нравится. Больше операций — больше вариантов ошибиться. Поэтому я всегда передавал его вместе с другими признаками как часть имени файла.
Кстати, сегодняшние каналы тоже иногда подводят. У меня товарищ недавно несколько дней мучался с установкой операционки на сервер, было какое-то дурацкое сообщение с ошибкой в каком-то конкретном драйвере. Интернеты по этому поводу безмолствовали. Решилось очень просто — выкачал и записал болванку еще раз. Оказалось, в первый раз образ скачался, но где-то при передаче он немного побился. Простая проверка контрольной суммы сэкономила бы в этом случае несколько рабочих дней.
www.taobackup.com/ мопед не мой…
Перебрав несколько разных тулзов для бэкапов (унылое гамно или гусеничный ентерпрайз) сделал свою (белая и пушистая).
Основное предположение — я не хочу возится, разбираясь с бэкап-тулзами к каждой из софтин на каждом из серверов, я просто делаю у себя полную копию всего необходимого (обычно это /home, /etc, /var/lib/mysql, /var/lib/svn и им подобное). Условное допущение — в любой из моментов, когда я закончил копирование, подконтрольная сущность может восстановится в той или иной мере. С просто файлами — работает, с svn — работает, с живыми сущностями типа баз mysql тоже работает, как это ни странно.
Как средство копирвания — rsync, транспорт — ssh (настроен .ssh/config и .ssh/authorized_keys на каждом из серверов). Как вторичное средство — уже отсинхронизированные локальные копии бэкаплю тут же еще раз, раз в неделю кумулятивный архив, 2 раза в день — инкрементальный. Тулкит — bash + tar + cron.
В качестве мониторинга используется веб-интерфейс. Бэкенд — django+couchdb. В couchdb хранятся конфиги серверов и логи. На основании логов делается вывод (на стороне сервера) — удачно ли прошёл бэкап (статус-коды всех завершившихся rsync-ов равны нулю). Страничка мониторинга, в которую я заглядываю раз в пару дней содержит до нельзя простой вывод — имя сервера, дата последнего бэкапа и его статус (зелёная или красная лампочка). В случае чего, доступны все логи всех запущенных rsync'ов по любому серверу (логи хранятся в процессе работы и аттачатся к документам в couchdb, благо нативная и удобная фишка).
Через какое-то время допилю еще пару мелочей, дорисую документацию и выложу в паблик. Может кому-то будет интересно.
Из плюсов:
1. Абсолютно стандартный toolchain, присутствующий в любом из линуксов, работающий по мануалам, доступный к модификации под каждый конкретный случай (хотите этот сервер бэкапить с ограничением скорости — да не вопрос).
2. Удобство мониторинга состояния (если бэкап провалился — я об этом узнаю просто бегло взглянув на страничку мониторинга, без лазанья по диску и логам).
3. Во время каждого из бэкапов скачиваются только изменения. Если появляются только новые файлы (файлопомойка) или только растут старые (couchdb, логи, myisam-базы), то трафик будет минимальный, на сколько только может быть.
Из минусов:
1. Бэкапы подразумеваются many-to-one, т.е. всё сливается на один сервер. Несколько бэкап-серверов не предусмотрено (но эта фишка легко реализуется, возможно и сделаю её до паблик-релиза).
2. Сложности бэкапа виндовс-машин (придётся ставить rsync-сервер на них).
Из недоделанного:
1. Кастомизация архивирования. Например, для некоторых бэкапов я хочу хранить только последние 2 дня, а для других — 2 года.
Бля, во написал… Практически, готовая readme…
Основное предположение — я не хочу возится, разбираясь с бэкап-тулзами к каждой из софтин на каждом из серверов, я просто делаю у себя полную копию всего необходимого (обычно это /home, /etc, /var/lib/mysql, /var/lib/svn и им подобное). Условное допущение — в любой из моментов, когда я закончил копирование, подконтрольная сущность может восстановится в той или иной мере. С просто файлами — работает, с svn — работает, с живыми сущностями типа баз mysql тоже работает, как это ни странно.
Как средство копирвания — rsync, транспорт — ssh (настроен .ssh/config и .ssh/authorized_keys на каждом из серверов). Как вторичное средство — уже отсинхронизированные локальные копии бэкаплю тут же еще раз, раз в неделю кумулятивный архив, 2 раза в день — инкрементальный. Тулкит — bash + tar + cron.
В качестве мониторинга используется веб-интерфейс. Бэкенд — django+couchdb. В couchdb хранятся конфиги серверов и логи. На основании логов делается вывод (на стороне сервера) — удачно ли прошёл бэкап (статус-коды всех завершившихся rsync-ов равны нулю). Страничка мониторинга, в которую я заглядываю раз в пару дней содержит до нельзя простой вывод — имя сервера, дата последнего бэкапа и его статус (зелёная или красная лампочка). В случае чего, доступны все логи всех запущенных rsync'ов по любому серверу (логи хранятся в процессе работы и аттачатся к документам в couchdb, благо нативная и удобная фишка).
Через какое-то время допилю еще пару мелочей, дорисую документацию и выложу в паблик. Может кому-то будет интересно.
Из плюсов:
1. Абсолютно стандартный toolchain, присутствующий в любом из линуксов, работающий по мануалам, доступный к модификации под каждый конкретный случай (хотите этот сервер бэкапить с ограничением скорости — да не вопрос).
2. Удобство мониторинга состояния (если бэкап провалился — я об этом узнаю просто бегло взглянув на страничку мониторинга, без лазанья по диску и логам).
3. Во время каждого из бэкапов скачиваются только изменения. Если появляются только новые файлы (файлопомойка) или только растут старые (couchdb, логи, myisam-базы), то трафик будет минимальный, на сколько только может быть.
Из минусов:
1. Бэкапы подразумеваются many-to-one, т.е. всё сливается на один сервер. Несколько бэкап-серверов не предусмотрено (но эта фишка легко реализуется, возможно и сделаю её до паблик-релиза).
2. Сложности бэкапа виндовс-машин (придётся ставить rsync-сервер на них).
Из недоделанного:
1. Кастомизация архивирования. Например, для некоторых бэкапов я хочу хранить только последние 2 дня, а для других — 2 года.
Бля, во написал… Практически, готовая readme…
а MS Exchange Information Store нормально ntbackup'ом бэкапить? точно потом восстановится?
Бэкаплю боевые сервера — rsync+zfs слепок каждые 8 часов. Проверить — zfs list -t snapshot.
> 1. Человеческий фактор
> 2. Ненадежность тулзов
> 3. Ошибки в логике проверок
> 4. проч.
1 — проверяется сразу после любых манипуляций со скриптами бекапа (явно, т.е. открытием и развертыванием бекапа)
2 — зачем ловить stderr в cron-скриптах, когда его можно автоматом посылать на почту, если он (stderr) есть?
3 — чо?
4 — чо?
Никогда не было проблем с бекапоми. Вообще =). Разворачивал при этом тыщщу раз
> 2. Ненадежность тулзов
> 3. Ошибки в логике проверок
> 4. проч.
1 — проверяется сразу после любых манипуляций со скриптами бекапа (явно, т.е. открытием и развертыванием бекапа)
2 — зачем ловить stderr в cron-скриптах, когда его можно автоматом посылать на почту, если он (stderr) есть?
3 — чо?
4 — чо?
Никогда не было проблем с бекапоми. Вообще =). Разворачивал при этом тыщщу раз
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как узнать, что бекап прошел успешно