У нас есть ленточный накопитель на 400 ГБ и мы используем Symantac Backup Exec 12.5. Если посмотреть на историю двухмесячной давности (до того, как я был здесь), объем работ был равен ~ 355 ГБ, но за это время он увеличился на 40 ГБ до ~ 395 - в опасной зоне из-за нехватки места.
Я ищу идеи, как разделить эту работу на несколько частей, выявить в работе те, которые растут больше, чем другие, или что-нибудь еще, что могло бы взять это под контроль.
Я предполагаю, что это единственный, не роботизированный диск, напрямую подключенный к какому-то серверу. И бюджета нет, или бюджета практически нет. Ваши варианты:
Просмотрите исходные данные и посмотрите, можете ли вы удалить или исключить части из резервного набора.
Выясните, как разделить резервную копию на два задания и запускать эти два задания в разные ночи на разных лентах.
Купите больший ленточный накопитель (привет, LTO-4!)
Купите робота, который будет автоматически менять ленты за вас.
Найдите схему резервного копирования через Интернет.
Резервные копии - это то, о чем многие люди писали эссе.
Вы должны знать, что такое окно восстановления - оно варьируется от «Я хочу восстановить файл, который я удалил десять минут назад (или шесть месяцев назад) СЕЙЧАС!» на «а, если мне придется подождать неделю, пока лента будет доставлена за пределы офиса, это круто».
Вы должны знать, являются ли эти резервные копии для аварийного восстановления (например, здание сгорело!) Или аудита (подтверждение состояния на определенную дату) или восстановления на уровне пользователя (кто-то удалил учетную запись X вместо Y) или восстановления на уровне файлов ( какой-то секретарь случайно наклеил запись в Facebook поверх финансовых отчетов компании). Ответы на эти вопросы повлияют на то, как выполняется резервное копирование.
Если есть правила для резервного копирования, обычно это:
Бюджеты будут ограничивать то, сколько из каждого из них вы действительно можете сделать, но люди, отвечающие за компанию, должны знать, что подкрепляется, а что нет, и каковы последствия этих фактов. Резервное копирование важно для способности компании выдерживать технические (а иногда и кадровые) сбои. Они должны быть одобрены кем-то, кому делегированы эти обязанности из высшего руководства.
Тебе не победить. Когда вы запрашиваете роботов, носители и программное обеспечение, они говорят: «Нам не нужно создавать резервную копию X». Однако в случае опасности они будут кричать на вас: «Почему вы не сделали резервную копию X?»
У своих клиентов каждые шесть месяцев я готовлю документ, в котором подробно описывается, что именно создается, и я отмечаю каждый важный набор объектов (о которых я знаю, хех), для которых НЕ выполняется резервное копирование, и отправляю его клиенту по электронной почте. а затем проведите с ними 30 минут, чтобы просмотреть его. Таким образом они будут знать, что копируется, что, по моему мнению, не копируется, время выполнения резервного копирования и требования к данным, политики хранения данных, детали за пределами площадки, обзор основных проблем (и, надеюсь, решения) за последние шесть месяцев , плюс все, что я считаю важным. Я спрашиваю их, знают ли они о чем-нибудь еще, что требует поддержки. Если требуются какие-либо изменения, я вношу их, повторно отправляю документ и храню эти электронные письма как доказательство того, что я отправил им документы. На самом деле, если что-то важное не подкреплено, моя задница все равно будет в перевязи, но в большинстве случаев у нее будет компания.
Резервные копии - это огромная, дорогая и сложная банка червей.
Удачи.
ИМХО, это природа бэкапов. Данные накапливаются, а объем резервных копий увеличивается. Это естественная эволюция. Почему это проблема? Вы не можете использовать несколько лент для резервного копирования? Разделение задания не приведет к уменьшению объема данных, для которых требуется резервное копирование.
Может ли ваше программное обеспечение выполнять резервное копирование на жесткие диски? Я бы серьезно подумал о замене лент на жесткие диски емкостью 2 ТБ и беспокоился о проблемах, связанных с этим, несколько лет спустя. Я знаю, что стоимость каждого элемента выше (или надеюсь, что это так), но жесткие диски можно читать на любом компьютере, и если ваш ленточный накопитель выйдет из строя, вы потеряете много лент, пока не получите еще один.
И ленты изнашиваются.
Согласитесь с Дэвидом в том, что резервное копирование обычно оказывается невероятно сложным, особенно когда вы начинаете увеличивать масштаб. Несколько дополнительных идей для потенциальных решений:
Первый вопрос, который я задам, - есть ли причина, по которой вы не можете использовать вторую кассету? Если резервная копия заполняет ленту, Backup Exec просто запросит (с помощью предупреждения) другую перезаписываемую ленту, и резервное копирование продолжится на нее.
Если вы абсолютно не можете использовать вторую ленту, вы можете выбрать диски и ленты большего размера или автозагрузчик ($$$), или вы можете рассмотреть возможность резервного копирования некоторых данных с помощью политики полного / дифференциального резервного копирования.
Чтобы узнать, какие ресурсы увеличиваются в размере, вы можете перейти в раздел «Файл», «Новый список выбора для восстановления», а в окне «Просмотр по ресурсам» можно просмотреть каталогизированные резервные копии и просмотреть размеры ресурсов, папок и т. Д.
Если вы хотите разделить задания на отдельные разделы, рекомендуется использовать политики Backup Exec.
Для всех, кто заинтересован, то, что мы собираемся сделать прямо сейчас, - это создать новый файловый ресурс / подключенный диск для пользователей для данных «Архив». Я мог бы также назвать это «статическими» данными или чем угодно, что редко меняется. Резервное копирование этого файлового ресурса будет выполняться только один раз в неделю.
Идея состоит в том, что это будет работать в течение более длительного времени, потому что по мере роста общей доли мы можем легко разделить раздел архива на несколько разных частей и каждую ночь выполнять резервное копирование одного из фрагментов, чтобы резервное копирование всего архива производилось каждую неделю. Затем мы переместим все, что не изменилось за последний год, в новое место и раз в квартал будем проверять наличие новых архивируемых файлов.