Как лучше всего выполнять резервное копирование данных на контент-серверах? Например, у меня есть 15 серверов, на которых просто есть контент, на нем нет запущенных приложений. Каждый сервер имеет жесткий диск объемом 250 ГБ. Итак, это довольно большой объем данных. Все данные имеют внешний доступ (по HTTP). Итак, вопрос: какая методология лучше всего подходит в моем случае?
Самый полезный из известных мне методов - это перекрестное резервное копирование: когда каждый сервер содержит свои собственные данные и резервную копию другого сервера. Но наблюдается значительное сокращение общей емкости.
RAID?
RAID не является резервным.
Теперь, когда это не в порядке, если у вас есть 15 серверов, на которых хранится только контент, и каждый из них имеет размер 250 ГБ, самое время задать себе несколько вопросов.
0) Следует ли централизовать данные?
Если вам просто не нравится управлять хранилищем на 15 машинах, вам, вероятно, следует выбрать объединенное управляемое хранилище. Тем не менее, за это приходится платить. Хранение стоит дешево. Удалось хранение стоит дорого. Если вы не хотите (или не можете) управлять им централизованно, вам понадобится ленточное решение. Самым дешевым решением будет один сервер с большим количеством дисков (в конфигурации RAID), подключенный к довольно большому устройству смены лент (в идеале, поскольку вы не хотите вручную менять ленты каждый день, я полагаю). Вы также можете взять 15 ленточных накопителей и подключить каждый к серверу, но это глупо.
1) Какова ваша политика хранения данных?
Другими словами, собираетесь ли вы хранить данные вечно или в течение ограниченного периода времени?
2) Какая у вас дельта размера?
Насколько ваши данные меняются за день? Это необходимо учитывать в ваших будущих планах хранения. Покупка оборудования связана не только с ИТ. Необходимо учитывать бухгалтерский учет. Если вы амортизируете свои покупки в течение 3 лет, вам необходимо приобрести хранилище, которого хватит на 3 года. Посчитайте или заплатите позже.
3) Куда ты собираешься его поставить?
15 * 250 = много данных, как вы упомянули. Вы должны выяснить, куда вы собираетесь его положить. Если вы хотите, чтобы он был «живым», вам нужно получить какой-то массив хранения. Если вы хотите сделать резервную копию на ленте, вам понадобится устройство смены ленты, подключенное к серверу с большим хранилищем.
4) Какая часть данных является копией других серверов?
Если вы централизовали хранилище, у вас есть возможность инвестировать в массив хранения, который имеет «дедупликацию данных», которая экономит тонны и тонны (и тонны) пространства. По сути, если файл здесь имеет те же данные, что и файл там, данные сохраняются только один раз, а вместо этого в каждом месте сохраняется токен, размер которого меньше исходных данных. Однако решения, которые обеспечивают это, дороги.
Расскажите, пожалуйста, о текущей топологии сети, характеристиках данных, особенностях серверов и обо всем, что можно.
RAID не является резервной копией. Скажите это со мной и повторяйте это про себя снова и снова. RAID защищает вас от отказа оборудования, но не от катастрофы.
Что бы вы ни делали, важно иметь резервную копию в автономном режиме. Если кто-то может злонамеренно или случайно удалить все ваши резервные копии, потому что все они подключены к сети и доступны через сеть, ваши резервные копии на самом деле не были резервными копиями. (Прочтите, что случилось с "avsim.com", когда их взломали, если хотите понять, о чем я говорю.)
Raid предоставит вам резервные копии только в случае сбоя оборудования. Что вам нужно, так это программное обеспечение для резервного копирования, чтобы сделать дубликаты всего контента на другом сервере, желательно в другом географическом месте.
Я бы купил сервер резервного копирования с несколькими дисками по 1 ТБ и сделал резервную копию всего на сервере резервного копирования.
Взял этот ответ из предыдущего вопроса о резервных копиях, поскольку я считаю, что он все еще применяется здесь (к вашему сведению, это был мой ответ, а не кто-то еще):
В зависимости от того, сколько вам нужно резервных копий, я бы рекомендовал следующее:
1.JungleDisk / Amazon S3 - ОЧЕНЬ хорошо работает.
2. RSYNC на удаленную машину тоже работает очень хорошо. Работа CRON каждые XX часов.
Мы выполняем резервное копирование почти ТБ данных в облако Amazon S3 и имеем «теплый резерв» в нашем colo-резервном копировании с главного устройства несколько раз в день (через rsync). Стоимость передачи / хранения на Amazon S3 чрезвычайно низкая. (то есть дешевле, чем запись на DVD, но не дешевле, чем резервное копирование на жесткий диск. Я знаю некоторых людей, которые просто подключают UDB емкостью 1 ТБ «Моя книга» или что-то еще к серверу и делают резервную копию еженедельно / ежемесячно. В зависимости от ваших потребностей один или два из них могут быть для вас самым дешевым решением.
Теперь это просто резервное копирование ДАННЫХ ... не резервное копирование самого сервера ...
В зависимости от ваших потребностей, Norton Ghost или даже Acronis (http://www.acronis.com) может быть вам полезен. Такие вещи, как Norton Ghost, как правило, полагаются на вашу способность выключить компьютер, чтобы сделать резервную копию. У некоторых из нас нет такой роскоши, но если у ВАС она есть, то Norton Ghost - ОЧЕНЬ хороший продукт.
RAID не следует использовать в качестве резервного решения. Я бы купил внешние диски или установил резервный сервер с чем-то вроде BackupPC, а затем повернул диски и сохранил хотя бы одну копию за пределами офиса.
Если вы готовы расстаться с наличными, мы используем R1Soft CDP на нашей платформе. Это очень хорошо.
Какие данные? База данных? обычные файлы? Вам нужна синхронизация в реальном времени?
Некоторые решения для резервного копирования позволяют выполнять восстановление в любую точку в случае базы данных.
Мы также попадаем в треугольник стоимости, качества и скорости. Пожертвуйте одним, чтобы получить два других.
Стоимость в данном случае - деньги. Качество - это деталь резервной копии. (больше точек для восстановления, ценность за пределами площадки) и Скорость - это производительность, которую вы получаете или теряете с помощью различных решений.
Выяснение того, что важнее, может помочь вам выбрать решение.
Что-то вроде МогилеFS смогу помочь в этом случае. Это крупномасштабное решение для хранения данных без единой точки отказа, и вместо поддержки системы в целом оно имеет несколько копий данных, разбросанных по кластеру. Отдельные диски (или шпиндели) могут выйти из строя, но чем важнее файл, тем больше его копий будет существовать в кластере. Миниатюры, которые можно легко воссоздать, могут иметь только 1 или 2 копии, но исходные изображения могут иметь больше - в зависимости от класса данных, к которому принадлежит файл.
Подобные методы используются Google и Facebook для хранения собственных файлов.
Что ж, архитектура такая:
15 серверов с HTTP сервером, все файлы обычные (без баз, без приложений) и доступны для скачивания (файлообменный проект). они бегут под МогилеFS.
Пара серверов приложений, которые я не считаю, если они живут своей жизнью. Суть резервных копий такова: если что-то случится, я разверну данные из резервной копии как можно быстрее.
Итак, я сказал о RAID как о варианте, конечно, это не решение для резервного копирования, но оно поможет уменьшить количество отказов.
Как реальный вариант я вижу Amazon S3 с его простым API, на котором у меня уже есть учетная запись для ежедневного резервного копирования базы данных.
И мой интерес прост, я просто хочу знать, как люди справляются с такими задачами.
Если вы серьезно относитесь к резервному копированию почти 4 ТБ данных, о чем вы говорите, с помощью 15 серверов по 250 ГБ каждый, у вас есть несколько вопросов, на которые нужно ответить.
1. Какая часть данных уже намеренно или не дублируется в вашей среде?
Если у вас есть тонна дублированных данных, вы можете значительно сократить занимаемое пространство и количество данных, которые необходимо создать для резервного копирования.
2. Можете ли вы централизовать данные на меньшем количестве серверов?
Установка исправлений, лицензирование и обслуживание 15 серверов - трудоемкий процесс, если их можно объединить в один. NAS или SAN. Их объединение не создало бы никакого «риска для безопасности», если бы разрешениями управляли правильно (это была самая большая жалоба моих пользователей, когда мы консолидировали хранилище, они чувствовали, что, если у них нет своих СОБСТВЕННЫХ серверов, люди могли бы видеть свои данные. Образование разрешило эту проблему. ) Если они не могут быть объединены по географическим причинам, это понятно. Это также изменит вашу стратегию резервного копирования, поскольку никто не хочет перетаскивать тонны данных по глобальной сети для резервного копирования.
3. Почему вы делаете резервную копию своих данных? Disatser Recovery? Защита от случайного удаления? Возможный отказ оборудования? Все вышеперечисленное? Эти ответы определяют ваше окно удержания и вашу методологию. Как уже говорили другие, RAID хорош только против аппаратных сбоев, если вы удалите файл на RAID-наборе, он практически исчез. Если вам нужно вернуть то, что удалили пользователи, вы должны знать, как часто эти данные используются. Месяц резервного копирования файла, который используется только раз в квартал, означает, что у вас не будет файла, когда они заметят, что он исчез. Я не рекомендую хранить здесь 3 месяца дополнительных данных, но сохранение конца месяца в течение года может быть хорошей идеей. Если необходимо аварийное восстановление, вам нужно подумать о переносе данных за пределы площадки, а также с серверов. Кроме того, зная, почему вы выполняете резервное копирование, вы сможете узнать, как часто вам следует выполнять резервное копирование. Еженедельное полное резервное копирование с ночным инкрементным или дифференциальным резервным копированием - традиционный метод и хороший вариант по умолчанию, но если ваши данные изменяются очень быстро или очень медленно, этого может быть недостаточно часто или слишком часто.
4. Какой у вас бюджет на резервное копирование? Это будет важным определяющим фактором при выборе того, что вы в конечном итоге выберете. Для хранения 4 ТБ данных в одном месте я бы выбрал небольшой сменщик лент и программное обеспечение для резервного копирования, чтобы автоматизировать резервное копирование. Или, возможно, для устройства резервного копирования на диск с дедупликацией. Перекрестное резервное копирование изначально обходится дешево, но не обеспечивает никакой ценности для аварийного восстановления и становится более дорогостоящей по мере роста вашего набора данных. Существуют также службы, которые могут выполнять резервное копирование ваших данных через Интернет даже в таком масштабе, в автоматизированной форме с шифрованием и дедупликацией, что может работать лучше, если ваши данные находятся на многих сайтах.