Назад | Перейти на главную страницу

Правильное использование резервного копирования с диска на диск на ленту с использованием дедупликации и LTO5

В настоящее время у меня есть ~ 12 ТБ данных для полного резервного копирования с диска на ленту (LTO3). Излишне говорить, что сейчас для этого требуется более 16 лент, поэтому я ищу другие решения. Вот что я придумал. Хотелось бы услышать мысли сообщества.

Я предполагаю сделать полное резервное копирование всей моей сети, что сначала займет много времени через сетевую карту 1 Гбит / с, но после того, как дедупликация сработает, в резервных копиях должно быть быстро. Затем я воспользуюсь LTO5, чтобы сделать резервные копии с диска на ленту и заархивировать их соответственно.

Что думают все? Есть ли более быстрый способ сделать первоначальное полное резервное копирование через сетевую карту 1 Гбит / с? Какие будут мои болевые точки? Есть ли лучший способ сделать то, что я пытаюсь достичь?

В настоящее время я делаю ночное резервное копирование своих систем данных, используя в основном rsync и rsnapshot для еще нескольких томов, "видимых пользователем".

Самый большой том имеет емкость 16 ТБ, в настоящее время используется 9,5 ТБ. Сначала он делает простой rsync на отдельный дисковый массив. Обычно это занимает от 30 до 45 минут.

Затем он делает вторую копию на внешний сервер по беспроводной связи 100 Мбит (хотя обычно мы получаем 50-60 Мбит после некоторой потери пакетов). Это занимает примерно 3 часа каждую ночь.

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

В первую очередь интересует, хотите ли вы делать резервные копии или просто поддерживать активную копию. Одна активная копия 16 Тбайт, обновляемая каждую ночь, - это определенно выполнимая задача с диска на диск, и она почти наверняка будет дешевле, чем ленточная библиотека; Тем не менее, учтите, что ваш последний вариант восстановления теперь хранится на физически размещенном вращающемся диске, который уязвим для всех обычных проблем, связанных с отказом диска, повреждением при потере питания и т. д., поэтому спроектируйте свою дисковую систему с соответствующим уровнем избыточности .

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

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

Это, конечно, только мое личное мнение; Надеюсь, они вам пригодятся при разработке решения для резервного копирования. Удачи!

Если вы используете файловую систему с dump программы, такой как ext [234], тогда вы можете получить док-станцию ​​eSATA и кучу дешевых sata-дисков емкостью 1 ТБ. Для начального сброса нулевого уровня вам понадобится дюжина дисков, которые затем можно будет бросить в несгораемый сейф или сейф, а затем прокрутить еще 5 или 6 дисков, делая ежедневные резервные копии по образцу ханоя. Используя этот метод, у вас обычно будет 2 или 3 копии часто меняющихся файлов на ежедневных дисках на случай, если вам нужно получить файл, который был удален или перезаписан, а если вам нужно выполнить полное восстановление, вы получите уровень дюжины 0, затем восстановите от 1 до 5 ежедневных дисков, в зависимости от того, в какой день произошел сбой системы.

Для получения дополнительной информации о шаблоне резервного копирования башни Ханоя см. http://en.wikipedia.org/wiki/Backup_rotation_scheme.