Приветствую!
Всем известно, что админы делятся на тех кто еще пока не делает бекапы и на тех, кто уже делает бекапы. Однако, есть мнение, что еще бывают и такие, кто свято убежден, что бекапы делаются, а на деле это не так. В этом посте мне бы хотелось рассказать парочку реальных историй и (если получится) подвести итоги, сделать выводы.
Disclaimer: все истории правдивы, но кое-где обрезал края, образ компании и админа собирательный, все имена изменены, лица искажены до неузнаваемости, мой первый топик, бла-бла-бла, одинодин…
Вводная: представим компанию, как классическую компанию разработчиков: активно использует систему контроля версий (subversion — в нашем случае это важно), систему сборки версий, ну, и в нагрузку системы таскооборотов и вики. Объемы большие, потеря данных стоит больших денег, все должно работать «как часы» и «а если вдруг пожар» никого не волнует — данные хранить надо! Будем считать, что бекапы после того, как они сделаны автоматически попадают на магн. ленту/dvd в сейфе ген.директора/ячейку в швейцарском банке, поэтому у нас нет проблемы с доступностью последнего бекапа.
Прелонч
Админ пишет скрипт, который делает бекап баз данных и пишет об этом в лог.
Драма
Админ поднимает из бекапов дампы, аккуратно сложенные в папочки дата_время и видит там, что файлы дампов, начиная с «полгода_тому_назад», имеют нулевой размер.
После грозы
Ошибка была, как минимум, забавной. Вместо
было написано
На самом деле, то что запись в логи добавлялись именно при помощи >> и спасло ситуацию, помогло избежать самого страшного, но это, конечно, очень большая удача. Когда была найдена ошибка и файл log.txt размером в десяток гигабайт было делом техники найти нужные строки ближе к концу файла и развернуть-таки дамп.
Прелонч
Админ пишет скрипт который при помощи svnadmin делает дамп всего репозитория и кидает копию на бекап сервер. «А если что-то где пойдет не так?» Сделав правильные выводы из «истории номер раз» Админ добавляет логирование, что в такой-то день была забекаплен репозиторий на столько-то байт.
Драма
На самом деле, драмы удалось избежать, но, опять же, повезло, все могло быть существенно хуже. Хотелось сделать второй svn сервер, некую песочницу, чуть позже захотелось на него раз в день накатывать самый свежий дамп. При решении этой задачи Админ выяснил, что файл дампа репозитория, начиная с какого-то дня битый. При этом проверка на размер успешно проходила — все ревизии-то до этой критичной бекапились.
После грозы
В этот раз виноват был svnadmin, который делает полный бекап итерационно, начиная с самой первой ревизии. Какая-то ревизия посередине была битой, svnadmin доходил до нее, ломался, честно об этом сообщал и уходил в себя. Начиная отсюда всех подробностей, к сожалению, не знаю, но они нам не очень-то и важны. Починить ревизию не было возможности, удалить ее тоже не было возможности (не знаю, кстати, опять же, как обстоят дела с этим в свежих версиях subversion'а). Поэтому было принято командирское решение переносить гигантский репозиторий на песочницу ежедневно, используя rsync.
Что я хотел этим всем сказать? То, что лично мне кажется, очень трудно автоматизировать процесс принятия решения о том, что бекап прошел успешно. Т.е. успешно он, допустим, и прошел, а вот как не разворачивая этот бекап проверить, что в нем данные все правильные и актуальные? И, например, новые данные, спустя какое-то время не начнут ломать сам процесс бекапа? Причем, ошибки, приводящие к этому могут быть стары как мир:
Лично я не знаю ответы на вопросы озвученные выше. Если уважаемый хабр в курсе, прощу поделиться опытом.
А пока что я уже очень давно считаю, что принцип «сделал и забыл», по крайней мере, в случае проведения бекапов, не работает. И советую разворачивать бекап целиком на отдельно стоящем тестовом сервере, если есть такая возможность (здесь мы убиваем двух зайцев ценой времени написания разворачиволки бекапа). Или же писать отдельный скрипт проверки целостности бекапов. Проверять нужно:
Спасибо за внимание.
UPD Спасибо за карму => перенес в блог «системной администрирование».
Всем известно, что админы делятся на тех кто еще пока не делает бекапы и на тех, кто уже делает бекапы. Однако, есть мнение, что еще бывают и такие, кто свято убежден, что бекапы делаются, а на деле это не так. В этом посте мне бы хотелось рассказать парочку реальных историй и (если получится) подвести итоги, сделать выводы.
Disclaimer: все истории правдивы, но кое-где обрезал края, образ компании и админа собирательный, все имена изменены, лица искажены до неузнаваемости, мой первый топик, бла-бла-бла, одинодин…
Вводная: представим компанию, как классическую компанию разработчиков: активно использует систему контроля версий (subversion — в нашем случае это важно), систему сборки версий, ну, и в нагрузку системы таскооборотов и вики. Объемы большие, потеря данных стоит больших денег, все должно работать «как часы» и «а если вдруг пожар» никого не волнует — данные хранить надо! Будем считать, что бекапы после того, как они сделаны автоматически попадают на магн. ленту/dvd в сейфе ген.директора/ячейку в швейцарском банке, поэтому у нас нет проблемы с доступностью последнего бекапа.
История номер раз
Прелонч
Админ пишет скрипт, который делает бекап баз данных и пишет об этом в лог.
Драма
-Шеф, все пропало, шеф!
-Не проблема, у нас же бекапы есть! Где этот наш пузатобородатый?
Админ поднимает из бекапов дампы, аккуратно сложенные в папочки дата_время и видит там, что файлы дампов, начиная с «полгода_тому_назад», имеют нулевой размер.
После грозы
Ошибка была, как минимум, забавной. Вместо
mysqldump db > db.sql &2>> log.txt
было написано
mysqldump db > db.sql &>> log.txt
На самом деле, то что запись в логи добавлялись именно при помощи >> и спасло ситуацию, помогло избежать самого страшного, но это, конечно, очень большая удача. Когда была найдена ошибка и файл log.txt размером в десяток гигабайт было делом техники найти нужные строки ближе к концу файла и развернуть-таки дамп.
История номер два
Прелонч
Админ пишет скрипт который при помощи svnadmin делает дамп всего репозитория и кидает копию на бекап сервер. «А если что-то где пойдет не так?» Сделав правильные выводы из «истории номер раз» Админ добавляет логирование, что в такой-то день была забекаплен репозиторий на столько-то байт.
Драма
На самом деле, драмы удалось избежать, но, опять же, повезло, все могло быть существенно хуже. Хотелось сделать второй svn сервер, некую песочницу, чуть позже захотелось на него раз в день накатывать самый свежий дамп. При решении этой задачи Админ выяснил, что файл дампа репозитория, начиная с какого-то дня битый. При этом проверка на размер успешно проходила — все ревизии-то до этой критичной бекапились.
После грозы
В этот раз виноват был svnadmin, который делает полный бекап итерационно, начиная с самой первой ревизии. Какая-то ревизия посередине была битой, svnadmin доходил до нее, ломался, честно об этом сообщал и уходил в себя. Начиная отсюда всех подробностей, к сожалению, не знаю, но они нам не очень-то и важны. Починить ревизию не было возможности, удалить ее тоже не было возможности (не знаю, кстати, опять же, как обстоят дела с этим в свежих версиях subversion'а). Поэтому было принято командирское решение переносить гигантский репозиторий на песочницу ежедневно, используя rsync.
Здесь надо подводить итоги
Что я хотел этим всем сказать? То, что лично мне кажется, очень трудно автоматизировать процесс принятия решения о том, что бекап прошел успешно. Т.е. успешно он, допустим, и прошел, а вот как не разворачивая этот бекап проверить, что в нем данные все правильные и актуальные? И, например, новые данные, спустя какое-то время не начнут ломать сам процесс бекапа? Причем, ошибки, приводящие к этому могут быть стары как мир:
- Человеческий фактор
- Ненадежность тулзов
- Ошибки в логике проверок
- проч.
Лично я не знаю ответы на вопросы озвученные выше. Если уважаемый хабр в курсе, прощу поделиться опытом.
А пока что я уже очень давно считаю, что принцип «сделал и забыл», по крайней мере, в случае проведения бекапов, не работает. И советую разворачивать бекап целиком на отдельно стоящем тестовом сервере, если есть такая возможность (здесь мы убиваем двух зайцев ценой времени написания разворачиволки бекапа). Или же писать отдельный скрипт проверки целостности бекапов. Проверять нужно:
- дату создания бекапа
- размер файла
- изменение размера файла относительно предыдущего бекапа
- список файлов в бекапе (или хотя бы количество уникальных)
- … и всю эту информацию засылать аккумулирующим письмом в почту раз в сутки.
Спасибо за внимание.
UPD Спасибо за карму => перенес в блог «системной администрирование».
