Не используешь резервное копирование — вон из профессии
При обсуждении полезных для аутсорсинговых компаний ИТ-технологий регулярно возникает тема резервного копирования. Резервное копирование — штука полезная, однако для ИТ-профессионала — это must have. Вопрос не о необходимости, а о предпочтениях. Можно спорить какая технология резервного копирования лучше и удобнее, однако, если для критически важных данных не используется какая-либо технология, пусть даже это копирование файлов при помощи проводника на внешний usb-диск — тебе нет места в профессии.
Как и предыдущие технологии, резервное копирование клиенту не нужно. Ему и платить то за него не обязательно. Пока все идет хорошо — он о нем не вспомнит. Как только что-то пойдет не так, то, что там, в договоре написано про восстановление работы систем?
Хотите потерять клиента и получить множество негативных отзывов? Расскажите клиенту, после инцидента, что вы восстановили работу бухгалтерии, но вот данные из нее пропали, т.к. вы не занимаетесь резервным копированием.
И наоборот, самая большая благодарность к ИТ возникает, когда оказывается, что можно восстановить случайно удаленный файл. Технологий обеспечивающих резервное копирование очень много. Ограничусь ссылкой на далеко не полный список в Википедии.
Дисковое пространство дешевеет с каждым годом. В домашних архивах пользователей вполне привычны терабайтные внешние диски, тем более компании могут себе позволить подобные решения. Многим компаниям вполне достаточно даже DVD-R дисков.
При организации резервного копирования следует обращать внимание на то, что часть пользовательских данных обновляется очень часто, а часть довольно редко. Если для корпоративного веб-сайта вполне подходит резервный DVD-R диск, то для пользовательских документов или бухгалтерского решения лучше все же применять что-то более автоматизированное и регулярное.
Стоит также отметить облачные хранилища. Их стоимость также не запредельна, зато позволяет обеспечить географическую удаленность резервной копии. Печальный опыт WTC показал, что хранить резервные копии нужно вдали от основной инфраструктуры, поскольку иногда происходит такое маловероятное событие, как попадание двух самолетов в два рядом стоящих задние.
Дополнительные материалы
Комментарии (20)
КомментироватьБояринцев Кирилл [solaris34], 23 ноября 2010, 18:33
"Расскажите клиенту, после инцидента, что вы восстановили работу бухгалтерии".
Очень верный пример. Заботясь об отказоустойчивости ИТ-сервисов некоторые периодически забывают, что для работы этих сервисов необходимы исходные данные. Поэтому, фактически, можно рассматривать резервное копирование данных, как обеспечение отказоустойчивости сервиса к которому они относятся.
Савчук Виктор [TigerS], 23 ноября 2010, 23:20
Клиент два визита распинался о необходимости архивирования документов/программ. Наверное надеялся, что я как телепат САМ разберусь, что для него важно.
Я предоставил бланк на каждый ПК. С единственным условием - что еще (какие паки/проги) кроме Рабочего стола и Моих документов подлежит архивированию..... энтузиазм как то сам собою сошел на нет.
Нет. Я конечно бОльшую часть ПО и сам догадаюсь забэкапить (хоть по ярлыкам на раб.столе...), но хочется взаимной ответсвенности за принятые решения.
Я прав?
Key Iten [inggvar], 24 ноября 2010, 09:13
Савчук Виктор [TigerS], 24 ноября 2010, 21:09
Так бэкап и продаем (в перечне прочих услуг). Но вопрос то остался - я сам должен ДОГАДЫВАТЬСЯ, что у клиента считается важной информацией? Особенно весело, когда работаешь с полиграфистами/дизайнерами. У них бэкапы - гиги и гиги. Соответственно время бэкапа (т.е. нагрузка на машину) весьма заметны.
Ночное время бэкапа не годится, т.к. по ночам ПК и рубильник питания включены далеко не у всех.
Яковлев Андрей Михайлович [swtws], 24 ноября 2010, 09:46
P.S. Вот что такое план аварийного восстановления объяснить труднее, а ведь тоже must have
Рубинштейн Кирилл [krubinshteyn], 24 ноября 2010, 11:13
Вопрос только к том, что нужны правильные руки и головы, чтобы в этом всем разобраться.
Савчук Виктор [TigerS], 24 ноября 2010, 21:14
А действительно... мы ведь обсуждаем малый бизнес :)
Какие уж там сотни ПК?
---Вся важная информация хранится либо в СВНе, либо в общих папках отделов
Аналогично выше. Выделенная машина у клиента есть далеко не всегда. :(
Мосолов Дмитрий [Cookie], 24 ноября 2010, 22:13
А не пробовали рассматривать как решение для бекапа такую экзотику для России, как Windows Home Server?
Я внедрял. Рекомендую.
Горошко Дмитрий [goroshko], 05 декабря 2010, 00:32
Ураев Алексей Витальевич [AlexR], 25 ноября 2010, 12:57
Бычков Валерий [vbychkov], 25 ноября 2010, 13:34
Ураев Алексей Витальевич [AlexR], 25 ноября 2010, 18:22
Горошко Дмитрий [goroshko], 10 декабря 2010, 01:08
Бычков Валерий [vbychkov], 10 декабря 2010, 06:07
Яковлев Андрей Михайлович [swtws], 29 августа 2011, 13:13
Беда в том, что в даже в средней компании ИТ директора нет и контролировать админа некому. Директор лесопилки в лесе разбирается, а в ИТ - нет. Я смеха ради держу на hh.ru три резюме, менеджера, специалиста и специалиста на английском. И все ищут специалиста. А я падаю, специалист политики разрабатывать будет?
Горошко Дмитрий [goroshko], 29 августа 2011, 18:30
Яковлев Андрей Михайлович [swtws], 29 августа 2011, 23:52
Вы не подскажете, какая компания сможет внедрить СУИБ в соответствии с ISO 27001 и почем в компании с 3-мя офисами и 150 компьютерами? Регламент бэкапов вообще в стандарт входит, но его можно и отдельно сделать.
Да еще, что Вы понимаете под "информационной безопасностью"?
Рубинштейн Кирилл [krubinshteyn], 29 августа 2011, 12:50
Дешево и вкусно.
[bhavenger], 13 октября 2014, 09:11
Кирилюк Иван [Qwerty], 21 октября 2014, 10:36
Кирилл, я на вебинаре по ITSM 365 упоминал про то, что облакам (имеется в иду не родным) критичные для компании данные доверять нельзя.
мне сообщили, что и Интернету доверять нельзя и вообще вопрос в цене.
в связи с заявлением про бэкапы Смартсорсинга, стало любопытно - а ITSM 365 случайно в Дропбокс какой-нибудь не бэкапится?
а то клиентам было бы здорово узнать, что их данные "дешево и вкусно" в публичное облако складываются в виде бэкапов.