5

Мое текущее хранилище (RAID-1 без аппаратной карты RAID) и резервное копирование (запасной диск) для моей домашней сети неадекватны. У меня слишком много данных, разбросанных по разным одноразовым дискам. Пришло время развиваться. Резервные копии кажутся достаточно простыми, по крайней мере: много больших дисков. Тем не менее, я озадачен количеством вариантов для небольшого домашнего хранилища. Drobo S выглядит привлекательно. Как и ReadyNAS. Я не ищу кучу блестящих функций, меня больше всего интересует надежность. Я не заинтересован в создании еще одного ПК для создания файлового сервера или для работы в облаке, или чего-то еще. Я глупый, поэтому я держу это простым.

Требования к основному объему:

  1. Начальное рабочее пространство примерно 2 ТБ, с возможностью увеличения до 5 ТБ
  2. RAID или что-то похожее на RAID с хотя бы одним диском четности
  3. ESATA II для скорости во время резервного копирования
  4. Возможность корректного отключения при получении оповещения о низком энергопотреблении от ИБП
  5. Необязательно, но желательно: сейчас потребуется 2 ТБ дисков с опциями для более крупных 3 ТБ дисков, которые появятся в 2010-2011 гг.
  6. Необязательно, но желательно: RAID-6 или что-то подобное, с двумя дисками четности
  7. Необязательно, но желательно
  8. Соединение Ethernet не требуется, так как объем будет использоваться на тех же компьютерах, на которых работает мой домашний сервер печати.

Резервные копии:

  1. Резервное копирование выполняется через ROBOCOPY в зеркальном режиме на внешний жесткий диск через соединение eSATA II.
  2. Начните с вращения между двумя внешними 2 ТБ жесткими дисками, перейдите до шести внешних 2 ТБ жестких дисков.
  3. Начните с еженедельного резервного копирования, переходите к двухнедельному резервному копированию по мере добавления дисков.
  4. При увеличении размера основного тома переходите на диски емкостью 3 ТБ.
  5. Резервные диски будут храниться в другом месте.

Жесткие диски:

  1. Я планирую купить все одинаковые модели, но разные партии от разных поставщиков.
  2. Я нашел утилиту «прожига», с помощью которой я могу разбираться с дисками в течение нескольких недель, прежде чем добавить их в резервный пул или основной том.

По моим оценкам, я рассчитываю начать примерно с 1500 долларов, как только начну добавлять два ТБ диска для резервного копирования и четыре для хранения. Итак, есть ли очевидные недостатки в моем плане? Что я упустил? Любые предложения для устройства хранения для моего основного тома, который соответствует моим требованиям? Или я просто оставлю это простым, два диска в RAID-1, а затем проведу тщательную проверку своих резервных копий, согласившись с тем, что мне придется покупать совершенно новый блок, когда объем моих данных превысит 2 ТБ?

|источник

3 ответа3

4

Основной том

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

Если вы ищете целостность и надежность данных, вы можете рассмотреть возможность использования файлового сервера OpenSolaris с конфигурацией raidz2 или raidz3 (2 или 3 диска четности соответственно) на ZFS.

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

Вы также можете запускать ZFS в других операционных системах, но OpenSolaris всегда является самой последней версией, поскольку для переноса новых функций на другие платформы требуется некоторое время. Если настройка окна OpenSolaris кажется немного более сложной, чем то, что вам нужно, FreeNAS, похоже, является следующей лучшей вещью с точки зрения поддержки ZFS.

На стороне Linux ZFS не поддерживается в ядре (только как драйвер уровня пользователя), но также разрабатывается новая файловая система, называемая btrfs. К сожалению, по состоянию на март 2010 года стабильной версии btrfs не существует.

Резервное копирование

Для ваших внешних резервных копий может быть более выгодно оплачивать такие услуги, как CrashPlan, Carbonite или Mozy. Настроить любой из них для автоматического резервного копирования файлов очень и очень просто. CrashPlan обладает лучшими функциями резервного копирования и восстановления (и даже позволяет бесплатно выполнять резервное копирование на другие удаленные компьютеры), в то время как методы восстановления Mozy либо дороги, либо очень неудобны (если вы хотите загрузить резервную копию Mozy, вам необходимо дождитесь, пока ваша работа будет поставлена в очередь и упакована в zip-файл). У меня лично не было никакого опыта с карбонитом.

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

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

Резервное вращение

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

РОБОКОПИЯ против CrashPlan

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

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

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

|источник
2

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

Я не заинтересован в создании еще одного ПК для создания файлового сервера или для работы в облаке, или чего-то еще. Я глупый, поэтому я держу это простым.

Шутки в сторону? Необходимость настройки сценариев резервного копирования с помощью Robocopy (который фактически не может создавать резервные копии используемых файлов)? Ручная транспортировка дисков вне площадки? Аппаратный рейд? Покупаете диски от разных производителей и запускаете на них утилиты? Все это противоположно простому.

Несмотря на всю шумиху вокруг "облачных" сервисов, резервное копирование данных на самом деле является одним из самых страшных применений. Я лично использую CrashPlan, потому что программное обеспечение хорошо себя ведет и очень прост в настройке. Но они все примерно одинаковы с точки зрения цены. Ожидайте платить около $ 3–5 баксов в месяц за неограниченное хранилище со всех ваших машин. Выигрыш в облачном резервном копировании заключается в том, что они избавляют вас от лишних хлопот, связанных с удалением ваших данных. Но независимо от того, каким сервисом вы пользуетесь, восстановление - это проблема, так как загрузка данных займет некоторое время. Поэтому вы должны дополнить его локальным решением для резервного копирования. А поскольку у вас уже работает облачное резервное копирование, ваше локальное решение для резервного копирования не должно быть пуленепробиваемым с точки зрения надежности, чтобы быть полезным.

Вот настройки, которые у меня есть для моего дома. Я собрал небольшой "домашний сервер" на базе Atom с четырьмя дисками по 1 ТБ в программном массиве raid 5 без "горячих" резервов. Чтобы быть ясно, рейд здесь не для надежности. Это для простоты создания одного резервного диска. Сервер работает под управлением Windows и копия CrashPlan, который не настроен для резервного копирования в любом месте. Остальные машины в доме также работают с CrashPlan и настроены для резервного копирования как в CrashPlan Central, так и на моем домашнем сервере. Вот и все. Все происходит автоматически, и я получаю отчеты о состоянии резервного копирования по электронной почте от CrashPlan, чтобы убедиться, что все работает без сбоев.

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

|источник
0

Только одна резервная копия? Это ошибка :) Особенно если вкладывать в нее столько ресурсов, было бы больно, если бы, например, стихийное бедствие выбило эту резервную копию, и вашу собственную, из нее.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .