Любой системный администратор предпочтет никогда не иметь дела с восстановлением файлов из резервной копии. Во-первых, в большинстве нормальных систем поломки случаются не каждый день, и поэтому опыта в восстановлении данных у большинства наших коллег мало или нет совсем. Во-вторых, поломки сами по себе создают массу неудобств и часто ведут к авральным работам служб технической поддержки. Поэтому счастлив тот системный администратор, чья система спроектирована так, чтобы обеспечить максимальную надежность хранения данных.
Надежность хранения подразумевает, что данные должны быть корректно сохранены на диск (или иной носитель), т.е. система всегда должна считать именно те данные, которые были записаны; данные, которые считываются несколько раз, всегда должны считываться одинаковым образом, и при сбое должна быть возможность восстановить исходные данные в том виде, в котором они сохранялись.
Кроме этого, при проектировании систем важно учитывать требуемую емкость носителей данных с тем, чтобы по мере накопления данных им хватало места в течение всей жизни системы.
Корректность сохранения данных на носитель и неизменность их состояния между считываниями (разумеется, при условии, что данные не требуют модификации) обеспечивается операционной системой. В случае, если носитель исправен, никаких дополнительных действий, связанных с обеспечением этих свойств данных, системный администратор предпринимать не должен.
Здесь уместно заметить, что системному администратору или проектировщику системы следует полагаться только на проверенные решения. Следующие несколько абзацев предназначены тем, кто планирует эксплуатировать Solaris на платформе x86, поскольку платформа Sun SPARC представляет собой более чем проверенное решение, за качество которого единственный его производитель, Sun Microsystems, ручается головой. Случаев жалоб на фирменное оборудование Sun в России мне слышать не приходилось. Коллеги из московского представительства: поправьте меня, если я не прав!
Итак, если перед вами стоит задача проектирования системы на платформе x86, постарайтесь учесть опыт (в том числе и печальный!) автора этих строк.
Во-первых, следует использовать ту аппаратуру, которая точно находится в
Во-вторых, следует всегда заботиться о совместимости аппаратуры и стараться эксплуатировать ее в щадящем режиме; например, не следует использовать мощность блока питания на 100%, не следует полагаться на те значения, которые написаны на наклейке этого блока питания – вполне возможно, что измерения покажут, что его фактическая мощность меньше в полтора раза.
В-третьих, жесткий диск должен быть произведен на заводе с хорошей репутацией; справьтесь у хорошо знакомого вам продавца и нескольких независимых экспертов, особенно занимающихся ремонтом жестких дисков, какие жесткие диски в данный момент считаются самыми надежными. Часто бывает, что какой-нибудь производитель выпускает отличные SCSI-диски на одном заводе и отвратительные IDE-диски – на другом под той же маркой. Избегайте привлекательных знакомых товарных знаков самих по себе – всегда интересуйтесь качеством именно того товара, который покупаете.
В-четвертых, НИКОГДА не пробуйте самые последние новинки в том оборудовании, которое должно выполнять какие-то жизненно важные функции. Если душа просит экспериментов, проведите их на том компьютере, крах которого никому не принесет слез или потерянных данных.
Помните о том, что кроме хорошей "начинки" вашему компьютеру требуется стабильное качественное электропитание и строго определенный температурный режим. Следовательно, надо подумать об источнике бесперебойного питания, честном заземлении, качественной вентиляции корпуса компьютера и вентиляции помещения, где будет установлен компьютер. В таком помещении не должно быть жарко, температура не должна сильно зависеть от погоды. Например, установка сервера в мансарде или на чердаке, где солнце сильно прогревает воздух сквозь металлическую крышу, чревата неожиданным резким перегревом оборудования.
Вокруг компьютеров не должно быть пыльно, корпуса следует располагать так, чтобы к ним всегда был удобный доступ, в том числе и для уборки. Провода имеет смысл наматывать в специальные органайзеры – такие бывают встроены в сетевые фильтры
Самодельные устройства, регулирующие напряжение в сети, оголенные провода, плохие контакты в розетках и старая проводка приводят, как ни странно, к пожарам. Автор был свидетелем нескольких пожаров, вызванных именно такими тривиальными причинами – поверьте, качеству проводки и электрооборудования надо уделить самое пристальное внимание при монтаже любой компьютерной системы.
Вот неполный список причин, по которым изначально исправные компьютеры чаще всего выходят из строя из-за недостатков планирования или плохого учета всех факторов при монтаже системы:
Все события, которые перечислены в этом списке, происходили в разных организациях на моих глазах в последние несколько лет, и будет странно, если по прочтении этой книги все читатели побегут перепланировать свои электросети и компьютерные системы. Гром не грянет – сами понимате что. Зато теперь вы предупреждены о последствиях. Если вы отвечаете за компьютерную систему крупного банка и все проблемы из списка давно предусмотрены и предотвращены – можно расслабиться. Должно быть, что-нибудь все равно произойдет, но хотя бы не из этого перечня.
Планируйте замену оборудования заранее! Сервер на платформе x86 не должен работать как часы в течение десятилетий; такое оборудование потребует полной замены через пять лет, более того, уже через год-два оно потеряет в цене половину. Если вы заботитесь не только о надежности работы системы, но и об экономической эффективности, следует планировать замену оборудования с продажей старого не реже, чем раз в два года.
К сегодяшнему дню не придумано более удобных средств хранения больших объемов данных, чем жесткие диски. Если говорить о накопителях, позволяющих с ними работать в режиме постоянного обмена данными с памятью компьютера, жесткие диски являются едва ли не единственными распространенными средствами хранения данных.
Для долговременного хранения и создания архивов по-прежнему применяют ленточные накопители (кассеты
Для повышения надежности систем хранения, основанных на жестких дисках, применяют RAID-массивы – аппаратуру, которая позволяет сохранять данные с той или иной степень избыточности. Solaris поддерживает аппаратуру RAID, за подробностями описания RAID-массивов можно обратиться к фирменной документации производителей (StorEdge и многие другие) или к доступным источникам в Интернете.
С точки зрения операционной системы, RAID-массив представляет собой просто один жесткий диск. То, что фактически такой массив состоит из многих (обычно пяти-семи) дисков и может обеспечивать возможность замены дисков "на лету", без выключения или перенастройки оборудования, скрыто от операционной системы и гарантируется аппаратурой самого RAID-массива. Такие массивы обычно присоединяются к шине SCSI и стоят достаточно дорого по сравнению с обычными дисками.
Для экономии средств вы можете отказаться от приобретения аппаратуры RAID. Solaris – начиная с самых ранних версий этой системы – предоставляет возможность организовать полноценный RAID-массив программно, с использованием нескольких жестких дисков и программы Solstice Disksuite. Эта программа дает возможность выполнять зеркалирование (RAID уровня 1), так же как и расслоение с избыточностью (запись блоков данных и блоков четности на разные диски – RAID уровня 5). Файловая система ZFS, которая поддерживается во всех версиях Solaris, начиная с Solaris 10, поддерживает не только программное зеркалирование и программный RAID-5, но и RAID с двойной избыточностью (см. команду zpool create raidz2 dev1 dev2 dev3 dev4 ).
В Solaris начиная с версии 8 Disksuite включен в состав системы, ранее его надо было устанавливать как отдельный пакет. Этот пакет – не единственный, позволяющий реализовать программный RAID в Solaris, но он пользуется популярностью у администраторов Solaris.
Solstice DiskSuite был переименован в Solaris Volume Manager при переходе от Solaris 8 к Solaris 9 и стал еще более тесно интегрирован в систему. Вызвать графическую оболочку Solaris Volume Manager можно из
Для создания зеркала или программного массива RAID 5 в SVM используйте команду metainit. Для проверки – metastat.
Подробное описание работы с SVM можно найти, например, по адресу http://sysunconfig.net/unixtips/soft-partitions.html.
Кроме SVM есть еще широко известный продукт Veritas Volume Manager (от компании Veritas Software), c ним можно познакомиться по адресу www.veritas.com.
Пользуйтесь современным инструментарием – если у вас Solaris 10, то ZFS поможет в надежном хранении данных!
Создание снимка файловой системы test/opt ; 19Mar08 – уникальное имя снимка:
zfs snapshot test/opt@19Mar08
Передача снимка на ленту (можно указать другое устройство, файл или перенаправить снимок на вход другой программе – в том числе для передачи по сети):
zfs send test/opt@19Mar08 > /dev/rmt
Прием снимка с ленты (можно указать любой другой источник, где хранится снимок):
zfs receive test/opt@19Mar08 < /dev/rmt
Откат файловой системы до состояния, в котором она была на момент снимка:
zfs rollback test/opt@19Mar08
Если возникла необходимость переноса дисковой подсистемы целиком из одного компьютера в другой (например, при выходе из строя материнской платы или другого компонента, который не удается быстро заменить на аналогичный), то пул ZFS можно перенести даже без сохранения порядка подключения устройств. Благодаря тому, что каждое устройство в пуле хранит информацию о своих "соседях", как бы вы ни подключили диски, пул ZFS будет работоспособен на новом компьютере. Таким образом можно переносить не только пулы, собранные из дисков, но и пулы, собранные из накопителей USB-флэш.
Для импорта пула ZFS в другую систему следует дать команду zpool import. Для вывода из работы пула в исправно работающей системе с целью его переноса в другоую систему, следует применить команду zpool export.
Так как файловая система ZFS спроектирована для корректной работы независимо от того, какой порядок бит в байте принят в архитектуре компьютера, допустим перенос пулов ZFS между компьютерами с разным порядком бит (например, между x86 и SPARC).
В разных системах UNIX могут использоваться разные системы контроля версий. Очень широко распространена
Что даст
Кроме этого, комментарии, которыми следует снабжать все файлы, помещаемые в репозиторий, помогут разобраться в смысле давно сделанных изменений и, при необходимости, установить их авторство. Согласитесь, системный администратор иногда очень хочет знать, кто из двух его помощников-стажеров изменил пароль босса и сам того не заметил... Система
Поскольку root и ответственной за резервное копирование роли.
Прежде всего, надо создать подкаталог
Основные команды программы
| Команда | Назначение |
|---|---|
create |
инициализация файла истории |
clean |
очистка текущего каталога |
deledit |
внесение изменений в репозиторий и извлечение файла |
delget |
внесение изменений в репозиторий и извлечение файла только для чтения |
delta |
внесение изменений в репозиторий |
edit |
извлечение файла |
enter |
инициализация файла истории |
get |
извлечение файла только для чтения |
info |
вывод полной информации о файле |
unedit |
возвращение файла к состоянию, в котором он был до последнего изменения |
Итак, начнем. Предположим, мы создаем репозиторий для файлов из каталога /usr/develop (пример c каталогом /etc так часто рассматривается в литературе, что мы сочли его банальным; если вы желаете сделать репозиторий для каталога /etc, просто замените все /usr/develop в нашем примере на /etc ).
cd /usr/develop mkdir SCCS
Теперь создаем файл истории проекта для файлов q и q1:
/usr/ccs/bin/sccs create q q1 q: No id keywords (cm7) q1: No id keywords (cm7) 1.1 2 lines No id keywords (cm7) 1.1 40 lines No id keywords (cm7)
Файлы оригиналов (т.е. того, что было до помещения файлов в репозиторий) сохраняются с именами, идентичными именам оригиналов, но с добавленной в начале запятой. Файлы истории предваряются префиксом s.:
ls -l SCCS total 6 -r--r--r-- 1 root other 155 Июн 26 16:01 s.q -r--r--r-- 1 root other 1877 Июн 26 16:01 s.q1 ls -l -rw-r--r-- 1 root other 7 Май 5 20:15 ,q -r--r--r-- 1 root other 7 Июн 26 16:01 q -rw-r--r-- 1 root other 1729 Июн 20 23:32 ,q1 -r--r--r-- 1 root other 1729 Июн 26 16:01 q1
Посмотрим содержимое файла q и попробуем его изменить.
Для редактирования файла следует его извлечь из репозитория; это делается командой
bash-2.05# /usr/ccs/bin/sccs edit q 1.1 new delta 1.2 2 lines
Посмотрим, как выглядит файл.
bash-2.05# cat q test
Отлично, выглядит по-прежнему. Если файл изменить, а затем дать команду извлечения из репозитория, сделанные изменения пропадут, файл будет прежним. Изменения в файл следует вносить только после того, как файл извлечен из репозитория для модификации. Добавим строку в конец файла:
bash-2.05# cat >> q test1
Теперь внесем изменения в файл истории в репозитории:
bash-2.05# /usr/ccs/bin/sccs delta q comments? new line added No id keywords (cm7) 1.2 1 inserted 0 deleted 2 unchanged
Если после внесения изменений в файл истории снова требуется изменить сам файл (в нашем случае – файл q ), то вместо delta следует указать подкоманду deledit, что эквивалентно последовательности команд
/usr/ccs/bin/sccs delta q /usr/ccs/bin/sccs edit q
Файл истории файла q в каталоге
h13611 s 00001/00000/00002 d D 1.2 04/06/26 16:12:03 root 2 1 c new line added e s 00002/00000/00000 d D 1.1 04/06/26 16:01:16 root 1 0 c date and time created 04/06/26 16:01:16 by root e u U f e 0 t T I 1 test I 2 test1 E 2 E 1
Как видно, в файле истории сохраняется информация о самих изменениях, а также о времени и авторе этих изменений.
Рассмотрим несколько возможных носителей для хранения копий данных. Они отличаются емкостью, скоростью записи и чтения, стоимостью, чувствительностью к внешним воздействиям.
Ленты (кассеты) – требуют использования накопителей на магнитной ленте. Емкость кассет обычно невелика, но самый современный формат
Идеальным носителем могли бы быть оптические компакт-диски (CD-R или DVD): скорость их записи заметно выше, чем скорость записи лент, скорость чтения сравнима со скоростью жестких дисков, они практически не подвержены внешним воздействиям (конечно, их не следует поджаривать или колотить, как и прочие носители, но зато электромагнитные поля им нипочем), хранить диски можно в штабелях, в конвертах, коробках и т.п., более того, их можно прочесть в любой операционной системе – от Windows до Mac, включая все разновидности UNIX. Одно плохо: пока на такие диски не научились записывать более 700 Мб (CD-R) или 4,7 Гбайт (DVD) – а это слишком мало для сохранения копий больших разделов. В последнее время на сцену вышли диски Blu-Ray, на которые можно записать до 54 Гб информации, и уже анонсированы первые результаты в проекте создания дисков объемом до 200 Гб. Согласно источнику http://www.gizmolovers.com/tag/solaris/ в конце 2007 года устройство для чтения дисков Blu Ray, совместимое с Solaris, стоило $429, а цены на устройства, записывающие диски Blu Ray, в июне 2008 стоили порядка $600 на ebay.com.
Jaz- и ZIP-диски. Обладают комбинацией недостатков лент и компактдисков, большого смысла рассматривать их как промышленное средство сохранения данных в настоящее время нет. Объем Jaz-диска – 2 Гб, ZIP-диска – 100 или 250 Мбайт.
Дискеты. Очень маленький полезный объем (1,44 Мбайта) компенсируется универсальностью: читаются повсюду, где есть дисковод. Чрезвычайно чуствительны к внешним магинтным полям: не рекомендуется, например, носить дискеты в портфеле рядом с мобильным телефоном. Качество современных дискет подстать их цене: из коробки ценой три доллара четыре дискеты из десяти легко окажутся бракованными еще до начала использования. Как средство хранения копий важных файлов лучше не рассматривать.
Флэш-память. Начиная с версии 8 Solaris стандартно поддерживает такой вид накопителей, хотя в некоторых случаях требуется установить обновление системы от Sun. Современные недорогие модели флэш-модулей, подключаемых к компьютеру по USB, имеют объем до 128 Мбайт. а более дорогие – до 1Гбайт. Можно использовать как хорошую замену дискетам и даже компакт-дискам. Этот носитель следует беречь от воздействия сильных магнитных полей и высокой температуры.
Наконец, жесткие диски. По-видимому, следует признать их лучшим вариантом на сегодняшний день, так как обеспечить регулярное копирование данных на второй жесткий диск или диск соседнего компьютера сравнительно просто (достаточно написать скрипт), а обеспечить оперативную замену вышедшего из строя диска на резервный не так уж и дорого. Кроме этого, жесткие диски с резервными копиями стоят ненамного дороже емких магнитных лент, зато они существенно быстрее и удобнее в использовании, поэтому их можно использовать не только для зеркалирования данных, но и для архивного хранения.
Для сжатия больших файлов в UNIX изначально использовалась программа compress. Она сжимала файл, после сжатия добавляла к имени файла .Z. Программа compress до сих пор поставляется практически со всеми диалектами UNIX. В IRIX и некоторых других системах она является стандартной утилитой сжатия. Чтобы вернуть файл, сжатый compress, к прежнему, несжатому состоянию, используется
В Linux и FreeBSD, а также во многих других диалектах для сжатия применяют gzip. Он использует тот же алгоритм сжатия LZW, что и WinZip или gzip, а gzip ее форматы не понимает. Для распаковки файлов, сжатых gzip, нужен gunzip. Большинство версий gzip не умеют сжимать каталоги с их содержимым – только файлы.
Есть еще утилиты zip и
Программа tar может применяться как для архивирования файлов на ленту, так и для создания архивов. Она собирает все указанные ей файлы в один большой файл. Имя файла tar никак не модифицирует. В UNIX принято, чтобы имя архива, соданного tar, заканчивалось на . tar. Об этом должен позаботиться тот, кто запускает tar, указав ей верное имя архива.
Затем удобно сжать получившийся файл с помощью gzip, чтобы он занимал меньше места. Многие дистрибутивы программных пакетов в UNIX упакованы tar и gzip. У команды tar даже есть ключ z. Он говорит tar, что после упаковки файлов в архив нужно вызвать gzip для сжатия. Такой же ключ используется и для распаковки, когда tar перед тем, как начать свою работу, вызывает gunzip.
Например, мне нужно упаковать дистрибутив apache, который лежит в /home/apache:
cd /home tar cvzf apache.tar.gz apache/*
Всего три команды в UNIX принимают (и в некоторых версиях – требуют) ключи без знака "минус" перед ними. Это ps, dump и tar. Мы использовали для создания архива следующие ключи:
с – create – создать архив;v – verbose mode – выводить имена всех пакуемых фалов на экран;z – zip – после упаковки вызвать gzip для сжатия;f – file – записать результат в файл, который указан после ключа f, а не на первый ленточный накопитель, как по умолчанию.apache.tar.gz – это имя архива, а apache/* – то, что надо упаковать.
Лучше всего запаковывать целый каталог, а не входить в него и паковать содержимое, вот так:
# так делать не надо cd /home/apache tar cvzf apache.tar.gz *
Архив так тоже можно создать, но при распаковке он рухнет всеми своими сотнями файлов и подкаталогов в тот каталог, где он будет распаковываться. Это неудобно, и так не принято. Дурной тон. Намного вежливее и красивее упаковать сразу целый каталог, как в предыдущем примере. Тогда по команде
tar xzvf apache.tar.gz
в том каталоге, где лежит архив, создастся подкаталог apache (помните, там было сказано "apache/*"?). И уже в него будут распакованы все файлы и подкаталоги архива. В этой команде tar мы использовали один незнакомый ключ – x. Он требует распаковать архив.
Для сжатия архивов можно применять как gzip, так и compress – более старую утилиту из древних систем UNIX. Результатом выполнения команды сжатия файла data.txt compress data.txt будет файл data.txt.Z. При применении gzip результат будет в среднем лучше, так как этот архиватор обычно сжимает файлы сильнее. При этом он дописывает к имени сжатого файла суффикс .gz. В обоих случаях исходный (несжатый) файл исчезает, остается только сжатый файл. Надо помнить, что при нехватке места на диске архив не может быть создан, так как несжатый исходный файл удаляется только после его успешного сжатия и переименования временного сжатого файла в окончательный результат.
Для декомпрессии файлов, сжатых утилитами compress и gzip используйте gunzip соответственно. В некоторых версиях UNIX используется еще более новый архиватор bzip2 (и де-компрессор bunzip2 ), но в Solaris он пока еще не портирован.
Для копирования целых устройств в их образы (например, дискет или компакт-дисков) и обратно служит программа dd. С ее помощью также можно копировать целые разделы дисков. Обычный формат вызова этой программы таков:
dd if=/dev/fd0 of=/usr/home/admin/diskettes/image1
Фактически, dd расценивает то, что она копирует, как блоки произвольных данных указанной длины (используется разумное умолчание в 512 байтов). Использовать dd можно тогда, когда следует иметь две или более резервные копии: первую копию на ленту записывают с помощью программы ufsdump, а остальные создают копированием с ленты на ленту программой dd:
dd if=/dev/rmt/0h of=/dev/rmt/2h
Нельзя использовать эту программу для копирования файлов с одной файловой системы на другую, если размер блоков этих файловых ситстем разный.
При копировании файлов, расположенных на блочных устройствах, последний копируемый блок может быть дополнен нулями от конца области данных до конца блока.
Команда cpio служит для копирования файлов в архив и из архива и умеет работать в трех режимах: входящего копирования, исходящего копирования и пассивного копирования. Режим исходящего копирования (копирования в архив, Copy Out Mode) применяется для создания архива из файлов, подходящих по маске. Так, для архивации файлов, чьи имена начинаются с q, можно использовать такую последовательность команд:
ls q* | cpio -oc >Q/sccs.backup 16 blocks cd Q ls sccs.backup
Файл результата состоит из заголовка и записанного вслед за ним имен и содержимого архивируемых файлов. Сжатия информации не производится. Так выглядит начало получившегося файла
head sccs.backup 070701000020fc0000812400000000000000010000000140dd6ab7000000120000 00660000000700000000000000000000000200000005q test1
Применим входящее копирование (т.е. копирование из архива, Copy In Mode) для извлечения из архива определенных файлов, в нашем примере – файла q:
ls sccs.backup cat sccs.backup | cpio -i q 4 blocks ls q sccs.backup
mv. В этом режиме cpio читает список файлов со стандартного ввода и копирует эти файлы в указанный каталог (дерево каталогов).
Фактически, cpio всегда принимает список файлов со стандартного ввода (кроме случая входящего копирования). Ключи, которые описаны в man cpio, предписывают программе особенности поведения, такие, как создание подкаталогов по необходимости и т.п.
Одним из самых мощных иструментов копирования и синхронизации содержимого географически удаленных файлов и каталогов является программа rsync. Она должна быть знакома вам по другим системам UNIX.
Можно применять rsync для работы поверх ssh или для самостоятельной работы в режиме клиент-сервер. В последнем случае потребуется на одной из сторон копирования запустить сервер rsync, который запускается командой rsync с ключом --daemon. Для запуска rsync в режиме сервера следует вначале создать и наполнить осмысленным содержанием файл /etc/rsyncd.conf, в котором указывается, какие каталоги и с какими правами доступа к ним сервер rsync позволит видеть снаружи.
Основное преимущество rsync перед всеми остальными способами копирования файлов в том, что rsync не передает файлы целиком, если в этом нет необходимости. Так, при синхронизации каталогов, содержащих файлы большого объема (сотни мегабайт, например), rsync обменивается с удаленным сервером контрольными суммами, посчитанными по блокам данных внутри файла, и при совпадении контрольных сумм и размеров блоков не выполняет пересылку блока, который одинаков на обеих сторонах.
Для копирования файлов с компьютера remote из каталога src/bar на локальный комптютер в каталог /data/tmp дать команду
rsync -avz remote:src/bar /data/tmp
А для того, чтобы передать с компьтера remote из каталога /data/important все файлы в каталог /data/remote/backup на локальном компьтютере с использованием ssh (фактически, поверх ssh ) следует дать команду
rsync -e ssh -avz remote:/data/important /data/remote/backup
При этом на компьютере remote должен быть доступен для запуска ssh и вы должны будете корректно аутентифицировать себя (ввести пароль) для выполнения команды.
В большинстве систем UNIX для резервного копирования файловых систем на ленту и восстановления файлов с ленты применяются программы dump и restore. В Solaris для этой же цели для файловых систем UFS используют собственные программы ufsdump и ufsrestore. Принципиальной разницы между общепринятым вариантом и специфичным для Solaris нет, программы dump, ufsdump занимаются резервным копированием данных, а restore и ufsrestore – восстановлением данных (т.е. переписыванием файлов с ленты на диск). Программы, применяющиеся в Solaris, обладают несколько большей функциональностью, например, позволяют выполнять копирование файлов на дискету (ключ D ), в то время как dump/restore работают только с ленточными накопителями.
В данном разделе мы рассмотрим только общие особенности этих программ, поэтому материал раздела применим не только к системе Solaris, но и к другим системам UNIX.
По умолчанию ufsdump и ufsrestore работают с первым стримером в системе. Несмотря на это, хорошим тоном считается явное указание устройства, на которое мы хотим выполнить резервное копирование. Это страхует нас от неприятных сюрпризов, таких, как неожиданная перемотка ленты в конце копирования или попытка копирования на носитель, который не вставлен в
Программа ufsdump выполняет копирование файловой системы целиком, ее можно, но не следует применять для копирования отдельных каталогов.
Она может выполнять копирование не только на ленту, но и в файл на диске, а также на дискету. При копировании информации на жесткий диск более разумно использовать обычные утилиты копирования типа cp или специализированные типа tar или rsync (если нужно выполнить копирование на удаленный компьютер).
Следует обязательно указывать уровень копирования при копировании на ленту. Программа ufsdump позволяет задать 10 уровней с 0 до 9. Уровень 0 – это копирование всей файловой системы целиком.
При копировании уровня n копируются все файлы, которые были изменены с момента последнего копирования уровня n или уровня с меньшим номером.
Уровни копирования введены для того, чтобы инкрементное копирование, т.е. копирование только измененных файлов, было легче организовать. Оно экономит место на ленте и время, затрачиваемое на резервное копирование. Обратной стороной медали в данном случае является большее время восстановления данных, так как если файловая система была сохранена полностью три дня назад, а вчера и позавчера выполнялось инкрементное копирование, при восстановлении придется задействовать три кассеты – чтобы восстановить файловую систему по состоянию на момент последнего резервного копирования. Если время позволяет, а свободное место на ленте заведомо превышает объем копируемых данных, удобнее всегда делать полное копирование выбранной файловой системы. В таком случае, когда бы ни произошел сбой, всегда хватит одной-единственной кассеты – самой свежей – чтобы полностью восстановить файловую систему.
Планируя схему резервного копирования, помните, что при инкрементном копировании для восстановления после сбоя придется последовательно считывать все ленты, начиная с последнего дампа нулевого уровня. Кроме затрат времени и кассет на такое копирование, после восстановления возникнут уже удаленные файлы, которые удалялись после дампа нулевого уровня: программа восстановления файлов не имеет информации о том, что какие-то файлы были удалены, потому что резервное копирование выполнялось до удаления этих файлов.
При нехватке места на ленте или диске, на которые производится резервное копирование, ufsdump предупредит об этом и попросит вставить в используемое для копирования устройство новый носитель (кассету с лентой). Конец ленты вызывает передачу сигнала от накопителя системе. Если ufsdump размер носителя в килобайтах явным образом.
Программа ufsdump позволяет задавать плотность записи на ленту. Плотность записи зависит только от типа и модели
За многие годы существования многопользовательских операционных систем было разработано множество схем резервного копирования, направленных на оптимизацию времени восстановления файловой системы, времени выполнения резервного копирования, количества используемых в цикле копирования лент и, наконец, всех этих параметров одновременно. Описание этих схем лежит вне рамок наших лекций, с теорией резервного копирования вы легко познакомитесь в Интренете, если это понадобится вам. На практике нам следует уместь выполнять основные действия, связанные с резервным копированием файловых систем.
Весьма часто применяется регулярное полное (уровня 0) резервное копирование раздела с важной информацией, что требует размещения важной информации на одном разделе.
Однозначно НЕ СЛЕДУЕТ выполнять резервное копирование разделов, где расположены временные файлы, файлы протоколов (если только протоколы не представляют ценности для вашей организации), дистрибутив системы или файлы приложений, которые легко установить из дистрибутива.
Резервные копии всегда следует хранить отдельно от пустых (чистых) кассет, и лучше всего – в надежном месте за пределами здания организации, по соображениям пожарной безопасности в том числе.
Синтаксис команды ufsdump отличается от синтаксиса большинства команд UNIX:
ufsdump [[ключи] [аргументы]] файловая_система
Сначала в командной строке друг за другом без пробелов указываются все ключи подряд, БЕЗ знака "минус" перед ними. Затем, через пробел, в том же порядке, что и ключи, указываются аргументы, относящиеся к этим ключам, например:
/usr/sbin/ufsdump 0ufBds /dev/rmt/0n 4194304 62000 1500 /var
Это означает дамп уровня 0 (ключ 0), с обновлением файла /etc/dumpdates (u), на устройство ( f, файл) /dev/rmt/0n, размер тома (т.е. картриджа, кассеты, – В) – 4 194 304 килобайта (т.е 4 гигабайта), плотность записи (d) 62000 бит на дюйм (bit per inch – файловая_система обязателен, в то время как все остальные аргументы могут быть приняты по умолчанию, а какую именно файловую систему копировать, надо решать Вам. Полагаться на умолчание не рекомендуется: указывайте параметры явно – так надежнее.
Конкретные параметры кассет и
Если вы настраиваете сеть, в которой работают несколько разных систем UNIX, не забывайте о некоторых отличиях Solaris и других систем. В частности, в версиях FreeBSD 4.х и выше программа dump принимает и вышеописанные ключи, и более стандартную форму ключей (со знаком "минус" и указанием значения параметра сразу после ключа). Таблица 11.2 описывает конвенцию именования файлов устройств стримеров в разных системах UNIX.
| ОС | С перемоткой | Без перемотки |
|---|---|---|
| FreeBSD | /dev/rsa# | /dev/nrsa# |
| Linux | /dev/st# | /dev/nst# |
| Solaris | /dev/rmt/#l | /dev/rmt/#n |
В любой системе UNIX каждый ленточный накопитель представлен двумя файлами устройств – с перемоткой ленты в конце записи и без перемотки. Вы можете записать на одну кассету несколько разных файловых систем или несколько последовательных резервных копий одной системы. Для этого надо в качестве устройства для записи указывать файл устройства без перемотки ленты в конце записи. Используйте эту возможность осторожно и всегда записывайте, какие именно файловые системы, в каком порядке и когда были сохранены. Обратите внимание: по умолчанию dump/ufsdum p выбирает устройство с перемоткой.
Названия устройств могут быть другими, в зависимости от типа # ) обозначает номер
Когда вы решите, что резервное копирование должно прочно войти в жизнь вашей компании, обязательно закупите достаточное количество кассет (иначе их называют картриджами, по сути дела это – специальные кассеты с магнитной лентой) для создания резервных копий.
Запись нескольких копий на одну ленту "от бедности" ведет к снижению надежности в несколько раз. Перед восстановлением данных вы можете забыть перемотать ленту и в результате сотрете нужные и еще целые данные вместо потерянных!
Маркируйте кассеты после выполнения копирования, к каждой из них не зря прилагается липкий стикер. Не играйте в плохую игру с памятью: вы будете помнить о том, что где записано, неделю, а резервная копия может понадобиться через 10 дней...
Программа ufsdump, если задать ключ u, будет обновлять файл /etc/dumpdates, это полезная возможность, пользуйтесь ею! В этом файле в случае успешного завершения копирования появится новая строка с описанием того, что, с какими параметрами и на какое устройство было скопировано. Потом эти сведения могут оказаться важными, если данные и в самом деле придется восстанавливать.
Каждый системный администратор в душе когда-то раньше надеялся, что резервное копирование – это пустая трата времени и данные никогда не придется восстанавливать. Несмотря на это, суровая правда жизни заставляет нас изучить и процедуру восстановления данных – конечно же, просто на всякий случай.
Восстановление данных, записанных программой ufsdump, производится командой ufsrestore. Ей можно указать, в какой каталог восстанавливать данные. Это сделано для того, чтобы при необходимости указать новый каталог вместо прежнего, например, при крахе файловой системы.
Следует своевременно удалять восстановленные файлы из временных каталогов, если Вы их уже перенесли по месту постоянной дисклокации, чтобы не занимать лишнего пространства забытыми файлами!
При записи нескольких файловых систем на одну кассету (помните: это не рекомендуется!) на кассете образуется несколько томов (volumes). Так как ни ufsdump, ни restore не умеют искать нужный том, важно знать, как самостоятельно отыскать требуемый том. На кассете должно быть написано вашей рукой (рука вашего ассистента или предшественника тоже подойдет), в каком порядке и что именно на ней записано. Для перемотки ленты до нужного тома надо использовать команду mt.
Программа mt оперирует понятием файла (перемотать ленту на файл вперед, на два файла назад). При записи на ленту программой ufsdump таким "файлом" будет целый том (файловая система), пусть слово "файл" здесь не вводит вас в заблуждение.
Кроме ufsdump, данные на ленту можно записывать с помощью программы tar, речь о которой шла выше: она записывает целоый каталог или группу файлов в один архив.
Любой системный администратор предпочтет никогда не иметь дела с восстановлением файлов из резервной копии. Во-первых, в большинстве нормальных систем поломки случаются не каждый день, и поэтому опыта в восстановлении данных у большинства наших коллег мало или нет совсем. Во-вторых, поломки сами по себе создают массу неудобств и часто ведут к авральным работам служб технической поддержки. Поэтому счастлив тот системный администратор, чья система спроектирована так, чтобы обеспечить максимальную надежность хранения данных.
Надежность хранения подразумевает, что данные должны быть корректно сохранены на диск (или иной носитель), т.е. система всегда должна считать именно те данные, которые были записаны; данные, которые считываются несколько раз, всегда должны считываться одинаковым образом, и при сбое должна быть возможность восстановить исходные данные в том виде, в котором они сохранялись.
Кроме этого, при проектировании систем важно учитывать требуемую емкость носителей данных с тем, чтобы по мере накопления данных им хватало места в течение всей жизни системы.
Корректность сохранения данных на носитель и неизменность их состояния между считываниями (разумеется, при условии, что данные не требуют модификации) обеспечивается операционной системой. В случае, если носитель исправен, никаких дополнительных действий, связанных с обеспечением этих свойств данных, системный администратор предпринимать не должен.
Здесь уместно заметить, что системному администратору или проектировщику системы следует полагаться только на проверенные решения. Следующие несколько абзацев предназначены тем, кто планирует эксплуатировать Solaris на платформе x86, поскольку платформа Sun SPARC представляет собой более чем проверенное решение, за качество которого единственный его производитель, Sun Microsystems, ручается головой. Случаев жалоб на фирменное оборудование Sun в России мне слышать не приходилось. Коллеги из московского представительства: поправьте меня, если я не прав!
Итак, если перед вами стоит задача проектирования системы на платформе x86, постарайтесь учесть опыт (в том числе и печальный!) автора этих строк.
Во-первых, следует использовать ту аппаратуру, которая точно находится в
Во-вторых, следует всегда заботиться о совместимости аппаратуры и стараться эксплуатировать ее в щадящем режиме; например, не следует использовать мощность блока питания на 100%, не следует полагаться на те значения, которые написаны на наклейке этого блока питания – вполне возможно, что измерения покажут, что его фактическая мощность меньше в полтора раза.
В-третьих, жесткий диск должен быть произведен на заводе с хорошей репутацией; справьтесь у хорошо знакомого вам продавца и нескольких независимых экспертов, особенно занимающихся ремонтом жестких дисков, какие жесткие диски в данный момент считаются самыми надежными. Часто бывает, что какой-нибудь производитель выпускает отличные SCSI-диски на одном заводе и отвратительные IDE-диски – на другом под той же маркой. Избегайте привлекательных знакомых товарных знаков самих по себе – всегда интересуйтесь качеством именно того товара, который покупаете.
В-четвертых, НИКОГДА не пробуйте самые последние новинки в том оборудовании, которое должно выполнять какие-то жизненно важные функции. Если душа просит экспериментов, проведите их на том компьютере, крах которого никому не принесет слез или потерянных данных.
Помните о том, что кроме хорошей "начинки" вашему компьютеру требуется стабильное качественное электропитание и строго определенный температурный режим. Следовательно, надо подумать об источнике бесперебойного питания, честном заземлении, качественной вентиляции корпуса компьютера и вентиляции помещения, где будет установлен компьютер. В таком помещении не должно быть жарко, температура не должна сильно зависеть от погоды. Например, установка сервера в мансарде или на чердаке, где солнце сильно прогревает воздух сквозь металлическую крышу, чревата неожиданным резким перегревом оборудования.
Вокруг компьютеров не должно быть пыльно, корпуса следует располагать так, чтобы к ним всегда был удобный доступ, в том числе и для уборки. Провода имеет смысл наматывать в специальные органайзеры – такие бывают встроены в сетевые фильтры
Самодельные устройства, регулирующие напряжение в сети, оголенные провода, плохие контакты в розетках и старая проводка приводят, как ни странно, к пожарам. Автор был свидетелем нескольких пожаров, вызванных именно такими тривиальными причинами – поверьте, качеству проводки и электрооборудования надо уделить самое пристальное внимание при монтаже любой компьютерной системы.
Вот неполный список причин, по которым изначально исправные компьютеры чаще всего выходят из строя из-за недостатков планирования или плохого учета всех факторов при монтаже системы:
Все события, которые перечислены в этом списке, происходили в разных организациях на моих глазах в последние несколько лет, и будет странно, если по прочтении этой книги все читатели побегут перепланировать свои электросети и компьютерные системы. Гром не грянет – сами понимате что. Зато теперь вы предупреждены о последствиях. Если вы отвечаете за компьютерную систему крупного банка и все проблемы из списка давно предусмотрены и предотвращены – можно расслабиться. Должно быть, что-нибудь все равно произойдет, но хотя бы не из этого перечня.
Планируйте замену оборудования заранее! Сервер на платформе x86 не должен работать как часы в течение десятилетий; такое оборудование потребует полной замены через пять лет, более того, уже через год-два оно потеряет в цене половину. Если вы заботитесь не только о надежности работы системы, но и об экономической эффективности, следует планировать замену оборудования с продажей старого не реже, чем раз в два года.
К сегодяшнему дню не придумано более удобных средств хранения больших объемов данных, чем жесткие диски. Если говорить о накопителях, позволяющих с ними работать в режиме постоянного обмена данными с памятью компьютера, жесткие диски являются едва ли не единственными распространенными средствами хранения данных.
Для долговременного хранения и создания архивов по-прежнему применяют ленточные накопители (кассеты
Для повышения надежности систем хранения, основанных на жестких дисках, применяют RAID-массивы – аппаратуру, которая позволяет сохранять данные с той или иной степень избыточности. Solaris поддерживает аппаратуру RAID, за подробностями описания RAID-массивов можно обратиться к фирменной документации производителей (StorEdge и многие другие) или к доступным источникам в Интернете.
С точки зрения операционной системы, RAID-массив представляет собой просто один жесткий диск. То, что фактически такой массив состоит из многих (обычно пяти-семи) дисков и может обеспечивать возможность замены дисков "на лету", без выключения или перенастройки оборудования, скрыто от операционной системы и гарантируется аппаратурой самого RAID-массива. Такие массивы обычно присоединяются к шине SCSI и стоят достаточно дорого по сравнению с обычными дисками.
Для экономии средств вы можете отказаться от приобретения аппаратуры RAID. Solaris – начиная с самых ранних версий этой системы – предоставляет возможность организовать полноценный RAID-массив программно, с использованием нескольких жестких дисков и программы Solstice Disksuite. Эта программа дает возможность выполнять зеркалирование (RAID уровня 1), так же как и расслоение с избыточностью (запись блоков данных и блоков четности на разные диски – RAID уровня 5). Файловая система ZFS, которая поддерживается во всех версиях Solaris, начиная с Solaris 10, поддерживает не только программное зеркалирование и программный RAID-5, но и RAID с двойной избыточностью (см. команду zpool create raidz2 dev1 dev2 dev3 dev4 ).
В Solaris начиная с версии 8 Disksuite включен в состав системы, ранее его надо было устанавливать как отдельный пакет. Этот пакет – не единственный, позволяющий реализовать программный RAID в Solaris, но он пользуется популярностью у администраторов Solaris.
Solstice DiskSuite был переименован в Solaris Volume Manager при переходе от Solaris 8 к Solaris 9 и стал еще более тесно интегрирован в систему. Вызвать графическую оболочку Solaris Volume Manager можно из
Для создания зеркала или программного массива RAID 5 в SVM используйте команду metainit. Для проверки – metastat.
Подробное описание работы с SVM можно найти, например, по адресу http://sysunconfig.net/unixtips/soft-partitions.html.
Кроме SVM есть еще широко известный продукт Veritas Volume Manager (от компании Veritas Software), c ним можно познакомиться по адресу www.veritas.com.
Пользуйтесь современным инструментарием – если у вас Solaris 10, то ZFS поможет в надежном хранении данных!
Создание снимка файловой системы test/opt ; 19Mar08 – уникальное имя снимка:
zfs snapshot test/opt@19Mar08
Передача снимка на ленту (можно указать другое устройство, файл или перенаправить снимок на вход другой программе – в том числе для передачи по сети):
zfs send test/opt@19Mar08 > /dev/rmt
Прием снимка с ленты (можно указать любой другой источник, где хранится снимок):
zfs receive test/opt@19Mar08 < /dev/rmt
Откат файловой системы до состояния, в котором она была на момент снимка:
zfs rollback test/opt@19Mar08
Если возникла необходимость переноса дисковой подсистемы целиком из одного компьютера в другой (например, при выходе из строя материнской платы или другого компонента, который не удается быстро заменить на аналогичный), то пул ZFS можно перенести даже без сохранения порядка подключения устройств. Благодаря тому, что каждое устройство в пуле хранит информацию о своих "соседях", как бы вы ни подключили диски, пул ZFS будет работоспособен на новом компьютере. Таким образом можно переносить не только пулы, собранные из дисков, но и пулы, собранные из накопителей USB-флэш.
Для импорта пула ZFS в другую систему следует дать команду zpool import. Для вывода из работы пула в исправно работающей системе с целью его переноса в другоую систему, следует применить команду zpool export.
Так как файловая система ZFS спроектирована для корректной работы независимо от того, какой порядок бит в байте принят в архитектуре компьютера, допустим перенос пулов ZFS между компьютерами с разным порядком бит (например, между x86 и SPARC).
В разных системах UNIX могут использоваться разные системы контроля версий. Очень широко распространена
Что даст
Кроме этого, комментарии, которыми следует снабжать все файлы, помещаемые в репозиторий, помогут разобраться в смысле давно сделанных изменений и, при необходимости, установить их авторство. Согласитесь, системный администратор иногда очень хочет знать, кто из двух его помощников-стажеров изменил пароль босса и сам того не заметил... Система
Поскольку root и ответственной за резервное копирование роли.
Прежде всего, надо создать подкаталог
Основные команды программы
| Команда | Назначение |
|---|---|
create |
инициализация файла истории |
clean |
очистка текущего каталога |
deledit |
внесение изменений в репозиторий и извлечение файла |
delget |
внесение изменений в репозиторий и извлечение файла только для чтения |
delta |
внесение изменений в репозиторий |
edit |
извлечение файла |
enter |
инициализация файла истории |
get |
извлечение файла только для чтения |
info |
вывод полной информации о файле |
unedit |
возвращение файла к состоянию, в котором он был до последнего изменения |
Итак, начнем. Предположим, мы создаем репозиторий для файлов из каталога /usr/develop (пример c каталогом /etc так часто рассматривается в литературе, что мы сочли его банальным; если вы желаете сделать репозиторий для каталога /etc, просто замените все /usr/develop в нашем примере на /etc ).
cd /usr/develop mkdir SCCS
Теперь создаем файл истории проекта для файлов q и q1:
/usr/ccs/bin/sccs create q q1 q: No id keywords (cm7) q1: No id keywords (cm7) 1.1 2 lines No id keywords (cm7) 1.1 40 lines No id keywords (cm7)
Файлы оригиналов (т.е. того, что было до помещения файлов в репозиторий) сохраняются с именами, идентичными именам оригиналов, но с добавленной в начале запятой. Файлы истории предваряются префиксом s.:
ls -l SCCS total 6 -r--r--r-- 1 root other 155 Июн 26 16:01 s.q -r--r--r-- 1 root other 1877 Июн 26 16:01 s.q1 ls -l -rw-r--r-- 1 root other 7 Май 5 20:15 ,q -r--r--r-- 1 root other 7 Июн 26 16:01 q -rw-r--r-- 1 root other 1729 Июн 20 23:32 ,q1 -r--r--r-- 1 root other 1729 Июн 26 16:01 q1
Посмотрим содержимое файла q и попробуем его изменить.
Для редактирования файла следует его извлечь из репозитория; это делается командой
bash-2.05# /usr/ccs/bin/sccs edit q 1.1 new delta 1.2 2 lines
Посмотрим, как выглядит файл.
bash-2.05# cat q test
Отлично, выглядит по-прежнему. Если файл изменить, а затем дать команду извлечения из репозитория, сделанные изменения пропадут, файл будет прежним. Изменения в файл следует вносить только после того, как файл извлечен из репозитория для модификации. Добавим строку в конец файла:
bash-2.05# cat >> q test1
Теперь внесем изменения в файл истории в репозитории:
bash-2.05# /usr/ccs/bin/sccs delta q comments? new line added No id keywords (cm7) 1.2 1 inserted 0 deleted 2 unchanged
Если после внесения изменений в файл истории снова требуется изменить сам файл (в нашем случае – файл q ), то вместо delta следует указать подкоманду deledit, что эквивалентно последовательности команд
/usr/ccs/bin/sccs delta q /usr/ccs/bin/sccs edit q
Файл истории файла q в каталоге
h13611 s 00001/00000/00002 d D 1.2 04/06/26 16:12:03 root 2 1 c new line added e s 00002/00000/00000 d D 1.1 04/06/26 16:01:16 root 1 0 c date and time created 04/06/26 16:01:16 by root e u U f e 0 t T I 1 test I 2 test1 E 2 E 1
Как видно, в файле истории сохраняется информация о самих изменениях, а также о времени и авторе этих изменений.
Рассмотрим несколько возможных носителей для хранения копий данных. Они отличаются емкостью, скоростью записи и чтения, стоимостью, чувствительностью к внешним воздействиям.
Ленты (кассеты) – требуют использования накопителей на магнитной ленте. Емкость кассет обычно невелика, но самый современный формат
Идеальным носителем могли бы быть оптические компакт-диски (CD-R или DVD): скорость их записи заметно выше, чем скорость записи лент, скорость чтения сравнима со скоростью жестких дисков, они практически не подвержены внешним воздействиям (конечно, их не следует поджаривать или колотить, как и прочие носители, но зато электромагнитные поля им нипочем), хранить диски можно в штабелях, в конвертах, коробках и т.п., более того, их можно прочесть в любой операционной системе – от Windows до Mac, включая все разновидности UNIX. Одно плохо: пока на такие диски не научились записывать более 700 Мб (CD-R) или 4,7 Гбайт (DVD) – а это слишком мало для сохранения копий больших разделов. В последнее время на сцену вышли диски Blu-Ray, на которые можно записать до 54 Гб информации, и уже анонсированы первые результаты в проекте создания дисков объемом до 200 Гб. Согласно источнику http://www.gizmolovers.com/tag/solaris/ в конце 2007 года устройство для чтения дисков Blu Ray, совместимое с Solaris, стоило $429, а цены на устройства, записывающие диски Blu Ray, в июне 2008 стоили порядка $600 на ebay.com.
Jaz- и ZIP-диски. Обладают комбинацией недостатков лент и компактдисков, большого смысла рассматривать их как промышленное средство сохранения данных в настоящее время нет. Объем Jaz-диска – 2 Гб, ZIP-диска – 100 или 250 Мбайт.
Дискеты. Очень маленький полезный объем (1,44 Мбайта) компенсируется универсальностью: читаются повсюду, где есть дисковод. Чрезвычайно чуствительны к внешним магинтным полям: не рекомендуется, например, носить дискеты в портфеле рядом с мобильным телефоном. Качество современных дискет подстать их цене: из коробки ценой три доллара четыре дискеты из десяти легко окажутся бракованными еще до начала использования. Как средство хранения копий важных файлов лучше не рассматривать.
Флэш-память. Начиная с версии 8 Solaris стандартно поддерживает такой вид накопителей, хотя в некоторых случаях требуется установить обновление системы от Sun. Современные недорогие модели флэш-модулей, подключаемых к компьютеру по USB, имеют объем до 128 Мбайт. а более дорогие – до 1Гбайт. Можно использовать как хорошую замену дискетам и даже компакт-дискам. Этот носитель следует беречь от воздействия сильных магнитных полей и высокой температуры.
Наконец, жесткие диски. По-видимому, следует признать их лучшим вариантом на сегодняшний день, так как обеспечить регулярное копирование данных на второй жесткий диск или диск соседнего компьютера сравнительно просто (достаточно написать скрипт), а обеспечить оперативную замену вышедшего из строя диска на резервный не так уж и дорого. Кроме этого, жесткие диски с резервными копиями стоят ненамного дороже емких магнитных лент, зато они существенно быстрее и удобнее в использовании, поэтому их можно использовать не только для зеркалирования данных, но и для архивного хранения.
Для сжатия больших файлов в UNIX изначально использовалась программа compress. Она сжимала файл, после сжатия добавляла к имени файла .Z. Программа compress до сих пор поставляется практически со всеми диалектами UNIX. В IRIX и некоторых других системах она является стандартной утилитой сжатия. Чтобы вернуть файл, сжатый compress, к прежнему, несжатому состоянию, используется
В Linux и FreeBSD, а также во многих других диалектах для сжатия применяют gzip. Он использует тот же алгоритм сжатия LZW, что и WinZip или gzip, а gzip ее форматы не понимает. Для распаковки файлов, сжатых gzip, нужен gunzip. Большинство версий gzip не умеют сжимать каталоги с их содержимым – только файлы.
Есть еще утилиты zip и
Программа tar может применяться как для архивирования файлов на ленту, так и для создания архивов. Она собирает все указанные ей файлы в один большой файл. Имя файла tar никак не модифицирует. В UNIX принято, чтобы имя архива, соданного tar, заканчивалось на . tar. Об этом должен позаботиться тот, кто запускает tar, указав ей верное имя архива.
Затем удобно сжать получившийся файл с помощью gzip, чтобы он занимал меньше места. Многие дистрибутивы программных пакетов в UNIX упакованы tar и gzip. У команды tar даже есть ключ z. Он говорит tar, что после упаковки файлов в архив нужно вызвать gzip для сжатия. Такой же ключ используется и для распаковки, когда tar перед тем, как начать свою работу, вызывает gunzip.
Например, мне нужно упаковать дистрибутив apache, который лежит в /home/apache:
cd /home tar cvzf apache.tar.gz apache/*
Всего три команды в UNIX принимают (и в некоторых версиях – требуют) ключи без знака "минус" перед ними. Это ps, dump и tar. Мы использовали для создания архива следующие ключи:
с – create – создать архив;v – verbose mode – выводить имена всех пакуемых фалов на экран;z – zip – после упаковки вызвать gzip для сжатия;f – file – записать результат в файл, который указан после ключа f, а не на первый ленточный накопитель, как по умолчанию.apache.tar.gz – это имя архива, а apache/* – то, что надо упаковать.
Лучше всего запаковывать целый каталог, а не входить в него и паковать содержимое, вот так:
# так делать не надо cd /home/apache tar cvzf apache.tar.gz *
Архив так тоже можно создать, но при распаковке он рухнет всеми своими сотнями файлов и подкаталогов в тот каталог, где он будет распаковываться. Это неудобно, и так не принято. Дурной тон. Намного вежливее и красивее упаковать сразу целый каталог, как в предыдущем примере. Тогда по команде
tar xzvf apache.tar.gz
в том каталоге, где лежит архив, создастся подкаталог apache (помните, там было сказано "apache/*"?). И уже в него будут распакованы все файлы и подкаталоги архива. В этой команде tar мы использовали один незнакомый ключ – x. Он требует распаковать архив.
Для сжатия архивов можно применять как gzip, так и compress – более старую утилиту из древних систем UNIX. Результатом выполнения команды сжатия файла data.txt compress data.txt будет файл data.txt.Z. При применении gzip результат будет в среднем лучше, так как этот архиватор обычно сжимает файлы сильнее. При этом он дописывает к имени сжатого файла суффикс .gz. В обоих случаях исходный (несжатый) файл исчезает, остается только сжатый файл. Надо помнить, что при нехватке места на диске архив не может быть создан, так как несжатый исходный файл удаляется только после его успешного сжатия и переименования временного сжатого файла в окончательный результат.
Для декомпрессии файлов, сжатых утилитами compress и gzip используйте gunzip соответственно. В некоторых версиях UNIX используется еще более новый архиватор bzip2 (и де-компрессор bunzip2 ), но в Solaris он пока еще не портирован.
Для копирования целых устройств в их образы (например, дискет или компакт-дисков) и обратно служит программа dd. С ее помощью также можно копировать целые разделы дисков. Обычный формат вызова этой программы таков:
dd if=/dev/fd0 of=/usr/home/admin/diskettes/image1
Фактически, dd расценивает то, что она копирует, как блоки произвольных данных указанной длины (используется разумное умолчание в 512 байтов). Использовать dd можно тогда, когда следует иметь две или более резервные копии: первую копию на ленту записывают с помощью программы ufsdump, а остальные создают копированием с ленты на ленту программой dd:
dd if=/dev/rmt/0h of=/dev/rmt/2h
Нельзя использовать эту программу для копирования файлов с одной файловой системы на другую, если размер блоков этих файловых ситстем разный.
При копировании файлов, расположенных на блочных устройствах, последний копируемый блок может быть дополнен нулями от конца области данных до конца блока.
Команда cpio служит для копирования файлов в архив и из архива и умеет работать в трех режимах: входящего копирования, исходящего копирования и пассивного копирования. Режим исходящего копирования (копирования в архив, Copy Out Mode) применяется для создания архива из файлов, подходящих по маске. Так, для архивации файлов, чьи имена начинаются с q, можно использовать такую последовательность команд:
ls q* | cpio -oc >Q/sccs.backup 16 blocks cd Q ls sccs.backup
Файл результата состоит из заголовка и записанного вслед за ним имен и содержимого архивируемых файлов. Сжатия информации не производится. Так выглядит начало получившегося файла
head sccs.backup 070701000020fc0000812400000000000000010000000140dd6ab7000000120000 00660000000700000000000000000000000200000005q test1
Применим входящее копирование (т.е. копирование из архива, Copy In Mode) для извлечения из архива определенных файлов, в нашем примере – файла q:
ls sccs.backup cat sccs.backup | cpio -i q 4 blocks ls q sccs.backup
mv. В этом режиме cpio читает список файлов со стандартного ввода и копирует эти файлы в указанный каталог (дерево каталогов).
Фактически, cpio всегда принимает список файлов со стандартного ввода (кроме случая входящего копирования). Ключи, которые описаны в man cpio, предписывают программе особенности поведения, такие, как создание подкаталогов по необходимости и т.п.
Одним из самых мощных иструментов копирования и синхронизации содержимого географически удаленных файлов и каталогов является программа rsync. Она должна быть знакома вам по другим системам UNIX.
Можно применять rsync для работы поверх ssh или для самостоятельной работы в режиме клиент-сервер. В последнем случае потребуется на одной из сторон копирования запустить сервер rsync, который запускается командой rsync с ключом --daemon. Для запуска rsync в режиме сервера следует вначале создать и наполнить осмысленным содержанием файл /etc/rsyncd.conf, в котором указывается, какие каталоги и с какими правами доступа к ним сервер rsync позволит видеть снаружи.
Основное преимущество rsync перед всеми остальными способами копирования файлов в том, что rsync не передает файлы целиком, если в этом нет необходимости. Так, при синхронизации каталогов, содержащих файлы большого объема (сотни мегабайт, например), rsync обменивается с удаленным сервером контрольными суммами, посчитанными по блокам данных внутри файла, и при совпадении контрольных сумм и размеров блоков не выполняет пересылку блока, который одинаков на обеих сторонах.
Для копирования файлов с компьютера remote из каталога src/bar на локальный комптютер в каталог /data/tmp дать команду
rsync -avz remote:src/bar /data/tmp
А для того, чтобы передать с компьтера remote из каталога /data/important все файлы в каталог /data/remote/backup на локальном компьтютере с использованием ssh (фактически, поверх ssh ) следует дать команду
rsync -e ssh -avz remote:/data/important /data/remote/backup
При этом на компьютере remote должен быть доступен для запуска ssh и вы должны будете корректно аутентифицировать себя (ввести пароль) для выполнения команды.
В большинстве систем UNIX для резервного копирования файловых систем на ленту и восстановления файлов с ленты применяются программы dump и restore. В Solaris для этой же цели для файловых систем UFS используют собственные программы ufsdump и ufsrestore. Принципиальной разницы между общепринятым вариантом и специфичным для Solaris нет, программы dump, ufsdump занимаются резервным копированием данных, а restore и ufsrestore – восстановлением данных (т.е. переписыванием файлов с ленты на диск). Программы, применяющиеся в Solaris, обладают несколько большей функциональностью, например, позволяют выполнять копирование файлов на дискету (ключ D ), в то время как dump/restore работают только с ленточными накопителями.
В данном разделе мы рассмотрим только общие особенности этих программ, поэтому материал раздела применим не только к системе Solaris, но и к другим системам UNIX.
По умолчанию ufsdump и ufsrestore работают с первым стримером в системе. Несмотря на это, хорошим тоном считается явное указание устройства, на которое мы хотим выполнить резервное копирование. Это страхует нас от неприятных сюрпризов, таких, как неожиданная перемотка ленты в конце копирования или попытка копирования на носитель, который не вставлен в
Программа ufsdump выполняет копирование файловой системы целиком, ее можно, но не следует применять для копирования отдельных каталогов.
Она может выполнять копирование не только на ленту, но и в файл на диске, а также на дискету. При копировании информации на жесткий диск более разумно использовать обычные утилиты копирования типа cp или специализированные типа tar или rsync (если нужно выполнить копирование на удаленный компьютер).
Следует обязательно указывать уровень копирования при копировании на ленту. Программа ufsdump позволяет задать 10 уровней с 0 до 9. Уровень 0 – это копирование всей файловой системы целиком.
При копировании уровня n копируются все файлы, которые были изменены с момента последнего копирования уровня n или уровня с меньшим номером.
Уровни копирования введены для того, чтобы инкрементное копирование, т.е. копирование только измененных файлов, было легче организовать. Оно экономит место на ленте и время, затрачиваемое на резервное копирование. Обратной стороной медали в данном случае является большее время восстановления данных, так как если файловая система была сохранена полностью три дня назад, а вчера и позавчера выполнялось инкрементное копирование, при восстановлении придется задействовать три кассеты – чтобы восстановить файловую систему по состоянию на момент последнего резервного копирования. Если время позволяет, а свободное место на ленте заведомо превышает объем копируемых данных, удобнее всегда делать полное копирование выбранной файловой системы. В таком случае, когда бы ни произошел сбой, всегда хватит одной-единственной кассеты – самой свежей – чтобы полностью восстановить файловую систему.
Планируя схему резервного копирования, помните, что при инкрементном копировании для восстановления после сбоя придется последовательно считывать все ленты, начиная с последнего дампа нулевого уровня. Кроме затрат времени и кассет на такое копирование, после восстановления возникнут уже удаленные файлы, которые удалялись после дампа нулевого уровня: программа восстановления файлов не имеет информации о том, что какие-то файлы были удалены, потому что резервное копирование выполнялось до удаления этих файлов.
При нехватке места на ленте или диске, на которые производится резервное копирование, ufsdump предупредит об этом и попросит вставить в используемое для копирования устройство новый носитель (кассету с лентой). Конец ленты вызывает передачу сигнала от накопителя системе. Если ufsdump размер носителя в килобайтах явным образом.
Программа ufsdump позволяет задавать плотность записи на ленту. Плотность записи зависит только от типа и модели
За многие годы существования многопользовательских операционных систем было разработано множество схем резервного копирования, направленных на оптимизацию времени восстановления файловой системы, времени выполнения резервного копирования, количества используемых в цикле копирования лент и, наконец, всех этих параметров одновременно. Описание этих схем лежит вне рамок наших лекций, с теорией резервного копирования вы легко познакомитесь в Интренете, если это понадобится вам. На практике нам следует уместь выполнять основные действия, связанные с резервным копированием файловых систем.
Весьма часто применяется регулярное полное (уровня 0) резервное копирование раздела с важной информацией, что требует размещения важной информации на одном разделе.
Однозначно НЕ СЛЕДУЕТ выполнять резервное копирование разделов, где расположены временные файлы, файлы протоколов (если только протоколы не представляют ценности для вашей организации), дистрибутив системы или файлы приложений, которые легко установить из дистрибутива.
Резервные копии всегда следует хранить отдельно от пустых (чистых) кассет, и лучше всего – в надежном месте за пределами здания организации, по соображениям пожарной безопасности в том числе.
Синтаксис команды ufsdump отличается от синтаксиса большинства команд UNIX:
ufsdump [[ключи] [аргументы]] файловая_система
Сначала в командной строке друг за другом без пробелов указываются все ключи подряд, БЕЗ знака "минус" перед ними. Затем, через пробел, в том же порядке, что и ключи, указываются аргументы, относящиеся к этим ключам, например:
/usr/sbin/ufsdump 0ufBds /dev/rmt/0n 4194304 62000 1500 /var
Это означает дамп уровня 0 (ключ 0), с обновлением файла /etc/dumpdates (u), на устройство ( f, файл) /dev/rmt/0n, размер тома (т.е. картриджа, кассеты, – В) – 4 194 304 килобайта (т.е 4 гигабайта), плотность записи (d) 62000 бит на дюйм (bit per inch – файловая_система обязателен, в то время как все остальные аргументы могут быть приняты по умолчанию, а какую именно файловую систему копировать, надо решать Вам. Полагаться на умолчание не рекомендуется: указывайте параметры явно – так надежнее.
Конкретные параметры кассет и
Если вы настраиваете сеть, в которой работают несколько разных систем UNIX, не забывайте о некоторых отличиях Solaris и других систем. В частности, в версиях FreeBSD 4.х и выше программа dump принимает и вышеописанные ключи, и более стандартную форму ключей (со знаком "минус" и указанием значения параметра сразу после ключа). Таблица 11.2 описывает конвенцию именования файлов устройств стримеров в разных системах UNIX.
| ОС | С перемоткой | Без перемотки |
|---|---|---|
| FreeBSD | /dev/rsa# | /dev/nrsa# |
| Linux | /dev/st# | /dev/nst# |
| Solaris | /dev/rmt/#l | /dev/rmt/#n |
В любой системе UNIX каждый ленточный накопитель представлен двумя файлами устройств – с перемоткой ленты в конце записи и без перемотки. Вы можете записать на одну кассету несколько разных файловых систем или несколько последовательных резервных копий одной системы. Для этого надо в качестве устройства для записи указывать файл устройства без перемотки ленты в конце записи. Используйте эту возможность осторожно и всегда записывайте, какие именно файловые системы, в каком порядке и когда были сохранены. Обратите внимание: по умолчанию dump/ufsdum p выбирает устройство с перемоткой.
Названия устройств могут быть другими, в зависимости от типа # ) обозначает номер
Когда вы решите, что резервное копирование должно прочно войти в жизнь вашей компании, обязательно закупите достаточное количество кассет (иначе их называют картриджами, по сути дела это – специальные кассеты с магнитной лентой) для создания резервных копий.
Запись нескольких копий на одну ленту "от бедности" ведет к снижению надежности в несколько раз. Перед восстановлением данных вы можете забыть перемотать ленту и в результате сотрете нужные и еще целые данные вместо потерянных!
Маркируйте кассеты после выполнения копирования, к каждой из них не зря прилагается липкий стикер. Не играйте в плохую игру с памятью: вы будете помнить о том, что где записано, неделю, а резервная копия может понадобиться через 10 дней...
Программа ufsdump, если задать ключ u, будет обновлять файл /etc/dumpdates, это полезная возможность, пользуйтесь ею! В этом файле в случае успешного завершения копирования появится новая строка с описанием того, что, с какими параметрами и на какое устройство было скопировано. Потом эти сведения могут оказаться важными, если данные и в самом деле придется восстанавливать.
Каждый системный администратор в душе когда-то раньше надеялся, что резервное копирование – это пустая трата времени и данные никогда не придется восстанавливать. Несмотря на это, суровая правда жизни заставляет нас изучить и процедуру восстановления данных – конечно же, просто на всякий случай.
Восстановление данных, записанных программой ufsdump, производится командой ufsrestore. Ей можно указать, в какой каталог восстанавливать данные. Это сделано для того, чтобы при необходимости указать новый каталог вместо прежнего, например, при крахе файловой системы.
Следует своевременно удалять восстановленные файлы из временных каталогов, если Вы их уже перенесли по месту постоянной дисклокации, чтобы не занимать лишнего пространства забытыми файлами!
При записи нескольких файловых систем на одну кассету (помните: это не рекомендуется!) на кассете образуется несколько томов (volumes). Так как ни ufsdump, ни restore не умеют искать нужный том, важно знать, как самостоятельно отыскать требуемый том. На кассете должно быть написано вашей рукой (рука вашего ассистента или предшественника тоже подойдет), в каком порядке и что именно на ней записано. Для перемотки ленты до нужного тома надо использовать команду mt.
Программа mt оперирует понятием файла (перемотать ленту на файл вперед, на два файла назад). При записи на ленту программой ufsdump таким "файлом" будет целый том (файловая система), пусть слово "файл" здесь не вводит вас в заблуждение.
Кроме ufsdump, данные на ленту можно записывать с помощью программы tar, речь о которой шла выше: она записывает целоый каталог или группу файлов в один архив.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.