Стратегия резервного копирования при больших объемах

[AlexeyC]

Добрый день.
Есть данные объемом окало 4 ТБ. Очень много небольших файлов. Объем растет почти каждый день. В год примерно плюс 1 ТБ. С этими данным могут работать круглые сутки каждый день.
Эти данные хранятся на RAID массиве. К этому серверу подключена по SCSI ленточная библиотека HP MSL 2024.
Суммарный объем ленточек окало 19 ТБ (без учета компрессии).
Вопросы:
Как лучше построить стратегию резервного копирования ? Достаточно глубины хранения - 1 неделя.
Самый простой вариант - делать полную копию + дифференциальные. Полную копию делать раз в неделю.
Места на лентах хватит что бы всегда была полная копия + набор дифференциальных.
Но проблема в том, что полная копия будет делаться долго (наверно более суток). В результате может утратиться ее актуальность.

Как вообще правильно делать резервные копии для такого большого объема при работе с ним в режиме 24*7 ?


Можно ли как то на библиотеку HP MSL 2024 делать репликацию данных ?

[gs]

Снапшот?

[gs]

На самом деле придумать можно много чего, но вот хватит ли денех?

[AlexeyC]

На самом деле придумать можно много чего, но вот хватит ли денех?

Два варианта:

1) Какое по Вашему оптимальное решения для существующего оборудования (HP MSL 2024) ?
2) Какое решение можете предложить Вы? И сколько оно стоит ?

[gs]

Какие приводы в библиотеке?
Что собственно не успевает - лента или массив?

[AlexeyC]

Какие приводы в библиотеке?

Приводы Ultrium 4-SCSI.

Что собственно не успевает - лента или массив?

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

[exLH]

В течении этого времени много данных могут измениться.

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

Как сейчас реализовано резервное копирование?
И где сейчас хранятся Ваши 4ТБ данных (на внутренних дисках сервера?)?

[CrazyFrog]

Когда файлы мелкие и их много, то это называется ФС высокой плотности (High density file system). Способ бэкапа такой штуки на обычном сервере фактически только один: бекапить нижележащий диск как имидж. Например, Legato SnapImage если его EMC ещё не угробило. Или Acronis, но тот IIRC не умеет писать на ленту.

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

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

[ITER]

Когда файлы мелкие и их много, то это называется ФС высокой плотности (High density file system). Способ бэкапа такой штуки на обычном сервере фактически только один: бекапить нижележащий диск как имидж.

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

[AlexeyC]

Всем большое спасибо за ответы.

А есть ли у кого-нибудь опыт работы с ленточной библиотекой HP MSL 2024 ?
Как правильно настроить бэкап для связки HP Data Protector + HP MSL 2024 ?

Хочу реализовать бэкап данных (4 ТБ) на ленточки использую ПО HP Data Protector.

Ленты достались по наследству с уже имеющимися данными которые не нужны.

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

Просто с ленточными библиотеками никогда раньше не работал

[AlexeyC]

Еще раз всем большое спасибо за помощь.
Вопросы по работе с HP MSL 2024 задам в отдельной теме.

[MAA]

exLH
Для того, чтобы этого не произошло достаточно использовать ПО резервного копирования с поддержкой VSS (или других технологий мгновенных снимков).
а можно подробнее рассказать про реализацию бэкапа через снапшот? (а то в интернете как-то поверхностно описано)
Правильно ли я понял, что бэкап через снапшот работает так:
1) на время бэкапа запись на том1 запрещается, а изменения пишутся на другой том2
2) делается бэкап (копирование файлов с том1 например на ленту)
3) после бэкапа изменения с том2 сливаются с данными на том1
4) разрешается запись на том1
?
если всё так, то у меня будет ряд вопросов

[Ziggy Stardust]

Правильно ли я понял, что бэкап через снапшот работает так:
1) на время бэкапа запись на том1 запрещается, а изменения пишутся на другой том2

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

2) делается бэкап (копирование файлов с том1 например на ленту)

Бэкап делается со снапшота файловой системы.

3) после бэкапа изменения с том2 сливаются с данными на том1

Снапшот просто удаляется.

[MAA]

Ziggy Stardust
Не так. На время бэкапа (в момент времени Х) на том же томе создается "теневая" копия (снапшот) всей файловой системы.
т.е. "на том же томе" - это обязательное условие?
и опять же поверхностное описание - "создается "теневая" копия (снапшот) всей файловой системы.". А как именно это происходит?

Получается на одном томе как бы две файловых системы
это мне вообще не понятно. что значит "две файловые системы на одном томе"?

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

[gs]

Да, все данные находятся на одном диске.
Снапшот - это просто логическая фиксация состояния диска на момент времени. Дальнейшие операции записи идут туда же, но перед записью новых данных изменяемые блоки переписываются в другое место на том же диске. В итоге существует две виртуальные файловые системы - одна нынешняя, а вторая - как было на момент снятия снапшота. "Старая" ФС приложениям просто так не видна, для работы с ней используются специальные службы ОС. Это очень приблизительно на пальцах.
По тому же принципу работает общеизвестная система "system restor" в винде.