Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 74
Сочувствую Вам, вы стали очередной жертвой закона бутерброда.
В разных ситуациях используем разные средства, в некоторых случаях бекапы грузится на другой сервер, в некоторых на другой винчестер, а иногда для бекапов используется Dropbox.
В разных ситуациях используем разные средства, в некоторых случаях бекапы грузится на другой сервер, в некоторых на другой винчестер, а иногда для бекапов используется Dropbox.
Хотя нет, в Вашем случае скорее применим Закон Мёрфи :)
> P.S. Напишите в коментах, какие средства вы используете для резервного копирования?
для базы лучше всего делать тупо дамп средствами MySQL, жать его и хранить как есть. последующие бэкапы — это по сути диффы от начального состояния. раз, например, в неделю делать полный бэкап (и последующие ежедневные диффы уже от него).
файлы — аналогично. для файлов кстати, если они в основном текстовые (вебсайты например) может быть лучше подойдет использование VCS (с бэкапом его конечно же).
для базы лучше всего делать тупо дамп средствами MySQL, жать его и хранить как есть. последующие бэкапы — это по сути диффы от начального состояния. раз, например, в неделю делать полный бэкап (и последующие ежедневные диффы уже от него).
файлы — аналогично. для файлов кстати, если они в основном текстовые (вебсайты например) может быть лучше подойдет использование VCS (с бэкапом его конечно же).
База да, согласен, после этого случая я примерно так и сделал.
Файлу не так актуальны, т.к. итак есть несколько копий у разработчиков и под версиями. Хотя… пойду-ка я проверю как у меня там.
Файлу не так актуальны, т.к. итак есть несколько копий у разработчиков и под версиями. Хотя… пойду-ка я проверю как у меня там.
Эту процедуру очень украшает много ядерный процессор.
База крутится на сервере с 2 4-х ядерными ксеонами, архив сразу пакуется в gzip, причем в темпе 200Мб/c.
После взятия архива мен отправляется письмо: " Резервная копия сделана, порядок ".
4 раза в сутки rsnapshot с бекап сервера забирает резервные копии важных файлов, дамы базы данных и.т.д.
По результату мне сваливается письмо в почту с похожим содержанием.
Просматривая почту проверяю наличие свежих отчетов и сильно не переживаю.
Раз в 3 месяца на тестовой машине проводится репитиция восстановления из бекапа.
База крутится на сервере с 2 4-х ядерными ксеонами, архив сразу пакуется в gzip, причем в темпе 200Мб/c.
После взятия архива мен отправляется письмо: " Резервная копия сделана, порядок ".
4 раза в сутки rsnapshot с бекап сервера забирает резервные копии важных файлов, дамы базы данных и.т.д.
По результату мне сваливается письмо в почту с похожим содержанием.
Просматривая почту проверяю наличие свежих отчетов и сильно не переживаю.
Раз в 3 месяца на тестовой машине проводится репитиция восстановления из бекапа.
бэкапы кстати (если они действительно важны) лучше хранить в двух и более удаленных друг от друга местах (локальный сервер, винт с еженедельными бэкапами в сейфе, месячный архив в криптоконтейнере на удаленном сервере, etc)
Это все понятно, но в моем случае ставка делалась именно на HP. Они кстати и правда не понимают как такое могло случиться.
К тому же дывает так, что данные не должны покидать серверную. Ну и представьте что основное устройство, контролирующее все процессы накрылось. Данные скорее всего целехоньки, вот только попробуй их достань теперь.
К тому же дывает так, что данные не должны покидать серверную. Ну и представьте что основное устройство, контролирующее все процессы накрылось. Данные скорее всего целехоньки, вот только попробуй их достань теперь.
> К тому же дывает так, что данные не должны покидать серверную.
а если пожар в серверной? как минимум тогда хотя-бы нужно регулярно скидывать бэкапы на переносной винт/ленты и хранить его в сейфе у начальника.
> Ну и представьте что основное устройство, контролирующее все процессы накрылось. Данные скорее всего целехоньки, вот только попробуй их достань теперь.
напомнило ситуацию с накрывшимся аппаратным RAID контроллером (из тех что хранят служебные данные во встроенной флешке). данные фактически есть на винтах, но их хрен восстановишь.
а если пожар в серверной? как минимум тогда хотя-бы нужно регулярно скидывать бэкапы на переносной винт/ленты и хранить его в сейфе у начальника.
> Ну и представьте что основное устройство, контролирующее все процессы накрылось. Данные скорее всего целехоньки, вот только попробуй их достань теперь.
напомнило ситуацию с накрывшимся аппаратным RAID контроллером (из тех что хранят служебные данные во встроенной флешке). данные фактически есть на винтах, но их хрен восстановишь.
А я никогда не бэкаплю что-то отдельно, целиком жесткий диск. Места всегда хватает, если использовать Incremental backup, который по сути в случае бэкапа добавляет только те данные, которые изменились. Юзаю Acronis True Image.
Т.к. все это делается на бинарном уровне, то вопрос появления вопросиков просто исключен.
Т.к. все это делается на бинарном уровне, то вопрос появления вопросиков просто исключен.
LVM-снапшоты.
Как я вас понимаю, у меня вот тут в пятницу рухнула система вся на серваке, а конкретно винт с виндой и файлохранилищем, абсолютно неожиданно, просто взяло все и рухнуло. Винт полетел, с трудом получилось восстановить файло. Бекапы системы не делалось оооочень давно, единственный бекап был двухгодичной давности с которого я и восстановил систему, щас вот сижу все привожу к нужному виду. Делайте бекапы всегда и всего что очень важно! Не ленитесь! Проверяйте состояние резервного копирования! Делайте копии ваших бекапов на другие носители!
рейда не было, как я понимаю?
Не следует смешивать отказоустойчивость дисковой подсистемы (raid 1|5|6), бэкапы (копии файлов, образы систем, дампы баз, etc.) и архивирование (ленточные накопители, отдельный сервер в удаленном ДЦ, etc.) в одну кучу, это три разных составляющих доступности данных.
Не следует смешивать отказоустойчивость дисковой подсистемы (raid 1|5|6), бэкапы (копии файлов, образы систем, дампы баз, etc.) и архивирование (ленточные накопители, отдельный сервер в удаленном ДЦ, etc.) в одну кучу, это три разных составляющих доступности данных.
Да я и не сравниваю вовсе, я рассказал о своей проблеме и о том, что я не снимал периодически образы системы, а сейчас мне предстоит настроить много чего заново, а если бы я снимал периодически образы системы, то я бы не сидел бы щас на работе и не выходил бы завтра на работу и в понедельник мне предстоит настраивать пользовательские компы когда они выйдут на работу.
А как же RAID?
Была ночь и я, без надежды на успех, написал в аську супорту Novosoft
У Novosoft 24/7 поддержка через ICQ? О_о
Я для бэкапов информации с компьютера использую DropBox.com, SugarSync.com, а для сайтов и всей остальной онлайн жизни (почты, твиттера, фоток) — Backupify.com
cp
Один из этапов тестирования продукта у нас это тестирование бекапов при полной физической потере рабочих данных (датацентр с рабочими серверами взорвался:) ).
Берется человек, который ничего не знает о системе.
Ему даются ссылки на документацию по развертыванию системы, развертыванию бекапов. Запрещается общаться с админами которые систему админят и программистами которые систему программят. Он выставляет требования для восстановления: сервера, оси. Мы сетапим сервера. После сетапа замеряем сколько времени потребовалось для процедуры восстановления и удалась ли она вообще.
Если не удалась — определяем в чем дело — доки, отсутствие компонент и т.д.
В зависимости от нагруженности проекта, мы сервера держим либо в VZ-контейнерах на наших фермах, либо на выделенных серверах.
Соответственно бекапим сами контейнеры. Мускуль бекапим через репликацию: мастер -> слейв и со слейва уже либо пофайлово либо дамп.
Берется человек, который ничего не знает о системе.
Ему даются ссылки на документацию по развертыванию системы, развертыванию бекапов. Запрещается общаться с админами которые систему админят и программистами которые систему программят. Он выставляет требования для восстановления: сервера, оси. Мы сетапим сервера. После сетапа замеряем сколько времени потребовалось для процедуры восстановления и удалась ли она вообще.
Если не удалась — определяем в чем дело — доки, отсутствие компонент и т.д.
В зависимости от нагруженности проекта, мы сервера держим либо в VZ-контейнерах на наших фермах, либо на выделенных серверах.
Соответственно бекапим сами контейнеры. Мускуль бекапим через репликацию: мастер -> слейв и со слейва уже либо пофайлово либо дамп.
По моему очень профессиональный подход!
Если бы вы были моим сисадмином я бы на вас молился!
Если бы вы были моим сисадмином я бы на вас молился!
Читал комменты и думал: «неужели никто не предложит тестировать бэкапы хотя бы после первого создания и серьёзных изменений». Сам так жестоко («человек, который ничего не знает», «запрещается общаться с админами» и т. п.) не тестировал, но уж на виртуалке прогнать полный цикл восстановления после «взрыва датацентра» обязан, по-моему, любой, кто процедуру резервного копирования организовал.
Конечно, общаться мы напрямую не запрещаем. Это лишь моделирование ситуации.
Все знают о программисте, которого переехал автобус. Сисадминов почему-то все считают автобусоупорными :)
Одно из моих правил построения бизнеса — бизнес должен выживать при 100%-й ротации персонала. Лучше заранее заложить 10% времени на подобные риски, чем потом бегать с голой задницей. Спасало неоднократно.
Даже если у вас остались программисты, которые писали проект при падении системы, мало того, что вы тратите время(деньги) на восстановление, так еще и отвлекаете программистов (тратите деньги) на консультации. Если систему писали год назад, то им прийдется порядком пить кофе и вспоминать что же они там накодили.
Все знают о программисте, которого переехал автобус. Сисадминов почему-то все считают автобусоупорными :)
Одно из моих правил построения бизнеса — бизнес должен выживать при 100%-й ротации персонала. Лучше заранее заложить 10% времени на подобные риски, чем потом бегать с голой задницей. Спасало неоднократно.
Даже если у вас остались программисты, которые писали проект при падении системы, мало того, что вы тратите время(деньги) на восстановление, так еще и отвлекаете программистов (тратите деньги) на консультации. Если систему писали год назад, то им прийдется порядком пить кофе и вспоминать что же они там накодили.
>бизнес должен выживать при 100%-й ротации персонала.
Надо будет запомнить, а то «незаменимых людей нет» как-то приелось, а некоторые ещё и обижаются :) Правильный подход, конечно, но в моем случае избыточный — без меня мои данные и восстанавливать некому будет.
Но раз уж я решил делать бэкапы, то время от времени проверяю, а смогу ли я из них восстановить всё что нужно с нуля. Я в виртуалке имитирую ситуацию «старый комп упал, причём со стола упал, и куплен новый». Часто обнаруживается, кстати, при таком подходе (это не для вас, а для читателей и автора топика, а отдельный коммент не хочется писать), что в первоначальной стратегии резервного копирования что-то упущено (конфиги сервера БД, например) или копируется не полностью (данные есть, а их структуры или хранимых процедур нет)
Надо будет запомнить, а то «незаменимых людей нет» как-то приелось, а некоторые ещё и обижаются :) Правильный подход, конечно, но в моем случае избыточный — без меня мои данные и восстанавливать некому будет.
Но раз уж я решил делать бэкапы, то время от времени проверяю, а смогу ли я из них восстановить всё что нужно с нуля. Я в виртуалке имитирую ситуацию «старый комп упал, причём со стола упал, и куплен новый». Часто обнаруживается, кстати, при таком подходе (это не для вас, а для читателей и автора топика, а отдельный коммент не хочется писать), что в первоначальной стратегии резервного копирования что-то упущено (конфиги сервера БД, например) или копируется не полностью (данные есть, а их структуры или хранимых процедур нет)
> Если систему писали год назад, то им прийдется порядком пить кофе и вспоминать что же они там накодили.
Поэтому я всегда говорил — код надо документировать, а в идеале документировать комментами в коде, и свн вести, с подробным описаловом изменений.
И сам с некоторых пор стал документировать все настройки, которые делаю. Не то, чтоб под автобус собрался, но порой напрочь забываешь через несколько месяцев что и где ты нагуглил. Хоть конфиги и бэкаплю, но все-таки…
Поэтому я всегда говорил — код надо документировать, а в идеале документировать комментами в коде, и свн вести, с подробным описаловом изменений.
И сам с некоторых пор стал документировать все настройки, которые делаю. Не то, чтоб под автобус собрался, но порой напрочь забываешь через несколько месяцев что и где ты нагуглил. Хоть конфиги и бэкаплю, но все-таки…
Да уж, бэкапы тема такая. В свое время поимел кучу батхерта из-за повреждения базы сервера ленточной библиотеки. К счастью рекавери план предусматривал копирование базы на ленты.
Дочь сказала на картинку: «Мальчик утонул в ванне...»
:-D
:-D
Поздравляю от души. Вы реально молодец, и люди, которые с вами работают должны гордиться знакомством с вами! Вам может показаться, что слишком сильно похвалил… Но я помню себя в такой ситуации, помню своих коллег и знаю, очень был большой соблазн — «а ну их нафиг, с их данными», а вы их сохранили, и все работает как прежде. Спасибо, за честное отношение к работе и поднятие имиджа нашей профессии!
Вы идиот? Признайтесь честно. Сис админа был бы нафиг не нужен никому ВООБЩЕ, если бы не давал гарантию на целостность аппаратно-информационной структуры. Автор не гений и не Боярский, просто записки эникея, о том: «Вот я второй месяц на должности сис админа», любой вменяемый человек тестирует свои бэкапы, ЛЮБОЙ!
А я не в должности сисадмина. Да и «записки» совсем не об этом и не для таких НЕэникеев как вы. Я написал этот топик для того, чтоб помочь кому-то научиться на моих ошибках.
Очень редко встречаешь людей, которые любят свою работу и своих клиентов. Я не сисадмин, я занимаюсь софтом, но почему вы так негативно отзываетесь на опыт молодых (и зацените, честных, заинтересованных в работе) сотрудников в своей же отрасли? Они работают так, чтобы вам за профессию стыдно не было… Пожалуйста, бросайте негатив, не знаю куда, дайте людям работать в удовольствие… и поддерживайте их.
«Я занимаюсь софтом» — понятно. Почему я так отзываюсь? Потому что: "(и зацените, честных, заинтересованных в работе)" и «Быстренько сделав задачу на бэкап и настроив уведомления я забыл об этом на полгода.» — взаимоисключающие понятия, как видите все просто.
Блин. Ну нельзя понять на самом деле что ты делаешь на работе, не попробовав кого-то этому научить. И дай тебе бог, если тебе на работу придет такой стажер как автор статьи — ты его на ура всему научишь. А если реально дерево придет, что ты будешь делать, как ты ему обяснять будешь что и почему делать надо?
А «быстренько настроил бэкап и уведомления» через пару лет придут к другой стороне — клиент захочет кнопочку Backup на рабочем столе иметь, плюс уведомление по почте. А работает клиент на MS Windows. И где вы в этот момент со своими специальными знаниями по юникс и не желанием общаться с людьми окажетесь?
очень удобно по крону сливать дампы на Amazon R3. у нас хостинг аккаунты пакуются и каждую ночь льются туда, где-то 3ГБ за ночь. денег в месяц получается в районе 15 баксов всего.
А у нас свой скрипт, который сливает по ночам бэкапы на яндекс.диск. ) Там 10 гигов бесплатного места.
Поздравляю. Вы очередной человек, попавшийся на удочку «а какое бы ПО мне сегодня заюзать в продакшене для вполне себе обычной задачи».
Ошибка раз — не использовали стандартный Mysql клиент (вот только не говорите, что под рукой не было VDSки с самым примитивным Linux, который пускал бы этот скрипт в bash'e).
Ошибка два — вы не использовали стандартный Mysql клиент
Ошибка три — …
Поверьте, приложение, которое годами затачивалось под определенную задачу всегда будет работать лучше аналогичного кусочка из адского комбайна. Добро пожаловать, в мир идеологии UNIX, где всё очевидно и просто.
Ошибка раз — не использовали стандартный Mysql клиент (вот только не говорите, что под рукой не было VDSки с самым примитивным Linux, который пускал бы этот скрипт в bash'e).
Ошибка два — вы не использовали стандартный Mysql клиент
Ошибка три — …
Поверьте, приложение, которое годами затачивалось под определенную задачу всегда будет работать лучше аналогичного кусочка из адского комбайна. Добро пожаловать, в мир идеологии UNIX, где всё очевидно и просто.
Это злой рок — вы только в начале пути. У нас это уже было несколько раз и каждый раз мы пытались обезопасить себя новыми способами — но случалось именно то, что наносило наибольший урон.
Жизнь админа это кошмар — но тот кто остается и разгребает все и должен зваться админом.
Жизнь админа это кошмар — но тот кто остается и разгребает все и должен зваться админом.
> P.S. Напишите в коментах, какие средства вы используете для резервного копирования?
Базы данных — стандартными средствами самих баз данных. Попросту говоря — дамплю, потом гзипую, и на сторэдж, который зеркалируется. На мой взгяд ничего лучше еще не придумано.
1С обычной выгрузкой по расписанию, и тоже на сторэдж зеркальный. Может умнее было бы дампить МСсикульную базу, но насколько я в курсе, там проблемы с восстановлением, 1С без бубна видеть восстановленную базу не будет, так что выгрузка проще, да и бывает нужно поднять локально, на определенную дату.
А для файлов — Symantec Backup Exec, очень приличное решение, только один минус — не умеет он никсовые фс ставить на континюс протекшн. За сим пришлось поднимать ФриНАС и цеплять его к к винде по iSCSI. Итого я получаю постоянный текущий бэкап и возможность восстановления на 64(если память не подводит) шага назад, с указанным временным промежутком. При этом скоращаю свое вмешательство, т.к. пользователь сам может восстановить свои файлы по версиям, если случайно накосячил =)
Базы данных — стандартными средствами самих баз данных. Попросту говоря — дамплю, потом гзипую, и на сторэдж, который зеркалируется. На мой взгяд ничего лучше еще не придумано.
1С обычной выгрузкой по расписанию, и тоже на сторэдж зеркальный. Может умнее было бы дампить МСсикульную базу, но насколько я в курсе, там проблемы с восстановлением, 1С без бубна видеть восстановленную базу не будет, так что выгрузка проще, да и бывает нужно поднять локально, на определенную дату.
А для файлов — Symantec Backup Exec, очень приличное решение, только один минус — не умеет он никсовые фс ставить на континюс протекшн. За сим пришлось поднимать ФриНАС и цеплять его к к винде по iSCSI. Итого я получаю постоянный текущий бэкап и возможность восстановления на 64(если память не подводит) шага назад, с указанным временным промежутком. При этом скоращаю свое вмешательство, т.к. пользователь сам может восстановить свои файлы по версиям, если случайно накосячил =)
давным давно, когда я был маленьким и бедным, бакапы я делал так:
a=`date +%Y-%m-%d-`user_database.sql
mysqldump -uuser_database -pdb_pass -hmysql_server user_database > $a && gzip $a
echo «this is user_database database dump» | mutt shakirov@gmail.com -a $a.gz -s «database backup „$a
т.е. делал дампы по крону и отправлял их на gmail. штука эта работала на шаред хостинге обыкновенном.
a=`date +%Y-%m-%d-`user_database.sql
mysqldump -uuser_database -pdb_pass -hmysql_server user_database > $a && gzip $a
echo «this is user_database database dump» | mutt shakirov@gmail.com -a $a.gz -s «database backup „$a
т.е. делал дампы по крону и отправлял их на gmail. штука эта работала на шаред хостинге обыкновенном.
Поздравляю, вы совершили почти все мыслимые ошибки при защите данных, которые можно было совершить.
У вас есть шанс запомниь этот случай, и больше никогда так не делать.
Впрочем, увы, наивно было бы думать, что ваш опыт хоть кого-то чему-то научит. «История учит, что она ничему не учит».
У вас есть шанс запомниь этот случай, и больше никогда так не делать.
Впрочем, увы, наивно было бы думать, что ваш опыт хоть кого-то чему-то научит. «История учит, что она ничему не учит».
Важно не то, как ты делаешь бекап.
Важно, можешь ли ты сделать restore.
Важно, можешь ли ты сделать restore.
напомнило это
xmages.net/storage/10/1/0/5/2/upload/159fc15c.jpg
xmages.net/storage/10/1/0/5/2/upload/159fc15c.jpg
Я согласен с Rostik и другими комментаторами выше — ошибка в том, что вы ни разу не пробовали восстановить данные раньше, чем это реально понадобилось. Как писал Джоел Спольский, Let’s stop asking people if they’re doing backups, and start asking if they’re doing restores.Let’s stop asking people if they’re doing backups, and start asking if they’re doing restores.
Дык никтож и не спорит. Более того, я и раньше это знал. Надо было сделать срочно, а работы и без того была масса. Вот я и пишу для того, чтоб другие так не делали.
Да я и Handy Backup недаром вспомнил. Сколько он уже существует, а такой простой баг до сих пор есть. Это говорит о том, что за все это время никто не обращался с проблемой, а возможно мало у кого доходило до реального восстановления. Пусть не все его юзают, но всеже программа популярна.
Да я и Handy Backup недаром вспомнил. Сколько он уже существует, а такой простой баг до сих пор есть. Это говорит о том, что за все это время никто не обращался с проблемой, а возможно мало у кого доходило до реального восстановления. Пусть не все его юзают, но всеже программа популярна.
1 бэкап файлов раз в месяц (24 бэкапа), 1 раз в неделю (4 бэкапа), 1 раз в день (24 бэкапа). Все с ротацией — при достижении макс. кол-ва файлов, все пишется в файл №1, потом в файл №2 и т.д.
С базой тоже самое, но еще идет репликация в другой ДЦ. Из-за репликации появляется возможность восстановить сайт за 5-10 минут на другом сервере. DNS переключается моментально из-за маленького TTL (юзаем платный DynDNS).
Все это дело бэкапится в 5 точек, находящихся в разных концах Москвы.
Когда-то бэкап шел на другой сервер в том же датацентре. Но скачек напряжения, вырубивший оба сервера, заставил пересмотреть подход к бэкапу.
Все на Perl + Shell.
Ах да, еще файлы хранятся в SVN, который имеет зеркало.
Осталось настроить отчеты и сделать страничку с общей статистикой.
С базой тоже самое, но еще идет репликация в другой ДЦ. Из-за репликации появляется возможность восстановить сайт за 5-10 минут на другом сервере. DNS переключается моментально из-за маленького TTL (юзаем платный DynDNS).
Все это дело бэкапится в 5 точек, находящихся в разных концах Москвы.
Когда-то бэкап шел на другой сервер в том же датацентре. Но скачек напряжения, вырубивший оба сервера, заставил пересмотреть подход к бэкапу.
Все на Perl + Shell.
Ах да, еще файлы хранятся в SVN, который имеет зеркало.
Осталось настроить отчеты и сделать страничку с общей статистикой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Горький опыт, резервное копирование и качественная техподдержка