Комментарии 20
Всё это от большого ума и отношения.
В нашей конторке бэкапы делаются каждый день уже 5 лет.
Понадобилось толлько 2 раза, да и н для восстановления, а для просмотра истории изменений.
Если сделано с умом — бэкапы и не нужны.
В нашей конторке бэкапы делаются каждый день уже 5 лет.
Понадобилось толлько 2 раза, да и н для восстановления, а для просмотра истории изменений.
Если сделано с умом — бэкапы и не нужны.
Если сделано с умом… А делают с умом, зачастую, только после того как «обожглись». Поэтому все-таки нужны.
Одно дело забекапить конторку, другое дело — забекапить 500 петабайт. В конторках как раз часто всё сделано по уму и с 5кратной надёжностью — если админ журналы читает. Когда у меня объём сберегаемых данных перевалил за 6Тб, бюджет сказал "нужно больше золота", и пришлось тоже ухудшать качество бекапов.
Это есть такая проблема. Но изворотливость ума никуда не делась. Года 4 назад надо было в одном видео проекте 3 дня бэкапы хранить — сделал из домашних компьютеров VPN и RSync пузырил c 2-мя дубликатами. Один раз пришлось восстанавливать — не быстро, но ролики клоунов из театра Дуровой (это реальные люди http://teatrium.ru/theater/creative-team/troup) не потерялись. Так что всё зависит от прослойки между клавиатурой и стулом.
Ох… 6Тб — это еще немного. Вот когда только продуктив который надо бэкапить с частотой 15 минут, выходит за 35-40Тб, вот тогда и начинается самое интересное.
Свежее: поломалася новый HP 3Par у налоговой в Австралии.
Корраптнутые данные успели залиться в реплику.
Регулярные снепшоты массива видимо настроить «не успели еще пока». Или «места жалко», ведь есть реплика и ленты =)))
Результат — потеря 1PB.
http://www.itnews.com.au/news/hpe-storage-crash-killed-ato-online-services-444490
http://www.storagenewsletter.com/rubriques/systems-raid-nas-san/failure-of-hpe-3par-storeserve-san-2/
Корраптнутые данные успели залиться в реплику.
Регулярные снепшоты массива видимо настроить «не успели еще пока». Или «места жалко», ведь есть реплика и ленты =)))
Результат — потеря 1PB.
http://www.itnews.com.au/news/hpe-storage-crash-killed-ato-online-services-444490
http://www.storagenewsletter.com/rubriques/systems-raid-nas-san/failure-of-hpe-3par-storeserve-san-2/
НЛО прилетело и опубликовало эту надпись здесь
В 2007 написал свою программу dirsync — легкая и простая (ну и для меня удобная — сам написал). Бэкаплю критичные данные раз в сутки, некритичные — 2 раза в неделю. Неоднократно восстанавливался. Не понимаю, как без бэкапов можно жить. Тем более на продакшене.
НЛО прилетело и опубликовало эту надпись здесь
Всё-таки «утечка данных» и «потеря данных» — кейсы совершенно разные, местами даже взаимоисключающие, (примерно как пожарники и охрана в вопросе решёток и дверей).
НЛО прилетело и опубликовало эту надпись здесь
Админы делятся на
1. Тех кто еще не делает бэкапы
2. Тех кто УЖЕ делает бэкапы
3. Тех кто УЖЕ проверяет бэкапы на валидность
Вот только у третьего пункта можно говорить, что бэкапы существуют.
Я так недавно принимал нового клиента. Полез проверять бэкапы настроенные прежними аутсорсерами, а там не бэкапы, а полная белибердень нечитаемая. Попросил информацию когда последний раз бэкапы проверялись, получил от прежнего аутсорсера ответ: «Никогда, нам не нужно проверять бэкапы настроенные сотрудниками, они у нас идеальны».
1. Тех кто еще не делает бэкапы
2. Тех кто УЖЕ делает бэкапы
3. Тех кто УЖЕ проверяет бэкапы на валидность
Вот только у третьего пункта можно говорить, что бэкапы существуют.
Я так недавно принимал нового клиента. Полез проверять бэкапы настроенные прежними аутсорсерами, а там не бэкапы, а полная белибердень нечитаемая. Попросил информацию когда последний раз бэкапы проверялись, получил от прежнего аутсорсера ответ: «Никогда, нам не нужно проверять бэкапы настроенные сотрудниками, они у нас идеальны».
«3. Тех кто УЖЕ проверяет бэкапы на валидность», — не знал, что без этого можно жить. Кто же эти админы, которые не проверяют бэкапы? У Oracle, например, есть стандартные средства rman-ские для проверки резервных копий после выполнения бэкапа. Всегда логи их выполнения анализирую.
Ну я выше привел пример из буквально недавнего своего опыта. Достаточно крупная российская фирма берущая на аутсорс чужие сервера не проверяла вообще настроенные бэкапы, а на вопрос о проверке заявила, что им в этом нет необходимости, потому что у них все всегда идеально.
При этом косяк там был прекрасный, они не проверяли реальное место на подмонтированной для сохранения бэкапа внешней точке даваемой хостером, хостер дает 100 гигов, но при монтировании в системе оно видится, как 1 террабайт, фигачили на это место при помощи dd lvmный снапшот, а потом уже делали gzip, что бы его пожать. В результате они на реальные 100 гигов якобы записывали 320 гигов, а потом жали то, что системе казалось файлом. Я этот прикол с местом выдаваемым Хецнером под бэкап очень хорошо знаю, что ты можешь писать туда свыше своих 100 гигов, эти данные уходят в космос, хотя система у тебя считает, что она туда что-то записала.
Ну вот как-то так.
При этом косяк там был прекрасный, они не проверяли реальное место на подмонтированной для сохранения бэкапа внешней точке даваемой хостером, хостер дает 100 гигов, но при монтировании в системе оно видится, как 1 террабайт, фигачили на это место при помощи dd lvmный снапшот, а потом уже делали gzip, что бы его пожать. В результате они на реальные 100 гигов якобы записывали 320 гигов, а потом жали то, что системе казалось файлом. Я этот прикол с местом выдаваемым Хецнером под бэкап очень хорошо знаю, что ты можешь писать туда свыше своих 100 гигов, эти данные уходят в космос, хотя система у тебя считает, что она туда что-то записала.
Ну вот как-то так.
Коллеги, раз тут собрались обсуждать бекапы — задам вопрос немного не в тему поста: где можно почитать про аналитику резервного копирования? Какими отчетами пользуются в отрасли, какие зависимости отслеживают. Есть такое что-то?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От факапа до бэкапа: истории ИТ-компаний, потерявших данные