Восстановление архивных данных из бекапа

У меня вышла из строя библиотека 3584 Tape Library. Все данные с катриджей я забэкапил на другой STGpool, который находится на сетевом СХД.

Но вот беда. Пока пытаются восстановить чтение ленты с LTO, у меня не получается сделать доступным данные с СХД.

Может кто-нибудь сможет помочь-проконсультировать?

• Тема изменена 5 лет, 1 месяц назад пользователем Yury Rephar .

Непонятно немного. Что значит забэкапил на другой пул? Мигрировал данные с лент на другой пул? Нужны подробности. Что значит недоступны? Что пишет TSM?

Есть primary storage pool и copy storage pool. При архивации данные API клиента попадают на оба пула.

После нового года случилась авария с библиотекой 3584 type library, на которой лежит весь primary storage pool. Но TSM не захотел восстанавливать по запросам данные из copy storage pool.

А тут в 11.2.2 написано:

«Пул хранилища копий позволяет восстановить данные после частичного или полного отказа первичного пула. Примером частичного отказа является потеря одной из лент первичного пула хранилища или дефект на ленте. Когда клиент предпримет попытку восстановить файл с этого тома, сервер для незаметного восстановления клиентских данных автоматически переключится на нужный том в хранилище копий…»

Посоветуйте, плз, как исправить ситуацию на будущее?!

• Ответ изменён 5 лет назад пользователем Yury Rephar .
• Ответ изменён 5 лет назад пользователем Yury Rephar .
• Ответ изменён 5 лет назад пользователем Yury Rephar .

пришли q stg твое первичного пула f=d посмотри утилизацию копипула

Что именно по утилизации. Данные вообще не должны удалсять

я к тому, что может данных в копипуле и нет.

Проверь содержимое копипула. Проверь occupancy копипула и определишь наличие актуальных данных. Проверь тома на копипуле (они вообще там есть?). Я к тому, что ничего не удалялось, а изначально не поступало

ВСе есть. 1й это основной 2й копипул Небольшая разница, но это не существенно — один из катриджей пришел в негодность, но тогда не было копипула. Из-за чего, собственно и создал его

• Ответ изменён 5 лет назад пользователем Yury Rephar .

Проверь тома на статусы Вдруг unavailable Сделай audit library (где копипул) Я вангую, что TSM не может найти кассеты

Судя по скрину ты должен retreive делать ( ну вдруг ошибся )

Вот запрос на наличие материала на основном и копи пулах

не совсем то, логически база знает куда ссылаться, а вот может ли она туда добраться мы не знаем

SelecT * from volumes where stgpool_name=’your_pool’

SelecT * from libvolumes where library_name=’your_lib’

Сделай команду audit library ( только с флагом barcode=yes )

audit library делал А вот насчет первого у меня неопределенность. Дело в том что копипул, не принадлежит никакой library. Физически он сделан на СХД и подмонтирован через сеть по nfs. И у меня не получается к этому копипулу указать PATH и соответственно так же определить его тип устройства для DRIVE

Смотрите, вы сделали копипул типа класса FILE (сиквентальный пул) , так что все равно тома там в виде файлов все равно образуются и вы должны их видеть ( и TSM тоже ). Конечно к нему никаких драйвов не надо определять. Путь до данных определен в девайс классе этого пула. Проверьте корректность путей. На всякий случай (все-таки NFS) убедитесь в физической доступности файлов хотя бы на read. Посмотрите, вдруг TSM не имеет прав на чтение (у вас какая ОС для TSM ?) от своей учетной записи

ОS SUSE SLES 9 Он же пишет в них бекапы паралельно. Вот записи из ac Date/Time Message ——————— ———————————————————- 01/31/17 15:06:24 ANR0406I Session 13333 started for node MMP (VIDI MMP) (Tcp/Ip localhost(43199)). (SESSION: 13333) 01/31/17 15:06:24 ANR8340I FILE volume /opt/tivoli/tsm/server/backup/backup- _gatr/DOM_PROD_DISK_DEVCL/00002207.BFS mounted. (SESSION: 13333) 01/31/17 15:06:24 ANR0511I Session 13333 opened output volume /opt/tivoli/tsm/server/backup/backup_gatr/DOM_PROD_DISK_- DEVCL/00002207.BFS. (SESSION: 13333) 01/31/17 15:07:10 ANR8337I LTO volume ML1048L3 mounted in drive AUTODRIVE2 (/dev/IBMtape1). (SESSION: 13333) 01/31/17 15:07:10 ANR0511I Session 13333 opened output volume ML1048L3. (SESSION: 13333) 01/31/17 15:07:50 ANR0514I Session 13333 closed volume ML1048L3. (SESSION: 13333) 01/31/17 15:07:50 ANR0514I Session 13333 closed volume /opt/tivoli/tsm/server/backup/backup_gatr/DOM_PROD_DISK_- DEVCL/00002207.BFS. (SESSION: 13333) 01/31/17 15:07:50 ANR0403I Session 13333 ended for node MMP (VIDI MMP). (SESSION: 13333) 01/31/17 16:37:16 ANR8336I Verifying label of LTO volume ML1048L3 in drive AUTODRIVE2 (/dev/IBMtape1). (SESSION: 13333) 01/31/17 16:38:44 ANR8468I LTO volume ML1048L3 dismounted from drive AUTODRIVE2 (/dev/IBMtape1) in library AUTOLIB1. (SESSION: 13333)

Только вот не читает их обратно для клиента(

хм вроде все корректно

у меня такая версия Что если у вас доступен primary pool в каком виде ;Поставьте его принудительно в unavailable тогда клиенту останется только ломится только на копипул

• Ответ изменён 5 лет назад пользователем Demetrio .

Спасибо! Попробую в выходные. Можно еще сделать недоступный хотя бы один vol в unavailable

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

02/05/17 17:16:02 ANR2017I Administrator ADMIN issued command: UPDATE VOLUME A00004L3 access=unavailable (SESSION: 18) 02/05/17 17:20:42 ANR0406I Session 33 started for node MMP (VIDI MMP) (Tcp/Ip localhost(32826)). (SESSION: 33) 02/05/17 17:20:42 ANR8340I FILE volume /opt/tivoli/tsm/server/backup/backup- _gatr/DOM_PROD_DISK_DEVCL/00001DC2.BFS mounted. (SESSION: 33) 02/05/17 17:20:42 ANR0510I Session 33 opened input volume /opt/tivoli/tsm/server/backup/backup_gatr/DOM_PROD_DISK_- DEVCL/00001DC2.BFS. (SESSION: 33) 02/05/17 17:20:45 ANR0514I Session 33 closed volume /opt/tivoli/tsm/server/backup/backup_gatr/DOM_PROD_DISK_- DEVCL/00001DC2.BFS. (SESSION: 33) 02/05/17 17:20:45 ANR0403I Session 33 ended for node MMP (VIDI MMP). (SESSION: 33)

Вывод: надо было задисейблить все тома пула, на котором не работали приводы и тогда TSM начал бы восстанавливать данные из копипула…