LINUX.ORG.RU
ФорумAdmin

Кто-нибудь юзает резервное копирование на ленты? Поделитесь опытом.

 , , , ,


1

2

Сам юзаю только в bareos. Интересует следующее:
0. Версия технологии LTO.
1. Какие были проблемы?
2. Как часть дохнет лента?
3. Как часто надо стример чистящим картриджем прочищать?
4. Какие у вас объёмы (инфы и самих бекапов)?
5. Какое ПО?
6. Рекомендации.
7. Используется ли промежуточное хранение (диск или виртуальная библиотека)?
8. Используется ли шифрование?



Последнее исправление: leretan (всего исправлений: 1)
Ответ на: комментарий от EvgGad_303

А что из них субъективно лучше? И какой функционал в одном есть, а в другом нет? Особенно интересует NBU vs TSM.

leretan
() автор топика
Ответ на: комментарий от leretan

TSM и Legato давно реально использовал, последнее время в основном NBU. TSM монструозен, дохрена возможностей и больше похож на data management комбайн, чем просто бэкап/рестор.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от leretan

C NBU сравнить не могу, т.к. я его ни разу не видел.
В TSM информация о каждом файле хранится в БД, соответственно все это сразу доступно для просмотра, в отличие от большинства СРК, где сначала нужно указать желаемую дату для восстановления, подождать, пока с ленты прочитаются индексы, чтобы получить список файлов, обнаружить, что нужного для восстановления файла среди них не оказалось, выбрать другую дату, и далее по кругу (или запустить поиск файла в индексах, который все равно сведется к этим действиям). В TSM сразу открываешь нужную директорию, и видишь список всех файлов, которые когда-либо были забэкаплены. Но без БД ленты превратятся в тыкву, IBM официально не поддерживает способа восстановить с них инфу, если БД утрачена.
Основной способ администрирования - командная строка, и она просто офигенна. GUI тоже есть, он он в лучшем случае вторичен - просто не нужен при таком CLI, и им мало кто пользуется.
Мейнфреймовские коды сообщений и ошибок- типа ANRXXXXE - в общем, тебе понравится.
Очень развита миграция данных между лентами и пулами. Например, можно настроить, чтобы дынные лежали в дисковом пуле какое-то время, а потом мигрировали на ленты. Гранулярность - один файл, а не бэкапной джоб целиком (в TSM вообще нет такого понятия). В некоторых СРК вообще для этого приходится создавать еще одну копию данных на лентах. Непроэкспайренные данные периодически мигрируют с ленты на ленту, не так важно, чтобы данные на ленте экспайрились целиком, нету сущностей типа syhtetic full, статусов лент типа active/appendable (только full/filling/scratch/empty).
В других СРК обычно для каждого сервера нужно указать список, чего собстенно там бэкапить. У администратора TSM и так забот хватает - это делегируется админам этих самых серверов. Админу TSM достаточно лишь предоставить различные политики хранения, а админы серверов сами могут выбирать, что бэкапить и сколько хранить. Делается это с конкретного сервера, в бэкап/архив-клиенте, доступ в админскую консоль TSM для этого не нужен.
Есть только инкрементальные бэкапы (incremental forever) и архивы.
Гибкие политики хранения, можно построить очень эффектную систему бэкапа. Например. можно указать срок хранения не только в днях и бэкапных циклах, а в количестве версий файла. Хранить 10 последний изменений файла 2 недели. Если файл уже не меняется месяц, то удалить старые версии. Если файл стерли с диска, то хранить его 2 месяца, потом удалить, и т.д.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Мейнфреймовские коды сообщений и ошибок- типа ANRXXXXE - в общем, тебе понравится.

Это намёк на дрочево на мейнфреймы?

без БД ленты превратятся в тыкву, IBM официально не поддерживает способа восстановить с них инфу, если БД утрачена.

Ну офигеть просто. И что делать? Постоянно бекапить БД другим ПО для бекапов? А если мне надо экпортировать бекап в другую компанию без передачи всей БД?

У администратора TSM и так забот хватает - это делегируется админам этих самых серверов. Админу TSM достаточно лишь предоставить различные политики хранения, а админы серверов сами могут выбирать, что бэкапить и сколько хранить. Делается это с конкретного сервера, в бэкап/архив-клиенте, доступ в админскую консоль TSM для этого не нужен.

А централизованно это делать можно?

Есть только инкрементальные бэкапы (incremental forever) и архивы.

И в чём разница? Архивы без БД тоже тыква? А программное шифрование есть?

leretan
() автор топика
Ответ на: комментарий от leretan

Почему сторонним ПО? Сами же TSM'ом и бэкапить. И базу, и transaction-логи. Специальная команда лдя этого есть - BACKUP DB. Бэкап базы делается не в пул, а на отдельную ленту - ее без базы прочитать, естественно, можно.

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

Опции бэкапа (include/exclude и пр.) можно определять и централизованно, естественно.

Бэкап - только инкрементальный, архив - только полный, и они никак с друг другом не соприкасаются. Архивы без БД тоже тыква, но их можно оформить в виде backupset'ов - тогда не тыква. Но это только чтобы записать и забыть, мигрировать их в обратно пул или на ленты нового поколения не получится. Шифрование, конечно же, есть.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

ХЗ, почему-то показалось, когда приходилось сталкиваться. Может потому что с давних пор в основном NBU.

C NBU сравнить не могу, т.к. я его ни разу не видел.

В принципе, всё то же самое, что ты написал.

EvgGad_303 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.