« Акисмет палит темы | Полезный софт для защиты компьютера »
Расскажу как у меня устроено резервное копирование, может кому-то пригодится. Понятно что я в этой области ничего принципиально нового не скажу и скорей всего я изобрёл велосипед, но мой велосипед вроде более продвинутый, чем например вот этот.
Для начала я делаю так, чтобы на сервере все нужные для архивации файлы были внутри домашней директории одного юзера, чтобы их не приходилось выкапывать по всему диску. То что невозможно туда перенести, например настройки крона – перед сохранением просто скидываются в файл и этот файл копируется в нужную директорию, примерно вот так: crontab -l > /home/user/settings/crontab.conf. Тоже самое делается со всеми нужными файлами о которых можно вспомнить, само копирование записывается в батник, который и будет работать бэкап-утилитой. Если вы что-то забудете, это не страшно, лучше забыть 1%, но сохранить 99, чем ничего не делать и в итоге потерять вообще всё. Полезный совет насчёт батника: если вы пишете на PHP, но при этом отнюдь не линуксоид, скрипт для архивации тоже можно написать на PHP, хуже он от этого не станет, а упираться в изучение тонкостей юниксового шелла ради бэкапа нет смысла. Итак, все данные собраны вместе, теперь архивируем их обычным zip’ом: zip -r filename * -x@exclude.lst. Тут самое интересное находится внутри файла exclude.lst – туда надо прописать всё, что не должно архивироваться, например временные файлы, логи и файлы которые будут архивироваться отдельно. Файл советую переименовать по текущей дате, например server1-20071001.zip, чтобы потом знать что в нём. Итак, у нас имеется архив со всем нужным для быстрого восстановления сервера, но он находится на том же сервере, то есть пока в качесвте бэкапа бесполезен. Для этого нужно его либо перенести на другой сервер, либо воспользоваться каким-то сторонним сервисом файлохранения.
Для быстрого переноса файлов между серверами подходит совсем даже не ftp, как наверняка будут советовать любители vi, а rsync (man rsync). В идеале ваш скрипт должен создать архив каждого сервера на каждом сервере, чтобы потом можно было восстановить конфигурацию и данные любого сервер при выходе его из строя. В качестве стороннего файлохранилища я пробую использовать Amazon S3 – “бесконечное” дисковое пространство от Амазона, плюс утилиту Jungle Disk, которая как раз с этим самым S3 работает, причём как под виндой, так и под линуксом.
Для сохранения мускульных баз данных я использую некий MySQL Backup Script. Вроде он достаточно надёжен, работает лучше чем например бэкап в phpMyAdmin, который может например не закачатся назад потому что окажется слишком длинным или не в той кодировке.
Напоследок расскажу одну байку, про то как не нужно делать резервное копирование. Работал я как-то в одной фирме, где вроде бы резервирование было устроено серьёзно, каждый день со всех дисков скидывался бэкап, дальше всё это отправлялось в специальную контору, которая записывала бэкап на кассеты и хранила в какой-то горе в секретной шахте. Приколы начинались, когда этим всем нужно было воспользоваться в обратную сторону. Если нужный файл оказывался на кассете уже вынутой из стриммера и положенной в шахту на полочку, то за то чтобы снять кассету с полки и поставить в сервер, с фирмы брали $150 (это в дополнение к миллионому контракту на обслуживание).
Так что тут Амазон выглядит как явный прогресс и шаг вперёд.
4 Responses
October 13th, 2007 at 08:19:21
// php gravatar() ?>1Криво это.
Для бэкапа на коленке проще всего поставить нецентрализованную систему version control, идеальным будет Git (написан Линусом; под ним ведут разработки ядра).
Далее, в /etc просто делаем commit всего. Git умеет хранить в сжатом формате, и в одном (сжатом) файле.
Смысл version control как раз в отслеживании изменений и записи новых версий.
Нецентрализованность Git’а в том, что любую из директорий под его контролем можно взять по сети себе, в локальный склад, и перенести файлы как новую ветвь если надо, или в продолжение существующей.
Вот и все. Всегда – и на сервере, и на административной машине – вы имеете доступ ко всем прошлым версиям конфигураций, всегда можете восстановить все за минуты, всегда можете увидеть точно какие файлы поменялись и как именно.
Разумеется, можно впихиваь на сервере обновления cron’ом, и так же кроном брать их на административную машину.
October 13th, 2007 at 15:06:12
// php gravatar() ?>2Спасибо за подсказку насчёт этого софта, но лично мне такое не подойдёт, у меня куча временных файлов, типа логов лежит там же где данные, соответсвенно коммитить всё нет никакого смысла. Кроме того, размер файла-репозитория думаю очень быстро вырастет до нетранспортабельного. А дневной ZIP с исключёнными директориями подходит идеально.
October 13th, 2007 at 17:06:12
// php gravatar() ?>3Вы совершенно неправы.
Временные файлы в Git-е удаляются точно так же легко, как и из директории – командой “git-rm”. Поэтому снежный ком просто не будет расти в первую очередь.
Во-вторых, хранение истории изменений невременных;
Сжатая хранилка СЖИМАЕТ, я держу ЖЖ-заметки всех, кого я читаю за последний год примерно в 70МБ – и имею мгновенный доступ к ним за сотые доли секунды, хранилка проиндексирована Git-ом.
В-третьих, не приходится заниматься самодеятельностью и следить за тем, чтобы чего-то не упустить. Git држит SHA1 (вроде МД5) и сравнивает файлы по их крипто-хэшу.
В-четвертых, при пересылках между машинами вы пересылаете ТОЛЬКО ОТЛИЧИЯ, а не всю кучу каждый раз.
В-пятых, дабы не отдавать цепочку команд, хотя и значительно урезанную из-за того, что множество дел version-control system делает за вас, стандартные команды помещаются в скрипт.
Я программирую на shell с использованием make
Gnu make – инструмент для ОБЩЕГО программирования, который позволяет не заботиться о целом, думая лишь “локально”, она “следит за проектом” сама. Мейк также отдает команды, проверяя их exit status и т.д. Это поразительная программа о существовании которой в этом качестве мало кто подозревает. Невозможно учить админов работать с shell и не применять make как часть программирования в командной строке.
Я написал программу, ведущую веб-блог как мейкфайл, сам мейк при этом используется как generic CGI application под веб-сервером, маленькая и шустрая, необыкновенно сильная и достаточно быстрая (этот CGI скрипт может обеспечивать до 18 запросов в секунду при выдаче одного файла или до 1.5 запросов в сек если надо пробежать 30,000 файлов в хранилке — на 500МГц нашине.
Т.е. в нашем первом примере весь “менеджмент” сводится к тому, что у меня в директории лежит мейк-файл, содержащий в себе скрипт.
Если я говорю “make”, он печатает help message и объясняет мне какие цели (т.е. скрипты, задачи, которые он умеет решать) есть в этом мейк-файле.
Далее, я говорю “make prepare-daily”, и он обновит хранилку, или “make what-changed” и он мне доложит какие файлы изменились и т.д.
с другой машины я скажу “make fetch-and-report” и майк на этой стороне сделает всю работу и т.д.
Т.е. я получил программу, о которой можно ничего не помнить – “make help” доложит мне как она работает, и т.д.
Точно так же из крона достаточно отдать одну команду: “cd somedir; make daily”
Так что изменить нужно просто инерцию своего мышления. (Это всегда самое трудное)
May 5th, 2008 at 13:15:13
// php gravatar() ?>4[...] в Яндексе, а победителю будет приз – $100. Про свой вариант серверного бэкапа я уже [...]
RSS feed for comments on this post · TrackBack URI
Написать комментарий
Про что писал
Календарь
Куйворды
Архив
Подписка на блог
Статистика подписки
Страницы
Комментарии
Последние посты
Blogroll
Счётчики
Свежие записи
Последние комментарии
Интересное на блоге
Самое комментируемое
SEO блог где палят темы is proudly powered by WordPress - BloggingPro theme modified by alexf