MostWanted
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Casket
Цитата: Всем здрасьте!
Такая проблема : бэкапятся контроллеры домена - и фулл, и инкремент. Создаются файлы .bkf и папки IMG_blabla. Так вот эти папки не перезаписываются. Т.е. файлы .bkf нормально труться и создается новая папка IMG, а старая не удаляется. Место со временем кончается, подтираю вручную...Запарило уже... Может, кто в курсе как пофиксить. Бэкап идет на харды(backup-to-disk).
Symantec 11d 7170+обновы |
trepov
Цитата: Цитата:создается новая папка IMG, а старая не удаляется
У меня IMG создается при проведении быкапа Exchange 2003 с возможностью восстановления по ящикам. IMZ приходится удалять руками. |
Поделюсь своим опытом по этому поводу:
Зарубежные сисадмины уже несколько лет (судя по форуму Symantec) ломают голову над технологией Granular Restore Technology (GRT). Вот такие посты можно встретить по данной проблеме:
http://seer.entsupport.symantec.com/docs/286794.htm
https://forums.symantec.com/syment/board/message?board.id=115&thread.id=3229
Эта проблема проявляется, когда вы бакапите базы Microsoft Exchange 2003 на жёсткий диск Backup-to-Disk (B2D) с использованием опции Enable the restore of individual mail messages and folders from Information Store backups (возможность восстанавливать отдельные почтовые ящики и отдельные письма). В таком случае Backup Exec создаёт маленький файлик B2S.....bkf (~2 КБ) и рядом с ним "кладёт" папку IMG.... в которой, собственно, и лежит бакап. Идём далее: после такого бакапа, если смотреть на закладке Media, можно увидеть в вашем медиасете один Media с именем B2D..., объёмом (Used capacity) 2 КБ и один Media и иненем IMG..., объёмом 0 Байт. Если реально посмотреть размер папки IMG... на жёстком диске, то он нормальный и соответствует действительности. При всём этом, если даже на вашем медиасете период перезаписи Overwrite protection period выставлен в "0 Hours" (т. е. все носители (Media) в этом сете могут быть перезаписаны в любое время), и период добавления Append period выставлен в "Infinite - Allow Append" (т. е. на носитель можно добавлять информацию до бесконечночти), то у носителя IMG... в поле Appendable Until один хрен будет стоять Not appendable (!!!). А вот с этого места получается вот что: при каждом новом бакапе баз Exchange Server с указанными выше опциями и условиями будет создаваться новый носитель (а на диске - каталог) с именем IMG...+1 и до тех пор, пока у вас не кончится свободное место на диске.
Symantec знает об этой проблеме и если вы воспользуетесь "звонком другу" (12 MONTH BASIC SUPPORT), то в ответ на этот косяк работы технологии GRT вы услышите IS BY DESIGN, что равноценно "мы знаем, что такой баг есть, но он не лечится хот фиксами и не будет лечиться, т. к. мы так написали данный программный продукт и переписывать его не будем". Этот баг присутствует во всех версиях Backup Exec где есть технология GRT - у меня стоит 11d с SP2 и Hot Fix 31, 32, 33, 34 и 35 - указанный баг в GRT присутствует в полной мере 
Как лечить (или обходить):
1. Первый вариант самый простой - стирать устаревшие носители IMG.... Причём, не стоит ручками удалять каталоги, лучше зайти в закладку Devices и в нужном Backup-to-Disk Folder выбрать устаревший носитель IMG..., нажать на нём правой кнопкой мыши и в контекстном меню выбрать пункт Erase.... Дальше всё как обычно. После стирания такого носителя, происходит не просто его очистка, а удаление его из списка носителей в Backup Exec и физическое удаление каталога с диска.
Минус такого способа - нужно не забывать ручками регулярно подчищать IMG... носители, поэтому если у вас много серверов и бакапы идут каждый день и их объёмы внушительные (от 20 ГБ), то вы запаритесь работать руками 
2. Второй вариант - это то, что предлагает Symantec в своих отмазочных статьях базы знаний. Ещё одна особенность технологии GRT заключается в том, что если на жёстком диске куда вы пишите нет места, то текущий бакап всётаки переписывает (!!!) носитель IMG... Т. е. есть у вас почтовая база на 20 ГБ и она до текущего момента ужа бакапилась в нужный медиасет (есть носители B2D... и IMG...), а теперь на жёстком диске осталось, например, 15 ГБ свободного места. Приходит время записи в этот медиасет (у задания выставлено Overwrite media) - вот теперь Backup Exec видит, что места, чтобы создавать новый IMG... носитель нет и удаляет имеющийся носитель IMG..., создаёт новый IMG... с новым индексом и льёт бакап в него. Вам (вернее GRT) не обязательно упираться в окончание свободного места на жёстком диске, достаточно правильно выставить параметр Disk space reserve в свойствах нужного Backup-to-Disk Folder на закладке Advanced. Теперь к вопросу о том, как выбрать этот резерв: нужно выставлять такое количество резервируемого свободного места, чтобы GRT чуть-чуть (~1..2 ГБ) не хватало его для создания нового носителя IMG... Какое то время последите за этим и потом после полного цикла (в течение недели, например) резервного копирования на диск можно будет забыть про баг в GRT.
|
