Как сделать резервную копию 20 + ТБ данных?


86

В компании, для которой я работаю, есть сервер NAS, который используется для хранения фотосессий. Каждый сеанс составляет около 100 ГБ. За последние пару лет этот сервер накопил более 10 ТБ данных, и мы увеличиваем количество фотосессий в геометрической прогрессии. По моим оценкам, к концу следующего года на этом NAS-накопителе будет храниться более 20 ТБ. В настоящее время мы выполняем резервное копирование этого сервера на ленту с использованием лент LTO-5 с Symantec BackupExec. Поскольку размер этого сервера вырос, полное резервное копирование этого сервера не завершается в одночасье. Кто-нибудь есть какие-либо предложения о том, как сделать резервную копию этого объема данных? Должны ли мы записать это на ленту? Есть ли другие варианты, которые могут быть лучше?


36
Почему вы выполняете полное резервное копирование каждую ночь? Почему бы не запускать полное резервное копирование один раз в неделю и запускать инкрементные резервные копии оставшиеся 6 дней в неделю?
Joeqwerty

9
Это то, что мы делаем, извините, я не упомянул, что ... полный недельный - тот, который не завершается.
Иисус Фидальго

6
Нужно ли заполнять еженедельный полный за ночь? Для еженедельных изданий довольно часто требуется более 24 часов для достаточно большого набора данных.
Стефан Ласевский

2
Какой тип NAS вы используете?
Ewwhite 12.12.12

6
Вы уверены, что увеличение фотосессий экспоненциально ?
gerrit

Ответы:


114

Вы должны сделать шаг назад и перестать думать: «У меня есть 20 ТБ на моем NAS, мне нужно сделать резервную копию!» и разработайте стратегию хранения, которая учитывает характер ваших данных:

  • Откуда это берется и сколько новых данных вы получаете? (у вас есть это в вашем вопросе)
  • Как используются данные, когда они у вас есть? Люди редактируют картинки? Вы сохраняете оригиналы и генерируете отредактированные версии?
  • Как долго вам нужно хранить все данные? Люди по-прежнему вносят изменения в фотографии, сделанные 2 года назад?

В зависимости от ответов на два последних вопроса вам, вероятно, потребуется больше системы архивации, чем радикально отличной системы резервного копирования.

Статические данные (например, 2-летние снимки, которые вы сохраняете «на всякий случай») не нужно резервировать каждую ночь или даже каждую неделю, их нужно архивировать. То, что вы на самом деле делаете, может быть более сложным, но концептуально все старые рисунки можно записать на ленту (несколько копий!) И больше не создавать резервных копий.

Исходя из ваших комментариев, некоторые дополнительные мысли:

  • Поскольку вы сохраняете оригиналы каждого снимка нетронутыми и работаете над копией и предполагаете, что по крайней мере некоторые из оригинальных снимков являются ложными, вы можете сократить объем данных, для которых необходимо выполнить резервное копирование, пополам.

  • Если вы по-прежнему не можете завершить полное резервное копирование в течение какого-то времени, то у вас есть общий способ ускорить процесс - сначала сделать резервную копию с диска на диск, а затем скопировать резервную копию на ленту.


1
Оригинальный снимок сохраняется без изменений, затем для редактирования используется еще одна копия фотосессии. Данные, возможно, должны храниться около 2 лет.
Иисус Фидальго

20
+1 Хорошо сказано. Я удивлен, как разница между Backup и Archive, в общем, плохо понята. Я делаю полное и инкрементное резервное копирование своей системы и эфемерных данных, таких как электронная почта и документы, но архивирую свою фотографию (1,2 ТБ и больше :-). Жаль, что я мог бы дать еще один +1 для предложения диска на диск, а также.
Ex Umbris

8
+1 Держу пари, что 80% данных на NAS никогда не используются более одного раза.
Стефан Ласевский

+1 Наилучшим вариантом здесь является ежедневная и даже ежечасная передача данных с диска на диск для сбора изменений, а затем отправка полных или инкрементных резервных копий в архив или стороннему провайдеру / месту на еженедельной или полнедельной основе. Раньше каждые 15 минут мы делали дельта-резервные копии наших файлов SQL, чтобы уменьшить количество потерь данных в сценарии аварийного восстановления.
Брент Пабст

