У меня есть несколько старых лент SunOS, и мне нужно просмотреть их содержание, прежде чем я их уничтожу.
Есть ли Linux-решение для восстановления этих лент?
Если ленты в формате tar, вы можете попробовать
tar -tf /dev/sr0
Если файлы в формате cpio, тогда
cpio -ivtB </dev/sr0
может работать. Если ленты в формате ufsdump, вы можете попробовать использовать restore
restore -if /dev/st0
затем используйте ls и cd, чтобы посмотреть, что на них
Иан дал часть ответа, но она не была полной. Вот совет, как читать неизвестные ленты на хосте linux:
Фактор блокировки
Вам нужно знать, какой коэффициент блокировки был использован, если только (возможно, старый) диск не использует фиксированный размер блока. Во-первых, вам нужно настроить привод на использование коэффициента мягкой блокировки:
# mt -f /dev/nst0 setblk 0
Затем вы будете использовать dd для чтения блока с ленты:
dd if=/dev/nst0 of=./testfile bs=128k count=1
Возможно, вам придется попробовать блоки нескольких размеров, желательно что-то достаточно большое. Если выбранный размер блока dd больше, чем фактический размер блока ленты, dd будет читать только один блок, примерно так:
# dd if=/dev/nst0 of=./testfile bs=128k count=1
1+0 records read
1+0 records written
32768 bytes (32 kiB) copied, 236 kiB/s
Здесь мы обнаружили, что использовался размер блока 32 КБ, это первая важная информация. Примечание: если вы используете слишком большой размер блока, могут возникнуть различные странные ошибки, такие как ошибка ввода-вывода. Большинство старых ленточных накопителей не поддерживают чтение за один раз больше 128 Кбайт, а может быть, меньше для старых форматов, таких как QIC.
Формат данных
Теперь, когда вы определили размер блока ленты, пришло время выяснить, каков формат данных ленты! Здесь мы должны использовать драгоценный и мощный инструмент: file команда. Теперь нам нужно взять с ленты еще несколько блоков, чтобы определить, что легче:
# dd if=/dev/nst0 of=./testtape.img bs=32k count=100
100+0 records read
100+0 records written
3276800 bytes (3 MiB) copied, 160 kiB/s
# file ./testtape.img
testtape.img: POSIX tar archive (GNU)
Удобно, что файл будет правильно определять большинство данных tar, cpio, * dump, сжатых данных, избавляя вас от долгой игры проб и ошибок.
Предостережение
Ленты вполне могут содержать несколько различных форматов данных. Обычным случаем для лент, использующих формат без индекса (например, tar), является наличие текстового файла, в котором содержимое ленты перечисляется в качестве, например, первого файла или некоторых других подобных заголовков. Таким образом, вам может потребоваться прочитать несколько записей, прежде чем найти реальные данные.
Оказалось, что записи были написаны с использованием уникальной версии CPIO, которая существовала только в ранних версиях SunOS, я предполагаю SunOS 2 или 3. В то время, в начале 90-х (когда я был ковбоем, а не sysadmin), Auspex (SunOS) был важным элементом файловых серверов UNIX. Sun пыталась включить большие файлы (> 2 ГБ, также известные как BIG_FILE). Основа CPIO заключается в том, что первое поле из X бит в записи дампа CPIO - это количество байтов в этом INODE. Это все хорошо и прекрасно. За исключением того, что позже CPIO был стандартизирован в другом количестве байтов, чтобы представить счетчик байтов INODE.
Вы можете себе представить, какое веселье возникает, когда вашему имени файла предшествуют случайные биты, а количество байтов неверное.
Вы имеете в виду ленты системы SunOS или ленты, записанные на старой системе SunOS? Системные ленты начинаются с загрузочного образа, за которым следует оглавление (для чтения /usr/etc/install/xdrtoc), а затем отдельные пакеты в формате tar.gz, как указано в файле TOC. Вам нужно перейти к файлу, который вы хотите извлечь с помощью mt (например,. mt -f/dev/non-rewinding-tapedevice fsf чтобы перейти к следующему файлу)
Если вы хотите читать записи, написанные на старые системы SunOS, я бы использовал звезда, загружается с Sourceforge, поскольку он может читать более или менее любой формат tar (включая исторические версии), pax или cpio.
Для формата ufsdump использование ufsrestore было указано на предыдущем плакате.
Совет: в настоящее время содержимое этих старых лент, скорее всего, легко втискивается в доступную файловую систему. Чтобы уменьшить износ изношенной старой ленты, может быть хорошей идеей перемотать ленту, считывая один файл за другим в файлы для дальнейшего изучения. Просто не забудьте всегда используйте ленточное устройство без перемотки (например, nrst0 или любое другое ленточное устройство, указывающее на ваш накопитель), каждый раз, когда вы забудете эту крошечную деталь, вы начинаете с 0.
В прошлом это приводило ко многим неприятным ситуациям, таким как резервные копии, перезаписывающие их предшественник снова и снова на этой волшебной никогда не заполняющейся ленте, или восстановление, которое обнаруживало бы только часть данных, когда все были уверены, что должно быть несколько архивов. на ленте ...
(ссылки обновлены 17.06.2019)
Предполагая, что ленты были написаны с использованием tar, tar -tvf your-backup-file.tar распечатает список файлов и каталогов в архиве, не распаковывая их. Это по-прежнему подразумевает чтение всего архива с ленты, так что это займет много времени.
Возможно, вам потребуется установить драйверы для вашего конкретного стримера. Возможно, вы обновите свой вопрос, указав марку и модель своего ленточного накопителя. Программное обеспечение, используемое для резервного копирования, также может помочь, если вы это знаете.