4722 читателя, 729 постов
Администрация
Модераторы
Блог для любителей и профессионалов, использующих Linux дома и на работе :)
Linux для всех whois
- индекс
- 181,26
А ты сделал бэкап?
Доброго времени суток %habrauser%!
Как известно backup — must be! Но просто сделать архив данных — это еще не значит грамотный бэкап. Когда у наших клиентов начали появляться сервера на базе Calculate directory server встал вопрос о выборе средств для создания резервных копий данных. Поиск готовых решений ничего толкового не дал, поэтому пришлось писать самим.
Для начала скажу что нам прежде всего нужно от программы:
К п.1 у нас особые требования. Не все архиваторы умеют делать инкременты от уже инкрементального архива, а именно это нам и необходимо.
Программа написана на баше. Сам текст скрипта я здесь приводить не буду ибо он достаточно большой. Лучше прокомментирую дефолтный конфиг, так, по-моему, луше будет видно возможности программы.
Файл конфигурации содержит в себе блоки параметров: один обязательный «main» и дополнительные. Обязательный блок имеет строго определенное название «main» и описывает основные параметры архивации, здесь же можно задавать единые параметры архивации которые будут использованны для всех дополнительных блоков. Дополнительные блоки могут иметь произвольные имена. В них происходит описание параметров конкретных архивов. Порядок описания блоков не имеет значения, главное указать какой блок будет обработан следующим.
Приведеный ниже конфиг описывает следующую логику архивирования:
Для задания объектов подлежащих архивации, а так же исключенных из нее, используются обычные файлы списки, которые воспринимает tar. Эти два файла должны находиться в папке с конфигом. Так же в папке с конфигом находится папка «services». В эту папку можно кидать линки на службы, которые непосредственно перед архивацией будут останавливаться, а после снова запускаться. Так же туда можно кидать и исполняемые файлы, в которых можно описать дополнительные действия до и после архивации. Все эти файлы запускаются с параметром «stop» перед архивацией и «start» после архивации.
Для установки скачайте архив bbackup.tar и распакуйте его куда не жалко и запустите «setup.sh».
Сам запуск программы до безобразия прост:
bbackup.sh <файл конфига>
Например:
$ bbackup.sh /etc/defconf/main.conf
Но скрипт создавался для автоматизации, поэтому запихнем его в крон на ежедневное исполнение.
На этом пожалуй я и закончу. Всем удачных бэкапов и пусть они вам никогда не пригодятся!
P.S. Сразу приношу свои извенения за некоторую сумбурность и неструктурированность данного поста. Я уже давно хотел его написать, но все никак руки не доходили, посему это писалось в порыве энтузиазизма в ущерб сна %)
_________
Текст подготовлен в ХабраРедакторе
Как известно backup — must be! Но просто сделать архив данных — это еще не значит грамотный бэкап. Когда у наших клиентов начали появляться сервера на базе Calculate directory server встал вопрос о выборе средств для создания резервных копий данных. Поиск готовых решений ничего толкового не дал, поэтому пришлось писать самим.
Для начала скажу что нам прежде всего нужно от программы:
- Инкреметальность архивов
- Уверенность в наличии архивов
- Гибкость настройки
- Отчет о работе
К п.1 у нас особые требования. Не все архиваторы умеют делать инкременты от уже инкрементального архива, а именно это нам и необходимо.
Программа написана на баше. Сам текст скрипта я здесь приводить не буду ибо он достаточно большой. Лучше прокомментирую дефолтный конфиг, так, по-моему, луше будет видно возможности программы.
Файл конфигурации содержит в себе блоки параметров: один обязательный «main» и дополнительные. Обязательный блок имеет строго определенное название «main» и описывает основные параметры архивации, здесь же можно задавать единые параметры архивации которые будут использованны для всех дополнительных блоков. Дополнительные блоки могут иметь произвольные имена. В них происходит описание параметров конкретных архивов. Порядок описания блоков не имеет значения, главное указать какой блок будет обработан следующим.
Приведеный ниже конфиг описывает следующую логику архивирования:
- Первого числа каждого месяца делать полный архив данных (ежемесячный архив). Он будет помещен в папку "/backup/ARCH/Monthly/" с именем «fullsystem.tar». При удачном завершении старые архивы, старше 3х месяцев, будут удалены.
- Каждое воскресенье делать инкрементальный архив от ежемесячного (еженедельный архив). Будет помещен в папку "/backup/ARCH/Weekly/" с тем же именем. При удачном завершении старые архивы, старше 4х недель, будут удалены.
- Каждый день делать инкрементальный архив от еженедельного (ежедневный архив). Будет помещен в папку "/backup/ARCH/Dayly/" с тем же именем. При удачном завершении старые архивы, старше 8ми дней, будут удалены.
- Список файлов которые будут заархивированны указаны в файле «monthly.include», файлы которые следует исключить заданны в «monthly.exclude»
$ cat /etc/defconf/main.conf
# Блок основных параметров
# Здесь задаются основные настройки бекапирования, для более точной настройки могут
# быть определенны в разделах описания архива. Исключением являються параметры с меткой (m)
main {
# В конфигурационном файле допускается использование
# своих переменных.
DEF_ARCHIVE_PATH="/backup/ARCH"
# Путь к папке с бэкапами
ARCHIVE_PATH=$DEF_ARCHIVE_PATH
# Имя архива
ARCHIVE_NAME="fullsystem.tar"
# Количество последних архивов которые не будут удалены
REMOVE_DEPTH=3
# Дополнительные параметры tar (m)
TAR_ADD_PARAMS="-vR"
# Ошибки которые не будут прерывать выполнение скрипта
# (в конце обязателен пробел) (m)
TAR_ERR_EXCLUDE="0 "
# Настройки почты (не забудте настроить "/etc/ssmtp/ssmtp.conf",
# а так же установить почтовый клиент "mutt")
# Тема письма
SUBJECT="ITEq Error level: $ERROR_CODE"
# Получатель
MAILTO="logger@site.ru"
# Посылать ли лог по почте (all - отправлять всегда, error - только при ошибках,
# при любом другом значении письмо отправлено не будет)
SENDMAIL='all'
# Первый блок конфига бекапа который будет обработан
NEXT=montly
}
# Месячный бэкап
# Первый блок всегда описывает полый архив
# все последующие будут выполняться инкрементным
# архивом от предыдущего
montly {
ARCHIVE_PATH="$DEF_ARCHIVE_PATH/Monthly/"
# Задает номер месяца когда разрешено делать архивацию
# Возможные значения от 1 до 12; 0 - любой месяц (равносильно 1-12 и 0/1)
# Так же можно задавать значения в виде интервала (1-3) или
# кратного числа (0/3). Далее идут три эквивалентные записи
MONTH=0
#MONTH=1-12
#MONTH=0/1
# Задает день месяца когда разрешено делать архивацию
# Возможные значения от 1 до 31
# Варианты записи аналогичны заданию месяца
DAY=1
# Задает день недели когда разрешено делать архивацию
# Возможные значения от 1 до 7 (1 - понедельник)
# Варианты записи аналогичны заданию месяца и дня месяца
DAY_OF_WEEK=0
# Задает имя файла в котором перечисляються объекты подлежащие архивации
TO_ARCHIVE_FILE_LIST="monthly.include"
# Задает имя файла с объектами исключенными из архива
EXCLUDE_FROM_ARCHIVE="monthly.exclude"
# Указываеться количество хранимых архивов
REMOVE_DEPTH=3
# Задает секцию с описанием следующего архива
NEXT=weekly
}
# Недельный бэкап
weekly {
ARCHIVE_PATH="$DEF_ARCHIVE_PATH/Weekly/"
MONTH=0
DAY=0
DAY_OF_WEEK=7
TO_ARCHIVE_FILE_LIST="monthly.include"
EXCLUDE_FROM_ARCHIVE="monthly.exclude"
REMOVE_DEPTH=4
NEXT=dayly
}
#Ежедневный бэкап
dayly {
ARCHIVE_PATH="$DEF_ARCHIVE_PATH/Dayly/"
MONTH=0/1
DAY=0
DAY_OF_WEEK=0
TO_ARCHIVE_FILE_LIST="monthly.include"
EXCLUDE_FROM_ARCHIVE="monthly.exclude"
REMOVE_DEPTH=8
NEXT=none
}
Для задания объектов подлежащих архивации, а так же исключенных из нее, используются обычные файлы списки, которые воспринимает tar. Эти два файла должны находиться в папке с конфигом. Так же в папке с конфигом находится папка «services». В эту папку можно кидать линки на службы, которые непосредственно перед архивацией будут останавливаться, а после снова запускаться. Так же туда можно кидать и исполняемые файлы, в которых можно описать дополнительные действия до и после архивации. Все эти файлы запускаются с параметром «stop» перед архивацией и «start» после архивации.
Для установки скачайте архив bbackup.tar и распакуйте его куда не жалко и запустите «setup.sh».
Сам запуск программы до безобразия прост:
bbackup.sh <файл конфига>
Например:
$ bbackup.sh /etc/defconf/main.conf
Но скрипт создавался для автоматизации, поэтому запихнем его в крон на ежедневное исполнение.
echo -e "#!/bin/sh\n/sbin/bbackup.sh /etc/bbackup/defconf/main.conf">/etc/cron.daily/bbackup.shНа этом пожалуй я и закончу. Всем удачных бэкапов и пусть они вам никогда не пригодятся!
P.S. Сразу приношу свои извенения за некоторую сумбурность и неструктурированность данного поста. Я уже давно хотел его написать, но все никак руки не доходили, посему это писалось в порыве энтузиазизма в ущерб сна %)
_________
Текст подготовлен в ХабраРедакторе
комментарии (73)
(на самом деле просто не обратил внимания что речь шла о сервере ;-) )
Это не так. Первое, что приходит на ум — AMANDA и Bacula. А кроме них есть ещё множество других систем.
Настраивать их, разумеется, надо руками. Так искаропки и невозможно предусмотреть все потребности админов. Всё-таки к бэкапам данных на серверах требования совсем другие, чем к данным на типичном десктопе.
Я живу в консоли и сейчас у меня открыто два окна iTerm по пять табов в каждом, но если что-то можно сделать в GUI, играть симфонии на клавиатуре у меня нет желания.
Он тем более ниразу не консольный. Это демон. Запускается по расписанию.
(иными словами: гуй у него есть? если на то пошло, TimeMachine тоже демон).
(задумался и достал из ящика стола внешний винт для бэкапов и подключил к лаптопу).
А неужели Apple предоставляет SLA?
>Может всё что угодно забекапить, так как присутствует возможность обернуть в пользовательский скрипт
Причем тут это? я говорю про интеграцию TimeMachine в приложения. самый обычный пример: почта( или контакты), а маке она храница в sqlite таблицах. на линуксе мы конечно же тупо забекапим фаил, да? А теперь нам надо восстановить одно удаленное письмо(контакт), но сохранить все изменения (допустим это было все месяц назад). Ну и что вы сделаете? Я просто запущу TimeMachine и восстановлю нужную мне часть. А на линуксе — проблематично…
>Следить вообще за всем надо, даже за своим мозгом.
какие адепты GNU/Linux не воспитанные. TimeMachine оповестит меня о проблеме бекапа, в то время как приложения под линукс может работать глючно и не оповещать об этом. Потом зачем простому рядовому пользователю думать какие каталоги надо бэкапить и где его почтовая программа хранит почту?
>А неужели Apple предоставляет SLA?
Нет, но не «as is».
>>>Нет, но не «as is».
Ну конечно, ага.
images.apple.com/legal/sla/docs/macosx106.pdf
Это вы эпик фэил если на маке используете тундерберд. Сколько людей его использует в макоси? Я рассмотрел 2 приложения с которыми я, а также большая часть пользователей apple часто работает. Опять все по-гиковски считаем, очнитесь линуксоиды еб^H^H ментальный секс с компьютером нравится только вам. Обычно пользователь просто хочет использовать компьютер в своих целях, а не работать над этим компьютером напильником, чтобы он был похож на рабочий инструмент.
Теперь вопрос по возможности ваших скриптов(я ими не пользовался и не могу сказать): позволят ли они откатить изменения только в _одном_ каталоге __не_ заходя _в консоль_ _не_ отвлекаясь от _основной задачи__? Тоесть тыкнул на хоткеи, вытащил 2 файла из версии за 1 января и 5 файлов за 1 февраля.
>Если rsnapshot не смог сделать бекап он может послать письмо, записать в лог, в общем-то всё что захотите.
ну вот опять я должен, что-то настраивать, еще и лог проверять.
никто не говорит про то, что использовать TM на сервере, я говорил про десктоп, а все эти ваши скрипты это излишний геморрой только.
>Ну конечно, ага.
ясно дело apple не отвечает за мои личные данные, но если их приложение будет лажать будет коллективный иск и apple будет платить.
>>>Тоесть тыкнул на хоткеи, вытащил 2 файла из версии за 1 января и 5 файлов за 1 февраля.
Для этого есть более удобный инструмент — называется система контроля версий. Но, представьте себе, rsnaphot тоже такое умеет делать. Как без консоли, так и с ней. Бекапы это просто директории на каждый день своя. А уж как вы там получаете доступ к ним — это уже выбор пользователя.
>>>ясно дело apple не отвечает за мои личные данные, но если их приложение будет лажать будет коллективный иск и apple будет платить.
Ещё разок прочитайте. Аппл не отвечает вообще ни за что в этом софтваре.
>Для этого есть более удобный инструмент — называется система контроля версий. Но, представьте себе, rsnaphot тоже такое умеет делать. Как без консоли, так и с ней. Бекапы это просто директории на каждый день своя. А уж как вы там получаете доступ к ним — это уже выбор пользователя.
представляю своб девушку которая разбирается системой контроля версий. опять же близк красно глазика — я могу это сделать, значит любой может иначе хомяк-домохозяйка
>А уж как вы там получаете доступ к ним — это уже выбор пользователя.
вот когда у линукса появится, что-то по юзабильности близкое к TM тогда поговорим
>Ещё разок прочитайте. Аппл не отвечает вообще ни за что в этом софтваре.
Есть законы как бы. Вы будите удивлены, но в США они работают! Apple не отвечает за сохранность данных, но если приложения нанесет вред системе — будет суд, а если будет несколько таких случаев — будет коллективный иск, и скорее всего в пользу исцов.
Для этого есть Partimage, но он не поддерживает ext4,
и fsarchiver.
По сути Back in time делает cp -rf из под рута (если для всей системы), выбранных директорий и файлов) Сейчас еще посмотрю, есть ли возможность включения сжатия.
Нужно было лучше поискать :-)
Но после того как сервер сгорел или взломан возникает задача развернуть новый сервер ASAP. И тут-то начинаются танцы с бубном — потому что если сервер жил долго до этого, то просто apt-get install apache2 и распаковка архивов почему-то уже не срабатывает :-). Суммарно на сервере находится такое количество мелких залепук и бубнов, что быстро сообразить что надо сделать на новом сервере — нереально. Получается, что помимо сайтов, например, надо бэкапить конфиг апача еще. Помимо почтовых ящиков, конфиги MTA и pop3/imap серверов + всяких сторонних тулзов (напр вебморда для создания виртуальных почтовых доменов и ящиков).
Сейчас живем используя «бэкапы данных», но это не позволяет быстро поднять сервер. Желание автоматизировать процесс заставляет писать что-то свое, при этом есть дилемма:
метод 1) разделить сервер на сервисы (скажем, сайт aaa.com, почта aaa.com итд) и бэкапить их каждый отдельно. Но тогда не факт, что на новом сервере легко можно будет поставить бэкапный сервис с другой машины (так как набор софта на разных машинах разный)
метод 2) полный бэкап системы в формате… .deb! где в dependencies будут все пакеты, которые установлены на системе, а в содержании — все файлы, которые изменены (или добавлены) на машине и отличаются по хэшам от того, что в пакетах прописано. Тогда возникает сложность с тем, чтобы реализовать возможность инкрементальных бэкапов, бэкапы получаются большими, зато практически гарантировано (после нескольких предсказуемых движений напильником, напр. смены IP) получается в очень короткое время работоспособная система.
Но есть какое-то странное ощущение, что и это тоже — велосипед, который должен существовать уже лет 10 как :-)
или партимаджем — это уже по желанию.
в этом случае при желании (если ОЧЕНЬ срочно :) ) можно систему запустить с бекапа — достаточно сделать чрут с лайфсиди.
ну а если pivot root сделать так вообще)))
img197.imageshack.us/img197/4504/81768423.jpg
Поэтому про бэкап мы никогда не забываем :)
«1 Инкреметальность архивов
2 Уверенность в наличии архивов
3 Гибкость настройки
4 Отчет о работе»
Я нашел bacula и больше никогда ничего не искал.
Т.к. ежемесячный архив это полная (full) резервная копия, то это называется — дифференциальный архив (а точнее, дифференциальный бэкап), бакула же его делает на ура.
> # а так же установить почтовый клиент «mutt»
Не понятно, зачем еще и mutt нужен? Для отправки почты вполне достаточно ssmtp. Или у вас еще что-то там есть (в общем не понятно по посту)?
Я что-то не втыкаю, зачем делать инкрементальный архив от дифференциального (просто сам никогда не делал такого и не вижу в этом смысла)? Буду благодарен, если объясните. Хотя, это же, в полной мере можно сделать и с помощью вышеупомяутой бакулы.
Процитирую моего товарища:
Она на 10 по 5-тибальной шкале делает то, что описано в данном топике :)
Сам ее юзаю не очень давно. Стоит и дома и на работе и еще в нескольких офисах (не имеющих прямого отношения к работе). Доволен полностью.
Все, что автор описал в посте можно сделать и с помощью бакулы.
Я просто не люблю гуй на серверах и считаю, что он там излишен.
все делает, что описано в топике ;)
Ведь есть куча готовых опенсорсных решений: rsync, dump/restore, etc.
Поначалу тоже сам пытался что-то писать, по фтп файлы гонял туда-сюда и т.п.
Но потом, когда серваков уже стало слишком много, надоело плодить скрипты, да и прсто запутаться можно было в этом всем. В итоге построил централизованную систему бэкапа на rsync. Один раз настроил и забыл, вот уже 3 года все работает на ура.
Мой велосипед делает примерно то же самое, только он очень простой (70 строк тривиального кода на sh) и гибкий (поддержка шифрования архивов, блокирования базы данных, etc.). Инкрементальные архивы делаются tar-ом (поэтому для распаковки бэкапов ничего кроме tar не требуется). Задачи вроде удаления старых архивов — отлично делаются через cron+find, нет смысла встраивать их в систему создания бэкапов. Задача разделения недельных/месячных архивов отлично решается через cron+указание скрипту параметром разных каталогов для бэкапа. И т.д. — нет смысла ручками и с глюками реализовывать то, что отлично делают стандартные и проверенные десятилетиями утилиты.
В общем, если вам нужна надёжная, простая и гибкая система бэкапов — можете попробовать мой
велосипедpowerbackup. Для Gentoo-шников в моём оверлее есть ebuild для упрощения установки powerbackup.Поправьте, пожалуйста, если я не прав.
Мне кажется интересным вариант хранения бэкапов с использованием Dropbox (профессиональный акк. на 50 gb). Инкрементальный бэкап, надежность Amazon S3, клиент для Windows, Linux, MacOS.