12

У вас есть два варианта:

Опция 1:

  1. Купить другой NAS
  2. Предоставьте своим пользователям RO доступ к new_NAS
  3. Переместить все файлы старше 2 лет в new_NAS
  4. Продолжайте резервировать old_NAS как обычно
  5. Каждые 6 месяцев перемещайте файлы старше 2 лет в new_NAS

Вариант 2:

  1. Купить другой NAS
  2. Запускать rsyncкаждый час: old_NAS -> new_NAS

    или лучше использовать что-то вроде rdiff-backup, которое rsync + сохраняет дельты с изменениями файлов (вы можете восстановить более старые версии файлов)

    rdiff-backup  user1@old_NAS::/source-dir    user2@new_NAS::/dest-dir
    
  3. Каждые 6 месяцев очищайте старые файлы, запустив что-то вроде:

    rdiff-backup --remove-older-than 2Y    old_NAS::/dest-dir
    

2

Почему ваши резервные копии должны быть завершены в одночасье? Производительность файлового сервера? Возможно, вы сможете ограничить пропускную способность вашего программного обеспечения для резервного копирования, чтобы ограничить воздействие в течение дня. Или выделите интерфейс на своем NAS для связи с ленточным накопителем, чтобы ограничить влияние на другой трафик.

Можете ли вы запускать полные дампы по выходным и делать приращения только в течение недели? Если проблема заключается в смене лент в выходные дни, когда никого нет рядом, дешевая ленточная библиотека / автозамена стоит намного дешевле, чем платить кому-то за смену лент.

Можете ли вы разбить данные на несколько групп, которые достаточно малы, чтобы заполнить их в окне резервного копирования?

На нашем NAS-накопителе около 50 ТБ данных, и на создание полного дампа всего этого с помощью двух стримеров требуется более недели (один том занимает почти неделю, поскольку в нем много мелких файлов). Что мы делаем, так это копируем наши данные на второй NAS. Наш вторичный NAS находится на месте (но в другом центре обработки данных, чем основной), поэтому мы по-прежнему помещаем данные на ленту для резервного копирования за пределы площадки. Мы запускаем резервные копии с этого вторичного NAS, поэтому резервные копии никого не замедляют.

Если вы можете разместить свой вторичный NAS достаточно далеко, то это может быть ваша резервная копия, никаких лент не требуется.


1

Я просто сомневаюсь в размере каждой стрельбы, действительно ли это 100 Гб / сессия? Сколько сессий проводит ваша компания каждый месяц?

Поскольку вы в основном храните старые сеансы, которые не будут часто использоваться, и т. Д. И, вероятно, вам не нужно будет восстанавливать эту информацию так часто, я бы посоветовал вам воспользоваться услугами какой-либо компании, чтобы решить эту задачу для вас. ,

Например, хранение этих 20 ТБ с использованием онлайн-сервиса, такого как Amazon Glacier, будет стоить чуть более 200 долларов в месяц. Если вам потребуется часто извлекать эти архивы или даже восстанавливать их полностью, это приведет к некоторым временным / затратным ограничениям. Если вы просто храните эти вещи «чтобы быть уверенными, что они хранятся», возможно, использование третьей части может облегчить вашу жизнь (и даже дешевле, чем покупка другого NAS, кассет и т. Д.)


1
100 ГБ за сеанс звучит для меня немного дорого, но не безосновательно. У нас обычно было 32+ ГБ сеанса, где я работал, и наше оборудование было среднего уровня.
Том Мартинал

1

full backups of this server are not completing overnight
Тогда попробуйте инкрементные резервные копии? Одна полная резервная копия каждые хх дней, инкрементный остаток.

Жесткие диски стоят недорого, быстрее лент и могут использоваться для резервного копирования.

Также есть хорошие альтернативы для облачных резервных копий, поэтому нет необходимости продолжать добавлять все более быстрые ленты.
Например:


Посмотрите на комментарии - это еженедельные отчеты, которые не заканчиваются. Кроме того, облачные резервные копии для 20 ТБ данных ... не очень хорошая идея. «Дешевый» вариант Amazon Glacier будет стоить ~ 2500 в год, а получение всех этих данных будет стоить ~ 36 000 долларов.
HopelessN00b

