Мы используем Symantec backup exec 12. Мы не считаем необходимым еженощное резервное копирование состояния системы. Мы предпочитаем создавать резервную копию ежемесячно или в случае внесения системных изменений.
Я читал статьи о том, что именно поддерживает состояние системы. Насколько я понимаю, даже с учетом состояния системы, все равно необходимо создать резервную копию всего диска C: и любого другого диска в системе, чтобы иметь возможность выполнить восстановление системы.
Мы выполняем резервное копирование нескольких серверов на ленту размером 800 ГБ. Вопрос в том, что теперь мы решили выполнять резервное копирование состояния системы только ежемесячно, что позволяет нам сэкономить 80 ГБ на полную резервную копию. Как вы думаете, нужно ли нам продолжать резервное копирование полного диска C: каждую ночь?
Примечание: мы делаем еженедельное мастер-задание и еженедельное добавочное. Причина, по которой возникает этот вопрос, заключается в том, что мы удерживаем недельный мастер, затем ежемесячно возвращаем предыдущую неделю в ротацию, удерживаем ежемесячно до конца года, а затем конец года сохраняется навсегда, и каждый месяц в конечном итоге возвращается в ротацию. Бла-Бла я бессвязно. В настоящее время на каждую полную резервную копию приходится две ленты. Мы пытались сократить до 1 ленты для удобства, но хотим делать резервные копии ПРАВИЛЬНО!
Что другие администраторы сочли лучшей практикой?
Теоретически вы можете выполнить резервное копирование строго состояния системы, и вы сможете восстановить это до новой установки ОС на новом оборудовании, если у вас случится авария.
На практике не всегда все идет так гладко. Часто на диске C находятся либо A) журналы, либо B) утилиты / драйверы для конкретного оборудования, которые могут быть либо полезны, либо критичны в случае восстановления.
Чтобы выяснить, можно ли обойтись только с состоянием системы, вам действительно следует выполнить тест аварийного восстановления и выполнить фактическое восстановление (на самом деле, вы действительно должны делать этот тест, как общее правило, каждый год). Всегда ошибайтесь в сторону слишком большого резервного копирования, пока не докажете, что можете сделать меньше.
-j
Я делаю еженедельные резервные копии наших дисков C: на выбранных серверах Windows с указанием состояния системы. Мы только заботимся о резервном копировании ОС машин, на диске C: которых хранятся вещи, которые не так легко воссоздать. Многие ящики в любом случае быстрее восстановить, чем восстановить. Теория, лежащая в основе Weekly Fulls, не должна так часто меняться на этих дисках. Мы храним эти резервные копии две недели, поэтому у нас есть две резервные копии. Это дало нам отличный баланс, позволяя вернуть то, что нам нужно, и не потреблять слишком много диска. Также это означает, что наши резервные копии состояния ОС / системы относительно свежие, и если нам действительно нужно откатить потерянные изменения, они будут только за прошлую неделю, что означает, что они достаточно свежие, чтобы их запомнить, и не так много, чтобы их можно было запомнить. неприятность.
Мы не храним никаких пользовательских данных на наших дисках C :. Они нужны только для данных приложений, которые нельзя установить на другой диск, и для проблем с конфигурацией.
У нас действительно есть ночное резервное копирование наших контроллеров домена с помощью SystemStates, чтобы у нас снова была текущая информация AD, которую мы храним только две недели, в основном только для аварийного восстановления. По сравнению с пользовательскими данными, которые мы храним намного дольше.
Имейте в виду, что состояние системы включает в себя реестр. Изменения в реестре будут зависеть от вашего сервера и установленных служб. Если какое-либо из этих определений служб находится в реестре и параметры меняются, вам необходимо обновить резервную копию состояния системы после изменения любого из этих определений служб.
Я не уверен, какова ваша ситуация, но, по моему опыту, полное резервное копирование системы не является необходимым или даже хорошей идеей. (GASP!)
По сути, лучше всего иметь вначале отказоустойчивое резервирование (например, репликацию Master-Master на сервере mysql) или Raid-1. (или 5 для лучших результатов).
По сути, на мой взгляд и по моему опыту, «резервное копирование состояния» - беспорядочный способ добиться цели. Если вам необходимо минимальное время простоя (менее минуты), используйте избыточность. для всего остального используйте решение для резервного копирования, которое подходит для системы (решение на основе rsync для файловой системы, репозитории для кода и т. д.).
Кроме того, ВСЕГДА ПРОВЕРЯЙТЕ ЗАПИСИ. В моем предыдущем посте в качестве младшего системного администратора Linux я натолкнулся на еженедельное резервное копирование за 8 лет ... в итоге мне понадобилось одно. обнаружил, что человек, которого только что уволили за грубую некомпетентность, в течение 8 лет напрямую поддерживал неправильное (пустое).
Мы также не делаем полных резервных копий C :, но мы делаем резервную копию состояния системы каждую ночь. Если вы используете активный каталог, очень важно хранить регулярные резервные копии состояния системы с ваших контроллеров домена - они не занимают столько места сами по себе по сравнению с полной резервной копией всего диска, и если ваша резервная копия старше, чем DNS возраст захоронения (который по умолчанию составляет 60 дней) не подходит для восстановления AD.
По собственному опыту, резервное копирование ОС и системного диска на «голое железо» часто не проходит гладко. Мы предпочитаем использовать такие вещи, как RAID с горячей заменой для избыточности, а затем резервное копирование данных и, где это возможно, конфигурацию с предположением, что нам нужно будет переустановить ОС и приложения, если что-то все равно пойдет полностью с ума.
Полное резервное копирование все на сервере здесь; полный по выходным, дифференциалы по ночам. Учитывая довольно минимальные накладные расходы, которые выполнение System State накладывает на вашу резервную копию как с точки зрения времени, так и с точки зрения хранилища, нет реальной причины не делать этого.