Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Предположим, вероятность потери данных составляет 1% (это неверно, так как мы говорим про уникальное событие, у него нет «вероятности», но, допустим, что в среднем 1 из 100 сталкивается с потерей данных в течение года). Предположим, что цена восстановления данных — неделя работы.
А теперь вопрос: что проще — восстановить данные за неделю или потратить 52 (количество недель) x 100 (обратное к вероятности) x 30 минут=2600 часов=108 дней по 24 часа в сутки или 325 дней по 8 часов в день? Желающие могут подставить свои коэфиценты, но цифры всё равно удручающие.
Предложение делать бэкапы руками и руками же их контролировать — предложение просирать жизнь на контроль того, что, возможно, никогда не случится.
А теперь вопрос: что проще — восстановить данные за неделю или потратить 52 (количество недель) x 100 (обратное к вероятности) x 30 минут=2600 часов=108 дней по 24 часа в сутки или 325 дней по 8 часов в день? Желающие могут подставить свои коэфиценты, но цифры всё равно удручающие.
Предложение делать бэкапы руками и руками же их контролировать — предложение просирать жизнь на контроль того, что, возможно, никогда не случится.
В какое время вы оцените восстановление фотографий вашего ребёнка, сделанных 5 лет назад? Видео со свадьбы?
А восстановление почтового архива?
Или, может, вы сможете за неделю восстановить исходники софта, написанного вами (и на который было потрачено пол года или даже больше времени)?
А реферат/курсовая работа/любые другие документы (на написание которых ушло немало времени)?
Есть масса ситуаций, когда понятие «цена восстановления» теряет смысл, т.к. восстановление возможно только из бекапа.
p.s. Понятно, что архив известных фильмов/распространённой музыки можно заново слить с торрентов.
А восстановление почтового архива?
Или, может, вы сможете за неделю восстановить исходники софта, написанного вами (и на который было потрачено пол года или даже больше времени)?
А реферат/курсовая работа/любые другие документы (на написание которых ушло немало времени)?
Есть масса ситуаций, когда понятие «цена восстановления» теряет смысл, т.к. восстановление возможно только из бекапа.
p.s. Понятно, что архив известных фильмов/распространённой музыки можно заново слить с торрентов.
Исходники софта я восстановлю в течение нескольких секунд. git придуман и для этого, в частности. Ни один реферат и курсовая не стоит 325 дней по 8 часов в день. Фотографии 5-летнего ребёнка — ну, не знаю.
Кроме того, я не возражаю против бэкапов, я против предложения каждый раз делать его вручную и ещё проверять. Дорого это по времени. Дорого, муторно и всё равно не гарантирует восстановимости.
Правильная стратегия, на самом деле, не резервные копии, а хранение на нескольких носителях. Например, почему я так спокоен за софт и прочие репозитории? Потому что они у меня на компьютере, на ноутбуке, на рабочем ноутбуке и на компьютерах у нескольких коллег. Если сервер навернётся — у нас есть копия.
То же касается и большинства других видов информации, связанной со мной — она просто хранится в нескольких экземплярах.
Кроме того, я не возражаю против бэкапов, я против предложения каждый раз делать его вручную и ещё проверять. Дорого это по времени. Дорого, муторно и всё равно не гарантирует восстановимости.
Правильная стратегия, на самом деле, не резервные копии, а хранение на нескольких носителях. Например, почему я так спокоен за софт и прочие репозитории? Потому что они у меня на компьютере, на ноутбуке, на рабочем ноутбуке и на компьютерах у нескольких коллег. Если сервер навернётся — у нас есть копия.
То же касается и большинства других видов информации, связанной со мной — она просто хранится в нескольких экземплярах.
Так хорошая резервная копия и должна храниться на другом носителе. Хранить бэкап в каталоге с файлами действительно мало пользы, на другом разделе винта — уже чуть побольше, спасёт от краха раздела или непродуманных действий, на отдельном винте/флэшке/компе рядом — ещё больше, спасёт от поломки основоного носителя, на другом компе в другой стране (сервере) — практически равнозначно «неубиваемости» данных. Если навернется свой комп, то останется копия на сервере, если сервер — останется на своем компе. Вероятность того, что навернутся одновременно и свой комп, и удаленный сервер пренебрежимо мала.
Резервное копирование и есть сознательное хранение информации минимум в двух экземплярах, а не обусловленное используемой технологией или стечением обстоятельств. Например, само использование git для бэкапов — это лишь аналог хранения архива бэкапа с файлами, нужно использовать внешние репозитории, а не просто git. Кстати, спасибо за идею использовать VCS для бэкапа, а то использовал Mercurial+BitBucket для управления версиями и синхронизации разных компьютеров, а ведь можно и для бэкапов сознательно, благо в отличии от GitHub ни место, ни количество приватных репозиториев на бесплатном аккаунте не ограничено. Пошёл составлять .htignore чтобы хоть видео не сохранялось там, сильно наглеть не надо :)
Резервное копирование и есть сознательное хранение информации минимум в двух экземплярах, а не обусловленное используемой технологией или стечением обстоятельств. Например, само использование git для бэкапов — это лишь аналог хранения архива бэкапа с файлами, нужно использовать внешние репозитории, а не просто git. Кстати, спасибо за идею использовать VCS для бэкапа, а то использовал Mercurial+BitBucket для управления версиями и синхронизации разных компьютеров, а ведь можно и для бэкапов сознательно, благо в отличии от GitHub ни место, ни количество приватных репозиториев на бесплатном аккаунте не ограничено. Пошёл составлять .htignore чтобы хоть видео не сохранялось там, сильно наглеть не надо :)
вы слишком ориентированы на IT работников, а в статье идет речь про среднего домашнего пользователя.
что, возможно, никогда не случитсяБолее того, по закону подлости, вероятность потери данных увеличивается если бэкапов нет, и уменьшается если они есть. Так давайте же делать бэкапы, и пусть они нам никогда не понадобятся! (тост) :)
А вообще Вы фигню написали. Никто ручками бэкапы не делает — один раз настраиваешь что куда бэкапить и по какому расписанию, и забываешь. Так что 325 дней это бред. Далее, «цена восстановления данных — неделя работы» это ещё один бред — как правило цена восстановления данных при отсутствии бэкапов на-амного выше. Цена в неделю работы — это цена для ситуации когда бэкапы уже делаются.
Резервное копирование данных простым языком.
>Backup данных должен быть таким же регулярным, как прием таблеток.
O_o Чуть не упал, когда залез под кат от такого сравнения. Уберите прочь! :) Бэкап это не лечение, это профилактика или вакцинирование! Они предназначены, чтобы минимизировать потери от «болезни».
Делать сравнение с таблетками, это провоцировать мысли: «Я что, больнойтаблетки пить бэкапы делать?». Если уж хочется сравнений близких к медицине то сравнивайте ежедневные инкрементальные бэкапы с чисткой зубов, ежемесячные полные со сменой зубной щётки, а ежегодные проверки с полным разворачиванием архивов с профилактическим визитом к стоматологу.
И, да, резервное копирование должно быть автоматическим. По расписанию и/или при подключении внешнего носителя или к сети. Плюс возможность запустить его вручную перед глобальными изменениями или после создания архиважных документов.
Комменты в топике натолкнули на мысль, что можно использовать VCS (системы контроля версий) и сторонние внешние репозитории для резервного копирования. Рекомендую hg/git в качестве VCS и BitBucket в качестве репозитория — неограниченное место и неограниченное количество приватных репозиториев. Правда настроить это всё для неайтишника будет проблематично без подробного howto. И с шифрованием не получится без костылей типа сначала создание шифрованного архива и уже его пушинг в репозиторий. Но потеряется возможность работы с версиями.
O_o Чуть не упал, когда залез под кат от такого сравнения. Уберите прочь! :) Бэкап это не лечение, это профилактика или вакцинирование! Они предназначены, чтобы минимизировать потери от «болезни».
Делать сравнение с таблетками, это провоцировать мысли: «Я что, больной
И, да, резервное копирование должно быть автоматическим. По расписанию и/или при подключении внешнего носителя или к сети. Плюс возможность запустить его вручную перед глобальными изменениями или после создания архиважных документов.
Комменты в топике натолкнули на мысль, что можно использовать VCS (системы контроля версий) и сторонние внешние репозитории для резервного копирования. Рекомендую hg/git в качестве VCS и BitBucket в качестве репозитория — неограниченное место и неограниченное количество приватных репозиториев. Правда настроить это всё для неайтишника будет проблематично без подробного howto. И с шифрованием не получится без костылей типа сначала создание шифрованного архива и уже его пушинг в репозиторий. Но потеряется возможность работы с версиями.
«Недавно моя подруга попросила объяснить… я решила собрать...»
Таблетки таблеткам рознь. Есть такие которые пьют именно для профлактики. Их нужно пить регулярно. Не выпила — залетела.
Ваш(а) К.О.
Таблетки таблеткам рознь. Есть такие которые пьют именно для профлактики. Их нужно пить регулярно. Не выпила — залетела.
Ваш(а) К.О.
Насчет автоматического резервного копирования, гита, шифрования и прочего. Да, это естественно лучше сделать. Но цель состояла в том, чтобы объяснить человеку не сведущему в IT, что и как он может сделать самостоятельно.
А где же amazon? Бекаплю исключительно на него, очень доволен. Конечно не особо дёшево, но лучше предлагаемых другими компаниями велосипедов.
И бэкап на CD/DVD неплох. У меня инкрементный бэкап за день занимает где-то 40 мегов. Одного диска хватает на полгода.
статья вроде заточена под пользователей win, почему про встроенные средства Windows 7 ничего не упомянуто? не пробовали или не понравилось?
Не понравилось, так как встроенная тула в один прекрасный момент тула начала выдавать ошибку и отказывалась работать. Вот подобная проблема: social.technet.microsoft.com/Forums/en-US/w7itprogeneral/thread/fce6950d-c06d-4dd0-a850-67022db4fe04/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервное копирование данных простым языком