Я использую Backup Exec 12.5 на Windows Server 2008 Standard x64. Сервер подключен к Dell Powervault 124T с интерфейсом SCSI, и я запускаю резервное копирование для самого сервера и других заданий, которые создают резервные копии других серверов по локальной сети.
Теперь backup Exec хранит свои файлы каталога под именем C: \ Program Files \ Symantec \ Backup Exec \ Catalogs \ Server, но также установил SQL Express и создал базу данных под названием BKUPEXEC.
Каталог каталога вырос до 120 ГБ, и у меня будут проблемы с дисковым пространством через несколько месяцев при таких темпах.
Следует ли делать резервную копию каталога и базы данных? или только один из них? Кроме того, порекомендуете ли вы политику очистки каталога каталога?
База данных содержит лишь небольшую часть информации в каталогах. Вы должны сделать резервную копию каталога и базы данных в рамках регулярного резервного копирования сервера, если вы собираетесь восстановить сам Backup Exec после аварии. Может быть удобно иметь каталоги в сценарии аварийного восстановления, если вы не хотите каталогизировать другие носители, чтобы найти подходящую ленту для восстановления.
Вам не обязательно делать резервные копии каталогов на ленту, но они могут пригодиться в случае аварии. Я копирую их на другие серверы на некоторых сайтах Заказчика. В других случаях я просто накрываю их обычным резервным копированием на магнитную ленту. Это зависит от их размера и свободного пространства на ленте / времени окна резервного копирования.
Помимо каталогов: вы всегда должны вести автономный журнал самой последней ленты, содержащей каталоги, чтобы в случае аварии вам не пришлось тратить время на каталогизацию лент, чтобы найти ленту с каталогами. на нем, чтобы вы могли определить, с каких лент вам нужно восстановить. Конечно, если вы настолько малы, что все заканчивается на одной ленте, это, вероятно, не имеет значения. Однако с автозагрузчиком легко не знать, какие ленты используются для каких заданий, и, в конечном итоге, вы можете потратить много времени на каталогизацию лент в сценарии аварийного восстановления, просто чтобы выяснить, какие ленты вам нужно использовать для выполнить восстановление.
Меня беспокоит, что ваши каталоги стали такими большими. Я имею в виду, это поразительно много. Я сижу перед ящиком с 12 месяцами ежедневных каталогов резервных копий, общий размер файла которых составляет менее 500 МБ.
Интересно, установлен ли период хранения вашего каталога на чрезмерно долгий период, регулярные операции по сокращению каталога не выполняются или что-то пошло не так. Я бы посмотрел на настройки каталога в меню «Параметры», в разделах «Настройки» и «Каталог», и посмотрел, как выглядит срок хранения. Вы видите какие-нибудь странные "предупреждения" по каталогам?
Совершенно безопасно отказаться от срока хранения, но, как говорит joeqwerty, в случае, если вам нужно узнать, что находится на ленте, которая устарела из каталогов на диске, вам придется каталогизировать ленту, чтобы увидеть, что на ней.
Я не поддерживаю ни одного. Я настраиваю хранение каталога в соответствии с тем, что я считаю разумным периодом времени, в течение которого меня могут ожидать или запросить восстановление данных, который для меня составляет 180 дней. После того, как каталоги старше 180 дней были очищены, можно просто повторно каталогизировать старые носители. Я не делаю резервные копии каталогов, потому что не хочу иметь дело с постоянно увеличивающимся размером каталогов и пространством, которое они занимают на моих носителях, что в моей малобюджетной компании очень ценно.
Резервное копирование каталогов потребует большего количества носителей по мере роста каталогов и приведет к значительному увеличению времени выполнения заданий резервного копирования по мере их роста.
Если вы чувствуете необходимость в резервном копировании каталогов, я предлагаю сделать их отдельно от обычных резервных копий на внешний USB-накопитель.
РЕДАКТИРОВАТЬ
Как намекал Эван в своем ответе, есть две причины, по которым вы можете сделать резервную копию своих каталогов и поддерживать довольно длительный период хранения:
Восстановление самого резервного сервера.
Возможность быстрого восстановления данных (или всего сервера) в критической / критической ситуации.
Вам нужно будет взвесить, какие параметры и настройки лучше всего подходят для вас и позволят вам достичь / превзойти любые конкретные цели или требования (как часть вашего DRP / BCP / SC).
Помимо необходимости хранить данные в базе данных, вам также необходимо настроить план обслуживания определенного типа для базы данных. Возможно, что файл размером 120 ГБ заполнен транзакционными данными.