Comments 47
Не увидел в тексте абзаца с описанием как и чем делаются бекапы у автора, а жаль. Тема мне достаточно интересна, так как текущее средство (кобиан бекап) меня не совсем устаревает, в нём не хватает инструментов для сбора всех полных копий, разбиение на размер двд и складирование в одном месте для записи на двд раз в квартал. Подумываю написать самому скрипт, но увы он будет огромный.
ну видимо так тому и быть, сам писал скрипт, по крону запускается, 7зипом архивируется…
Специально не стал указывать чем делаю, т.к. не важно чем — важно как, важны принципы, а софт можно выбирать почти любой, у большинства есть нужный функционал.
если говорить конкртено, то делал (и делаю) самописными скриптами (использовал 7zip и winrar), Symantec Backup Exec (одна из любимых программ) и Symantec System Recovery (после того как она обновилась до 9 версии как софт для системного бэкапа она мне нравится все больше и больше)
но, повторюсь, есть масса других не менее хороших програм, тот же Acronis, DPM, Handy Backup, Comodo и т.д. и т.п.
если говорить конкртено, то делал (и делаю) самописными скриптами (использовал 7zip и winrar), Symantec Backup Exec (одна из любимых программ) и Symantec System Recovery (после того как она обновилась до 9 версии как софт для системного бэкапа она мне нравится все больше и больше)
но, повторюсь, есть масса других не менее хороших програм, тот же Acronis, DPM, Handy Backup, Comodo и т.д. и т.п.
Было бы интересно посмотреть как раз скрипты, платный софт не всегда даже удобней их.
например такой момент — запуск скрипта на стороне клиента или сервера? как лучше.
Имхо, проще так: бэкап клиентского ПК инициируется со стороны клиента, если по какой-то причине бэкап не запустился по расписанию, можно выставить «галочку» на выполнение задания при следующем старте ПК.
По возможности складировать создаваемую копию локально и затем переносить в хранилище.
По возможности складировать создаваемую копию локально и затем переносить в хранилище.
зависит от того что вы бэкапите.
Если это файловые данные — то правильнее стремится к тому, чтобы все важные файлы лежали в сети (соответственно бэкап работает на стороне сервера).
На мой взгляд идеальная ситуация, это когда при поломке рабочей станции пользователь тупо пересаживается на соседнюю, вводит свой логин-пароль и после некоторых первоначальных (автоматических) настроек продолжает работать дальше. тогда на стороне клиента вообще бэкапить ничего не надо.
А если все таки надо (клиент банки, спец-по и т.д.), и бэкапите не специализированным ПО (типа Symantec с его агентами, или тем же DLO) а скриптом, то запускайте на стороне клиента. Так вы убираете лишнее звено (из цепочки «ЗапускСкриптаНаСервере-ОбращениеНаРабСтанцию-КладемБэкапНаСервер» убираются не нужные первых два шага).
И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало.
Если это файловые данные — то правильнее стремится к тому, чтобы все важные файлы лежали в сети (соответственно бэкап работает на стороне сервера).
На мой взгляд идеальная ситуация, это когда при поломке рабочей станции пользователь тупо пересаживается на соседнюю, вводит свой логин-пароль и после некоторых первоначальных (автоматических) настроек продолжает работать дальше. тогда на стороне клиента вообще бэкапить ничего не надо.
А если все таки надо (клиент банки, спец-по и т.д.), и бэкапите не специализированным ПО (типа Symantec с его агентами, или тем же DLO) а скриптом, то запускайте на стороне клиента. Так вы убираете лишнее звено (из цепочки «ЗапускСкриптаНаСервере-ОбращениеНаРабСтанцию-КладемБэкапНаСервер» убираются не нужные первых два шага).
И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало.
«И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало»
используется ли у вас какое-то автоматическое отслеживание таких сообщений?
ведь иногда, бэкап может не просто отработать с ошибкой, а не отработать вообще и/или не прислать отчет — и такие ситуацию явно надо как-то отслеживать не руками. особенно, когда систем несколько.
а как вы управляете расписанием резервного копирования?
например, есть 3 файловых сервера, есть 1 сервер под бэкапы. если изначально настроить расписание из предположения что каждый ФС будет обрабатываться 2 часа, и поставить в расписание их с интервалом в 2,5-3 — в какой-то момент бэкапы могут «наложиться». что либо просто приведет их длительному выполнению, либо к сбою в итоге.
а если бэкап-серверов и источников много — уже явно не получится обойтись простым расписанием «назначенных задач». т.к. нужен и полный список заданий и штатное время выполнения и объем и прочая.
используется ли у вас какое-то автоматическое отслеживание таких сообщений?
ведь иногда, бэкап может не просто отработать с ошибкой, а не отработать вообще и/или не прислать отчет — и такие ситуацию явно надо как-то отслеживать не руками. особенно, когда систем несколько.
а как вы управляете расписанием резервного копирования?
например, есть 3 файловых сервера, есть 1 сервер под бэкапы. если изначально настроить расписание из предположения что каждый ФС будет обрабатываться 2 часа, и поставить в расписание их с интервалом в 2,5-3 — в какой-то момент бэкапы могут «наложиться». что либо просто приведет их длительному выполнению, либо к сбою в итоге.
а если бэкап-серверов и источников много — уже явно не получится обойтись простым расписанием «назначенных задач». т.к. нужен и полный список заданий и штатное время выполнения и объем и прочая.
Из бесплатного под Windows — Cobian Backup. Гибкий и надёжный (нужно только имеющуюся в комплекте библиотеку 7za.dll заменить на свежую).
я в одной из следующих статей расскажу про самописный скрипт для бэкапа. Специально писал что был довольно универсальный, с параметрами и т.п.
А такую систему как Bacula, кто-нибудь использует? Есть положительные впечатления? Лично у меня она неплохо работает, но после Symantec'а как-то не так все, а на этом месте работы не хотят покупать symantec.
Использую, совместно с автоматизированной настройкой клиентов через Puppet.
Используем. Впечатления — только положительные.
а web-интерфейс вы какой используете? или только консоль?
Консоль. Да и та нужна раз в месяц, когда что-нибудь затыкается и надо посмотреть status dir, или когда что-то восстанавливаем.
Только BAT. Сейчас подумал: «Может web-bacula стоит поднять для контроля состояния...» Для управления ИМХО не нужно.
А для управления webacula и не годится, там конечно есть прямой доступ в консоль, но ИМХО он не удобен. Зато посмотреть статистику и общие отчеты можно. Хотя у меня все это льется на почту, поэтому заходить туда возникает необходимость исключительно редко. Хотя и сервис-то не тяжелый так, что это скорее приятное не отягощающее дополнение.
Использую.
Хорошая, годная система.
Хорошая, годная система.
Мне для бэкапа фалов на винде понравился SyncBack Pro (хотя и бесплатная версия вполне функциональна). На FreeBSD самописные скрипты.
а можете про скрипты по подробней?
ну и на tar ещё перешёл)
У нас там система архивов была проста. файловый архив за последние 3 дня хранится в незапакованном виде. затем более поздние файлы ежедневно архивируются. Ну и ежемесячно делается архив этих файлов. А бэкапы делались отдельно системы и отдельно каждой программы. в случае чего поднимается хоть «голая» система и на неё восстанавливаются программы. А в шкафах было еще проще. настроил систему — работает. отзеркалил винт рэйдом. вставил второй сделал копию — вот тебе и бэкап.
Спасибо, очень, очень дельный текст. Практически выхватили у меня из рук одну из тем статей на Хабре, ну, впрочем, тема такая важная, что я не в обиде.
Отдельное спасибо за привлечение внимания к таким вещам, как разница между «архивом» и «бэкапом», сомнительной ценности лент для бэкапа, и важности процесса восстановления и тестирования бэкапов после создания и архивов во время хранения.
Я обратил внимание, что об этом мало задумываются. А зря.
Отдельное спасибо за привлечение внимания к таким вещам, как разница между «архивом» и «бэкапом», сомнительной ценности лент для бэкапа, и важности процесса восстановления и тестирования бэкапов после создания и архивов во время хранения.
Я обратил внимание, что об этом мало задумываются. А зря.
В разделе хранения носителей (особенно — лент) в банковских ячейках, необходимо отметить, что климатические условия ячеек (температура и влажность) не всегда могут соответствовать условиям хранения носителей, и архив может выйти из строя быстрее, чем «раз в год».
Ну что же, все верно. Сам использую Symantec Backup Exec, особенно когда с ней разберешся.
«есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д.»
а можно этот момент осветить чуть подробнее: с какими проблемами восстановления приходилось сталкиваться?
может быть даже в виде отдельной статьи, ведь скорее всего систем и «заморочек» было много?
используется ли в вашей инфраструктуре несколько exchange серверов и приходилось ли восстанавливать первый/рядовой экс? были ли проблемы связанные с AD (сайтами) или с чем-то еще?
делались ли оптимизации для поднятия SQL-серверов? (когда базы по дцать гигов и их кучка, поднятие всего требует времени. а «работать уже хотят все и сразу») опять же, когда баз много и они большие, возникает вопрос схемы резервного копирования — в случае SQL речь уже идет не только о самой БД, но и о логах. которые тоже любят расти/обрезаться.
делалась ли на каких-либо сервисах оптимизация схемы резервного копирования в пользу времени восстановления, вместо места под бэкапы? (например, тот же экс судя по предыдущему посту должен быть весьма нетривиален по времени восстановления. особенно, если сторы большие и их мало)
действительно ли оказалось выгоднее иметь несколько ежедневных диффов вместо shadow copy на файловых хранилищах? может быть в процессе эксплуатации выявлены какие-то проблемы, мешающие полноценному использованию теневых копий?
можно ли по заголовку поста «про бэкапы» считать, что здесь рассмотрен именно аспект сохранения данных, а не обеспечения непрерывности работы? хотелось бы почитать как сделана именно непрерывность :) особенно, если полноценно перешли на экс 2007 (про SQL к сожалению поста еще не было, но если есть и SQL 2005+ — тоже интересно, используется ли зеркалирование/standbay и тп. в первую очередь, правда, с точки зрения непрерывности.)
ну и уже отвлеченный вопрос: поднятие упавшего сервиса выполняется руками или автоматизированно какой-то системой? например, если упал SQL, на который завязан sharepoint. или FS + DC и тп.
как реализовано восстановление системных объектов? т.е. если удаляем учетку в DC, поднимается ли она из какого-то бэкапа спецсофтом или ручками вынимается из захоронения и настраивается в первоначальный вид руками. вопрос больше по связанным сервисам, т.к. одного только SID не всегда достаточно (взять тот же экс)
а можно этот момент осветить чуть подробнее: с какими проблемами восстановления приходилось сталкиваться?
может быть даже в виде отдельной статьи, ведь скорее всего систем и «заморочек» было много?
используется ли в вашей инфраструктуре несколько exchange серверов и приходилось ли восстанавливать первый/рядовой экс? были ли проблемы связанные с AD (сайтами) или с чем-то еще?
делались ли оптимизации для поднятия SQL-серверов? (когда базы по дцать гигов и их кучка, поднятие всего требует времени. а «работать уже хотят все и сразу») опять же, когда баз много и они большие, возникает вопрос схемы резервного копирования — в случае SQL речь уже идет не только о самой БД, но и о логах. которые тоже любят расти/обрезаться.
делалась ли на каких-либо сервисах оптимизация схемы резервного копирования в пользу времени восстановления, вместо места под бэкапы? (например, тот же экс судя по предыдущему посту должен быть весьма нетривиален по времени восстановления. особенно, если сторы большие и их мало)
действительно ли оказалось выгоднее иметь несколько ежедневных диффов вместо shadow copy на файловых хранилищах? может быть в процессе эксплуатации выявлены какие-то проблемы, мешающие полноценному использованию теневых копий?
можно ли по заголовку поста «про бэкапы» считать, что здесь рассмотрен именно аспект сохранения данных, а не обеспечения непрерывности работы? хотелось бы почитать как сделана именно непрерывность :) особенно, если полноценно перешли на экс 2007 (про SQL к сожалению поста еще не было, но если есть и SQL 2005+ — тоже интересно, используется ли зеркалирование/standbay и тп. в первую очередь, правда, с точки зрения непрерывности.)
ну и уже отвлеченный вопрос: поднятие упавшего сервиса выполняется руками или автоматизированно какой-то системой? например, если упал SQL, на который завязан sharepoint. или FS + DC и тп.
как реализовано восстановление системных объектов? т.е. если удаляем учетку в DC, поднимается ли она из какого-то бэкапа спецсофтом или ручками вынимается из захоронения и настраивается в первоначальный вид руками. вопрос больше по связанным сервисам, т.к. одного только SID не всегда достаточно (взять тот же экс)
Вы наверное хотите, чтобы я следующие полгода отшельником провел за клавиатурой, рассказывая все то, что вы спрашиваете :)
Нет, правда, ваши вопросы замечательные, но это же настолько обширная тема, что можно писать и писать, заваливая простынями, а хочется пройтись по каким то вехам, что-ли, ну или хотя бы чтобы было интересно читать, а я, честно говоря, сомневаюсь, что очень многим понравится статья про нестандартное восстановление Exchange, где не столько интересны идеи и принципы, сколько просто довольно примитивный поиск решения по разным источникам, и с тем или иным успехом применение его.
Не забывайте также, что мой опыт ограничен условиями применения, с компаниями больше чем 500 ПК я не работал, а это накладывает отпечаток на решения. Скажем, автоматическое восстановление сервиса — это скорее исключение в моей ситуации, чем правило (я имею в виду автоматическое восстановление SQL, или там SCR в Exchange и т.п.)
Давайте я закончу сначала свой цикл, а потом, если хабравцам все еще будет продолжать нравится то что я пишу, пройдемся по мемуарам. м? И, кстати, спасибо, ваши вопросы были одними из самых дельных и глубоких. натолкнули на еще пару идей.
Нет, правда, ваши вопросы замечательные, но это же настолько обширная тема, что можно писать и писать, заваливая простынями, а хочется пройтись по каким то вехам, что-ли, ну или хотя бы чтобы было интересно читать, а я, честно говоря, сомневаюсь, что очень многим понравится статья про нестандартное восстановление Exchange, где не столько интересны идеи и принципы, сколько просто довольно примитивный поиск решения по разным источникам, и с тем или иным успехом применение его.
Не забывайте также, что мой опыт ограничен условиями применения, с компаниями больше чем 500 ПК я не работал, а это накладывает отпечаток на решения. Скажем, автоматическое восстановление сервиса — это скорее исключение в моей ситуации, чем правило (я имею в виду автоматическое восстановление SQL, или там SCR в Exchange и т.п.)
Давайте я закончу сначала свой цикл, а потом, если хабравцам все еще будет продолжать нравится то что я пишу, пройдемся по мемуарам. м? И, кстати, спасибо, ваши вопросы были одними из самых дельных и глубоких. натолкнули на еще пару идей.
о разделении понятий бэкап и архивирование добавлю, под архивированием часто подразумевается удаление скопированных данных.
Юзаю систему Bacula(конечно костыльная сама по себе и многое бы по другому, но зато умеет бэкапить и с никсов различных и с винды), схема бэкапа такая:
Раз в месяц full backup, далее каждый рабочий день incremental backup, и каждое воскресение differencial backup.
У incremental время жизни 7 дней, больше не имеет смысла, получается в конце месяца имеем 1 фул, 4 дифа и несколько инкрементальных(не более 5) за последнюю неделю.
Раз в месяц full backup, далее каждый рабочий день incremental backup, и каждое воскресение differencial backup.
У incremental время жизни 7 дней, больше не имеет смысла, получается в конце месяца имеем 1 фул, 4 дифа и несколько инкрементальных(не более 5) за последнюю неделю.
Прокомментируйте пожалуйста, как вы рассчитали риски «смерти» одного из жестких дисков на которых хранятся месячные бекапы, ведь в таком случае теряется огромное количество информации.
Я исходил из следующих соображений:
— «месячные» диски это отдельные диски, они используются редко, раз в месяц, и по умолчанию «сыпаться» не должны
— исходя из наших объемов, на один 2 ТБ диск влезает 2 месячных бэкапа с некоторым запасом на будущее, соответственно если он сгорит — то мы потеряем максимум наш архив-бэкап за два месяца, причем не по порядку. т.к. на каждом конкретном диске только два месячных архива, и мы их чередуем (январь-март, февраль-апрель и т.д.). Ситуация выглядит не такой уж страшной.
— кроме того возможны варианты, например: например незаслуженно забытое копирование на ВНЕШНИЕ «месячные» диски (их можно насовать хоть гроздью из 12 штук, по одному на каждый месяц) или копирование на диск и складирование в сейф руководителя (некий такой не совсем архив, но и уже не бэкап, дешевая альтернатива хранению ВНЕ офиса). Последний вариант (копирование на внешний диск, например через крэдл, и отключение его от сервера на год) вообще на мой взгляд весьма приемлем, если закрыть глаза на необходимость ручных действий.
— и последнее: обращение к месячным бэкапам на моей практике скорее исключение чем правило, и когда просят восстановить что-то старее, чем несколько месяцев, то обычно точных дат не просят, люди вполне готовы удовлетвориться не «мартом» а «январем».
— «месячные» диски это отдельные диски, они используются редко, раз в месяц, и по умолчанию «сыпаться» не должны
— исходя из наших объемов, на один 2 ТБ диск влезает 2 месячных бэкапа с некоторым запасом на будущее, соответственно если он сгорит — то мы потеряем максимум наш архив-бэкап за два месяца, причем не по порядку. т.к. на каждом конкретном диске только два месячных архива, и мы их чередуем (январь-март, февраль-апрель и т.д.). Ситуация выглядит не такой уж страшной.
— кроме того возможны варианты, например: например незаслуженно забытое копирование на ВНЕШНИЕ «месячные» диски (их можно насовать хоть гроздью из 12 штук, по одному на каждый месяц) или копирование на диск и складирование в сейф руководителя (некий такой не совсем архив, но и уже не бэкап, дешевая альтернатива хранению ВНЕ офиса). Последний вариант (копирование на внешний диск, например через крэдл, и отключение его от сервера на год) вообще на мой взгляд весьма приемлем, если закрыть глаза на необходимость ручных действий.
— и последнее: обращение к месячным бэкапам на моей практике скорее исключение чем правило, и когда просят восстановить что-то старее, чем несколько месяцев, то обычно точных дат не просят, люди вполне готовы удовлетвориться не «мартом» а «январем».
Что-то как-то с ног на голову: делать бекапы потому что все делают.
Начинать надо с противоположного: с плана восстановления — сразу будет видно и необходимую глубину и т.п.
Начинать надо с противоположного: с плана восстановления — сразу будет видно и необходимую глубину и т.п.
Вы очень правильно заметили, что надо разделять бекап и архивирование. Многие используют бекап как архив, что не есть гуд.
Но Вы неверно разделяете эти понятия. Краткосрочность/долгосрочность хранения данных можно установить и в бекапе и в архиве, но у этих систем принципиально разные функции.
У нас в компании есть такая поговорка "Backup for recovery, archiving for discovery", что значит «Бекап для восстановления, архивирование для поиска». В идеале должны существовать обе эти системы, они должны быть интегрированы между собой и обладать сквозной дедупликацией.
Но Вы неверно разделяете эти понятия. Краткосрочность/долгосрочность хранения данных можно установить и в бекапе и в архиве, но у этих систем принципиально разные функции.
У нас в компании есть такая поговорка "Backup for recovery, archiving for discovery", что значит «Бекап для восстановления, архивирование для поиска». В идеале должны существовать обе эти системы, они должны быть интегрированы между собой и обладать сквозной дедупликацией.
Интересно: когда я писал дипломный проект, я от одного человека услышал мнение, что мол архивы не нужны, объёмы жёстких дисков можно считать бесконечными…
Sign up to leave a comment.
Опытные мелочи-4, или «Померяемся бэкапами?»