Это на самом деле не много.
Sirex

1
Я полагаю, это вопрос мнения, если 2400 долларов в год - это много для 20 ТБ относительно безопасного и полностью не требующего обслуживания хранилища. Нет энергопотребления, нет охлаждения, нет неисправного оборудования, нет SLA, не занимает место в стойке. И, как и в большинстве систем, вы должны ожидать около 0 операций полного восстановления. И если вам нужно восстановление, цена будет больше, чем $ 1800, чем $ 36000 (не знаю, откуда вы взяли это число).
Тедд Хансен

Для ледника $ 36K довольно близко. Я грубо расцениваю это как 42K $ для затрат на поиск на 20TB. Это все еще не много, хотя. Пропускная способность является более важной проблемой.
Sirex

1

Я думаю, что лучшим решением для этого является то, что мы делаем с нашими данными по заработной плате, что должно потребовать минимальных усилий для реализации.

  • Первоначально он хранится вместе с остальными данными сервера, которые ежедневно копируются. Срок хранения этих резервных копий составляет 13 месяцев.

  • Как только мы больше не ожидаем, что данные нужно будет изменить (через два периода оплаты, IIRC), эти данные (через сценарий) сохраняются в томе архива, который исключен из регулярных резервных копий.

  • Том архива ежегодно копируется на ленту, а ленты отправляются в Cintas для хранения на неопределенный срок.

Это позволяет нам иметь простой онлайновый доступ к этим неизменным данным (поэтому нам не нужно звонить на магнитную ленту в любое время, когда бухгалтер хочет что-то посмотреть), сохраняя при этом неопределенные сторонние архивы данных, которые нам, возможно, придется хранить вечно. и не ломая нашу резервную систему. Похоже, что тот же тип установки может работать для вас, хотя вы, возможно, захотите настроить объем данных, которые вы храните в сети, в зависимости от ваших потребностей для своевременного доступа к этим данным - 20 ТБ хранилища корпоративного уровня намного дороже чем архивировать его на два или три набора лент LTO5, которые хранятся в хранилищах за пределами площадки.


0

Может быть, вы можете создать свой собственный Backblaze Pod : 135Tb за 7384 $
Нажмите здесь для получения дополнительной информации: Backblaze Pod информация о сборке

Вы можете купить нужные кусочки и собрать их самостоятельно.

Может быть, вы можете построить 3 из них, и сохранить 2 на месте и 1 вне. Затем вы можете использовать один модуль в качестве «оперативных данных», второй модуль в качестве резервной копии первого модуля и третий модуль в качестве экстренной резервной копии.

С 135Tb хранилища для каждого модуля вы даже можете подумать о сохранении некоторой истории изменений ...
135Tb / 20Tb = 19 полная резервная копия .
В качестве альтернативы вы можете сохранить 10 полных резервных копий плюс смешное количество разностных резервных копий.

Естественно, если вы хотите резервное копирование вне сайта, вам понадобится какая-то большая пропускная способность ... :-)


5
Если ваши данные и ваша работа важны для вас, вы не должны пытаться создать свой собственный модуль с нуля. Это кажется хорошей идеей, пока вы не поймете, что кладете все яйца в одну действительно большую корзину. Хуже того, эта корзина не была тщательно протестирована как единое целое. Секретный соус backblaze - это репликация программного обеспечения во многих модулях, что позволяет беспрепятственно проваливать целые блоки. Вместо этого я бы порекомендовал сервер хранения supermicro, centos, xfs и rdiff-backup.
bugaboo

-1

Мой коллега приобрел NAS-устройство Synology на 8 дисков. Работает гибридный RAID. Несколько недель назад он купил восемь 3TB Seagate Barracuda у NewEgg за 89 долларов каждая. Вы можете перезаписать зеркало с производственного NAS на этот новый NAS через GigaBit. Поскольку вы передаете только различия, передача займет меньше времени. Затем вы можете использовать резервное хранилище для выполнения полного или инкрементного. Стоимость для вас будет меньше $ 2000 за запасной NAS.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.