У нас есть система резервного копирования на диск объемом 6 ТБ, работающая с Backup Exec 2010. Каждую неделю выполняется полное резервное копирование с разницей в другие дни. Нам удается сохранить там около четырех недель резервных копий.
Во-первых, прав ли я, полагая, что функция дедупликации более эффективно использовала бы это пространство для резервного копирования на диск? Например, в каждую из этих четырех недель один и тот же файл размером 4 ГБ копируется четыре раза (используемое пространство = 16 ГБ), но с дедупликацией будет сохранена только первая копия?
Во-вторых, если вы включите дедупликацию, будет ли это иметь немедленный эффект или потребуется время, чтобы дедупликация охватила область B2D?
В первом случае потребуется выполнить задание для существующих файлов B2D, найти дубликаты и пометить файл BKF как перезаписываемый.
Последующий вариант будет намного проще реализовать, поскольку он просто влияет на последующее резервное копирование.
Если бы я был букмекером, я бы выбрал более поздний вариант ;-) Кодировать проще ...
Я установил пробную версию Backup Exec 2010 и могу ответить на свои вопросы:
Во-первых, вы не можете использовать существующую систему резервного копирования на диск и преобразовать ее в хранилище с дедупликацией. Дедупликация - это совершенно другой механизм и новый тип хранилища в BE. Вы создаете новую область хранения с дедупликацией так же, как создаете область хранения резервных копий на диск.
Поэтому мой вопрос о том, удаляет ли дубликат существующей папки B2D, - «нет».
Это действительно создает острую проблему перехода на де-дублирование с B2D, если вы пытаетесь использовать тот же носитель. Поскольку BE никогда не удаляет файлы B2D BKF, вам придется делать это вручную по истечении срока действия носителя.
Во-вторых, BE de-dup по умолчанию основан на блоках с 64k блоками. Кроме того, база данных словарей должна поддерживать, чтобы позволить ей хешировать повторяющиеся блоки. Структура папок de-dup намного сложнее, чем B2D.
В-третьих, да, BE 2010 требует большой оперативной памяти. Я тестировал виртуальную машину W2k3 объемом 1 ГБ и заметил, что она работает как трехногий осел. В общей сложности он занимал 1,5 ГБ, поэтому файл подкачки был перегружен. Поэтому я думаю, что нам нужно обновить наш сервер резервного копирования в реальном времени, прежде чем рассматривать возможность использования de-dup.
Привет, Роб.
Обычная установка для использования B2D против дедуплицированных систем хранения (или механизма дедупликации BE) - это запустить 1 полное резервное копирование, а затем «инкрементное навсегда». Это предпочтительный метод, позволяющий полностью использовать возможности дедупликации, но он может не подойти для каждого центра обработки данных.
Дедупликация бывает разной. Я не могу сейчас вспомнить, что использует один BE, но все они создают контрольные суммы блоков данных, а затем сравнивают их с базой данных, чтобы увидеть, хранились ли они где-то еще.
У Backup Exec довольно высокие системные требования для дедупликации, вы должны это знать. Если я правильно помню, это 1 ГБ ОЗУ на 1 ТБ данных в цикле резервного копирования.
Вы должны заметить эффект дедупликации после выполнения полного резервного копирования с включенной опцией. Это будут в основном ваши «базовые» данные, как описано выше, где каждая инкрементная резервная копия будет дедуплицироваться по сравнению с полной резервной копией.
Я не вижу необходимости использовать существующие файлы B2D. Почему бы просто не направить следующую полную резервную копию в папку в хранилище B2D под названием «дедупликация» или что-то в этом роде?