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


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


81
2017-12-12 03:50


Источник


Почему вы выполняете полную резервную копию каждую ночь? Почему бы не запустить полную резервную копию один раз в неделю и запустить инкрементные резервные копии оставшихся 6 дней в неделю? - joeqwerty
Это то, что мы делаем, извините, я не упомянул об этом ... еженедельный полный - тот, который не завершается. - Jesus Fidalgo
Еженедельно ли заполняется полная ночь? Нередко для еженедельников требуется более 24 часов для достаточно большого набора данных. - Stefan Lasiewski
Какой тип NAS вы используете? - ewwhite
Вы уверены, что увеличение фотосессии экспоненциальный? - gerrit


Ответы:


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

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

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

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

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

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

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


110
2017-12-12 04:19



Оригинальная съемка сохраняется нетронутой, затем для редактирования используется другая копия фотосессии. Возможно, данные должны храниться около 2 лет. - Jesus Fidalgo
+1 Хорошо сказал. Я удивляюсь, как разница между Backup и Archive, в общем, плохо понятна. Я делаю полные и инкрементные резервные копии своей системы и эфемерные данные, такие как электронная почта и документы, но архивирую мою фотографию (1.2 ТБ и растущую :-). Хотел бы я дать еще +1 для предложения диска-диска. - Ex Umbris
+1 Готов поспорить, что 80% данных на NAS никогда больше не используется более одного раза. - Stefan Lasiewski
+1 Лучшим вариантом здесь является ежедневная и даже ежечасная дельта-передача на диск-диск, чтобы фиксировать изменения, а затем отправлять полные или инкрементные резервные копии в архив или локальный провайдер / местоположение на еженедельной или полугодовой основе. Мы использовали дельта-резервные копии наших файлов SQL каждые 15 минут, чтобы уменьшить объем потери данных в сценарии DR. - Brent Pabst


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

Опция 1:

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

Вариант 2:

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

    или, лучше использовать что-то вроде RDIFF резервного копирования который делает 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
    

12
2017-12-12 15:07





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

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

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

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

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


2
2017-12-12 18:47





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

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

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


1
2017-12-12 12:15



100 ГБ за сеанс звучит немного высоко для меня, но не необоснованно. У нас обычно было 32+ ГБ сессии, где я работал, и наше оборудование было средним уровнем. - Tom Marthenal


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

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

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


1
2017-12-12 13:47



Посмотрите на комментарии - это еженедельные заполнения, которые не завершаются. Кроме того, облачные резервные копии для 20 Тбайт данных ... не очень хорошая идея. «Дешевый» вариант Ледника Амазонки будет стоить ~ 2500 / год, и получение всех этих данных будет стоить ~ 36 000 долларов. - HopelessN00b
На самом деле это не так много. - Sirex
Я думаю, это вопрос мнения, если $ 2400 / год много для 20TB относительно безопасного и полностью не требующего обслуживания хранилища. Нет потребляемой мощности, без охлаждения, без сбоев, без SLA, не занимает место в стойке. И как и в большинстве систем, вы должны ожидать около 0 операций полного восстановления. И если вам нужно восстановление, цена больше, чем $ 1800, чем $ 36000 (не уверен, где вы получили это число). - Tedd Hansen
Для ледника 36 долларов США довольно близко. Я грубо подсчитаю его как 42 тыс. Долл. Для извлечения затрат на 20 ТБ. Это все еще не так много. Полоса пропускания - большая проблема. - Sirex


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

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

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

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

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


1
2017-12-12 16:58





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

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

Возможно, вы можете построить 3 из них и сохранить 2 на месте и 1 за пределами площадки. Затем вы можете использовать один блок в качестве «онлайн-данных», второй на месте подкачки в качестве резервной копии первого контейнера, а третий внешний сайт - в качестве резервной резервной копии вне офиса.

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

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


0
2017-12-18 08:28



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


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


-1
2017-12-12 16:38