(Резервное копирование и восстановление)
В большинстве случаев сбои в системе происходят по вине человека, но случаются и аппаратные сбои. Хакеры находят все новые способы преодоления сетевой защиты и проникновения в систему через приложения, и вам неизбежно придется регулярно обновлять свою систему. (Обновлять ли систему полностью или отдельную ее часть – это уже отдельный вопрос.) Всякий раз, когда вы прикладываете руки к системе, существует опасность допустить ошибку, нарушить работу жизненно важной службы или вообще полностью разрушить систему. Достаточно вспомнить, как часто вы что-то меняли на компьютере (с любой операционной системой) и сталкивались впоследствии со странным поведением системы. Даже минимальные изменения конфигурации потенциально способны повредить данные. Поэтому вы всегда должны быть готовы к худшему. В случае с компьютерами это означает возможность повреждения данных на жестком диске, и вы должны быть готовы восстановить эти данные.
Хуже другое – читатель этой книги, вероятно, еще только изучает, как настраивать систему FreeBSD, и поэтому пока не готов к аварии. Новичку необходимо протестировать множество вариантов конфигурации и проанализировать «историю» изменений в конфигурации системы. Иногда случаются вещи, которые могут вызвать не только высказывание: «Но в последний месяц это работало, что же я изменил?», – но и более бурные эмоции. Сможете ли вы вспомнить все изменения, которые произвели в течение последних недель, месяцев или лет? А что если изменения были внесены вашими коллегами? На самом деле интенсивные эксперименты могут полностью нарушить работу системы, поэтому необходим способ восстановления важных данных.
Эта глава начинается с рассмотрения общего подхода – резервного копирования всего, что есть в компьютере. Однако такой подход недостаточно хорош для сохранения отдельных файлов, поэтому этот случай будет рассмотрен отдельно. Если файл изменяется три раза в день, а резервное копирование происходит раз в неделю, то при потере файла можно потерять важные данные. Кроме того, будут рассмотрены меры по восстановлению и перекомпоновке системы в случае частичных неполадок – с применением однопользовательского режима и загрузочной дискеты для ремонтных работ (fixit).
Резервное копирование системы
Резервное копирование системы необходимо, лишь если данные важны. Это не так глупо, как может показаться. Вопрос, который надо себе задать, таков: «Сколько будет стоить восстановление данных?» Например, недорогая система резервного копирования стоит несколько сотен долларов. Как дорого стоит ваше время и сколько его потребуется, чтобы восстановить систему с установочного носителя? Если самые драгоценные данные на вашем жестком диске – это файл с закладками веб-браузера, тогда, вероятно, нет смысла вкладывать деньги в систему резервного копирования. Но если речь идет о магистральном сервере компании, тогда вы будете относиться к инвестированию денег в систему резервного копирования очень серьезно.
Для операций по полному сохранению и восстановлению необходимы накопитель на магнитной ленте и сама лента. Кроме этого, данные можно сохранять в файлах, проводя резервное копирование по сети, или на съемных носителях, таких как компакт-диски или DVD-диски. Однако современным индустриальным стандартом является магнитная лента, поэтому внимание здесь будет сосредоточено именно на этом решении. Для работы с накопителем на магнитной ленте вам потребуется программа резервного копирования, и мы рассмотрим стандартные программы резервного копирования, которые распространяются в составе FreeBSD.
Накопители на лентах
FreeBSD поддерживает накопители на магнитных лентах с интерфейсами SCSI, USB и IDE. По сравнению с устройствами IDE устройства SCSI быстрее и надежнее, однако устройства IDE дешевле. Накопители с интерфейсом USB не всегда соответствуют стандартам и потому могут не поддерживаться системой FreeBSD. Обязательно ознакомьтесь с примечаниями к выпуску в архивах почтовых рассылок FreeBSD, чтобы убедиться, что ваш накопитель на магнитной ленте совместим с FreeBSD.
После физической установки накопителя на ленте необходимо убедиться, что FreeBSD распознала это устройство. Самый простой путь проверить файл /var/run/dmesg.boot, как рассказывалось в главе 3. Накопители с интерфейсами SCSI и USB отображаются в нем как устройства «sa», тогда как IDE-накопители отображаются как устройства «ast». Например, следующие три строки из файла dmesg.boot описывают SCSI-накопитель, подключенный к этому компьютеру:
sa0 at ahc0 bus 0 target 9 lun 0
sa0: <SONY SDT-10000 0110> Removable Sequential Access SCSI-2 device sa0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
Из всей информации, что мы имеем об этом накопителе на магнитной ленте, самое важное, что FreeBSD опознала его как устройство sa0 . Кроме того, это устройство подключено к SCSI-карте ahc0 со SCSI ID 9 и это модель «SONY SDT-10000 0110» с максимальной производительностью до 40 Мбайт в секунду .
Файлы устройств накопителей на лентах, перемотка и извлечение
Прежде чем вы сможете использовать накопитель на магнитной ленте для нужд резервного копирования, необходимо научиться им управлять. Подобно многим другим старомодным устройствам UNIX, способ доступа к накопителю на ленте определяет его поведение. Для каждого типа накопителей на ленте используются различные файлы устройств, и все они ведут себя по-разному. Основной механизм управления накопителем – применение файла устройства, который используется для доступа к нему.
При наличии обычного SCSI-накопителя интерес представляют только три файла устройств: /dev/esa0, /dev/nsa0 и /dev/sa0. Точно так же для IDE-накопителя важны файлы /dev/east0, /dev/nast0 и /dev/ast0.
Накопители на лентах – это устройства с последовательным доступом; данные на ленте хранятся линейно. Для получения доступа к определенным данным на ленте необходимо перематывать ленту вперед и назад. Делать это или не делать – вопрос важный.
Примечание
Поведение различных файлов устройств накопителей на ленте различно в разных операционных системах. Различные версии UNIX обладают различным программным обеспечением, которое по-разному обслуживает эти накопители. Не делайте никаких предположений относительно вашего накопителя!
Если в команде указывается файл устройства, который соответствует имени устройства, лента будет автоматически перемотана после завершения операции. Возьмем устройство SCSI sa0; при запуске команды, в которой в качестве файла устройства указан /dev/sa0, лента будет автоматически перемотана по завершении команды.
Бывает так, что после завершения операции ленту перематывать не надо, например, когда предполагается выполнить резервное копирование данных с другой машины и разместить их на ленте или вам необходимо перед перемоткой и извлечением ленты каталогизировать ее. В этом случае следует задействовать файл устройства, имя которого начинается с n. Скажем, если в команде указан /dev/nsa0, лента не будет перемотана.
Чтобы лента извлекалась автоматически после завершения операции, следует указать файл устройства, имя которого начинается с e. Например, если операция подразумевает резервное копирование всей системы, для автоматического извлечения ленты по окончании сохранения следует задействовать устройство /dev/esa0. Некоторые старые накопители на лентах могут не поддерживать автоматическое извлечение ленты; в этом случае необходимо нажать клавишу для приведения в действие рычага, который извлечет ленту из накопителя. Самый простой способ, позволяющий выяснить, возможно ли автоматическое извлечение ленты, состоит в том, чтобы попробовать извлечь ее за счет использования соответствующего файла устройства и посмотреть, что произойдет.
Переменная $TAPE
Во многих программах подразумевается, что накопитель на ленте представлен файлом устройства /dev/sa0, однако такое предположение не всегда верно. Даже если в системе установлен только один накопитель SCSI, то возможно, что вам не потребуется автоматическая перемотка ленты (dev/nsa0) или надо будет извлечь ленту по завершении резервного копирования (/dev/esa0). Либо в системе есть накопитель IDE, для которого используется файл устройства с совершенно другим именем.
Многие программы (но не все) ориентируются на переменную окружения $TAPE, значение которой они используют как имя файла устройства по умолчанию. Вы всегда сможете в командной строке указать иной файл устройства, а в переменную $TAPE записать наиболее часто используемое значение и тем самым избавить себя от доли раздражения.
Если вы используете командный процессор по умолчанию, значение переменной $TAPE можно установить следующей командой:
# setenv TAPE /dev/sa0
Определение состояние накопителя с помощью команды mt(1)
Теперь, когда вы узнали, как отыскать свой накопитель на ленте, можно выполнять основные операции, такие как перемотка, натяжка, очистка и т. д., с помощью команды mt(1). Чаще всего команда mt применяется для выяснения состояния накопителя на ленте:
#mt status
Mode Density Blocksize bpi Compression
Current: 0x25:DDS-3 variable 97000 ———available modes———
0: 0x25:DDS-3 variable 97000 1: 0x25:DDS-3 variable 97000 2: 0x25:DDS-3 variable 97000 3: 0x25:DDS-3 variable 97000 ———————————
DCLZ
DCLZ
DCLZ
DCLZ
DCLZ
Current Driver State: at rest. ———————————
File Number: 0 Record Number: 0 Residual Count 0
Большая часть информации, представленной здесь, особого значения не имеет, однако если эти данные необходимо изучить построчно, следует обратиться к странице руководства mt(1), хорошо описывающей все особенности команды. По крайней мере, если команда возвращает какую-то полезную информацию, следовательно, она обнаруживает накопитель.
Самое первое, что мы видим, – это характеристика плотности записи на ленту . В устаревших моделях для разных целей могли использоваться ленты с разной плотностью записи, но современные устройства записывают данные настолько плотно, насколько это возможно. В данном случае привод обеспечивает плотность записи DDS-3. Вам могла бы потребоваться иная плотность записи, но DDS-3 – это все, что может вам предложить данное устройство. Далее видно, что устройство предлагает возможность аппаратной компрессии данных по алгоритму DCLZ . Ближе к концу видно, что делает устройство в настоящий момент .
Команда status может выводить самые разные сообщения. Наибольшие проблемы вызывает то, которое сообщает, что устройство не сконфигурировано:
# mt status
mt: /dev/nsa0: Device not configured
Это означает, что в системе нет накопителя на ленте, соответствующего файлу устройства, который указан в переменной $TAPE. С файлами устройств можно поэкспериментировать, если посредством ключа –f указать файл устройства (например, mt –f /dev/nsa1 status). Однако необходимую информацию можно получить из dmesg.boot.
Если вы уверены в работоспособности своего устройства, то, возможно, в приводе отсутствует лента или устройство требует чистки.
Еще один вариант ответа, который можно получить от команды mt status, – mt: /dev/nsa0: Device busy. Вы спрашиваете, в каком состоянии находится ваша лента, и вам отвечают: «Я не могу говорить сейчас, я занят». Попробуйте обратиться позднее или с помощью команды ps –ax посмотрите, кто пользуется приводом. В каждый конкретный момент времени доступ к ленте может получить только один экземпляр программы. Вы не можете вывести содержимое ленты в то время, когда с нее производится чтение файла.
Другие команды управления накопителем на ленте
С накопителем на магнитной ленте можно выполнять гораздо более интересные операции, чем просто получать отчет о его состоянии. Наиболее часто я использую команды retension, erase, rewind и offline.
Ленты имеют свойство растягиваться, особенно первое время. (Я отлично знаю, все современные производители лент заявляют, что они предварительно производят растяжку своих лент или что их ленты не растягиваются; но прибавляем к этим заявлениям два кусочка хлеба и получаем болонский сэндвич.) Повторное натяжение (retensioning) ленты производится простой ее перемоткой вперед и назад, с помощью команды mt retension. Повторное натяжение устраняет слабину и повышает надежность резервного копирования.
Операция стирания удаляет все данные с ленты. Но это не то надежное стирание, которое можно было бы использовать для сокрытия данных от фирмы, занимающейся восстановлением данных или от налогового управления США: mt erase просто прокручивает ленту и накладывает новую запись поверх существующей. Это может занять довольно много времени. Если нужно стереть ленту быстро, можно воспользоваться командой mt erase 0, которая просто пометит ленту как пустую.
Команда mt rewind перемотает ленту в начало, точно так же, как и обращение к устройству через файл устройства с тем же именем.
Когда устройство отключается, оно перематывает ленту и выталкивает ее, что дает возможность вставить новую ленту. Команда, которая делает это, выглядит немного странно – mt offline.
Характер накопителя на ленте
Не все накопители на магнитной ленте поддерживают полный перечень функций. Устаревшие модели накопителей очень капризны и требуют тщательной настройки. Если вы испытываете сложности с каким-либо приводом, загляните в архивы почтовых рассылок FreeBSD-questions и посмотрите, не было ли там сообщений с описанием аналогичной проблемы. Возможно, там вам удастся отыскать ответ.
Перематывать или нет?
О лентах важно постоянно помнить, что данные на ленте хранятся линейно. Каждый участок ленты хранит отдельный блок данных. Если на одну и ту же ленту производится копирование нескольких блоков данных, то после каждой операции копирования не нужно производить перемотку ленты. Представьте, вы записали на ленту резервную копию одной системы, перемотали ленту и записали резервную копию другой системы. Вторая резервная копия просто затрет первую, потому что запись будет произведена на тот же самый участок ленты. Когда на одну и ту же ленту записывается несколько резервных копий, используйте соответствующий файл устройства, чтобы избежать автоматической перемотки ленты между операциями.
Программы для создания резервных копий
Два популярных пакета для резервирования системы – это tar(1) и dump(8). Разумеется, есть и другие инструменты, такие как pax и cpio. Вам также могут встретиться программы для FreeBSD, выполняющие резервное копирование по сети, такие как Amanda и Bacula, и позволяющие создать резервную копию всей сети. Подобные инструменты хорошо подходят для определенных сред, но они не такие универсальные, как tar и dump. Впрочем, если освоить dump и tar, то работать с другими программами будет просто.
Программа tar(1) предназначена для работы с файлами. Данные из резервных копий, созданных с помощью tar, можно восстановить почти на всех операционных системах. Программа dump(8) работает с дисковыми разделами и файловыми системами. Информацию из резервных копий, полученных командой dump, можно восстановить исключительно на той же операционной системе, на которой были созданы копии. Для резервного копирования всех файлов следует применять dump. Если необходимо сохранить небольшой объем данных либо их потребуется восстановить в совершенно другой среде, следует предпочесть tar.
tar
Утилита tar, сокращение от «tape archiver» (ленточный архиватор), может создавать резервные копии любой информации – от одного файла до всей системы. В отличие от dump tar работает только с файлами и каталогами и понятия не имеет о базовой файловой системе (это его преимущество и недостаток). Tar – это общий стандарт, признанный почти всеми производителями операционных систем. Программу tar можно запускать в средах Windows, Linux, UNIX, BSD, Mac OS X, AS/400, VMS, Atari, Commodore64, QNX и почти во всех других операционных системах.
Утилита tar(1) может сохранять файлы на ленте или в специальном файле. Такой файл называется тарбол (tarball). Поскольку tar работает с файлами, извлечь и восстановить файл из тарбола очень легко.
В системе FreeBSD используется своя версия tar, которая называется bsdtar, написанная с самого начала для замены GNU tar. Утилита bsdtar может вести себя как GNU tar, а также в строгом соответствии с POSIX tar. Если вас интересуют различия между GNU tar, POSIX tar и bsdtar, прочитайте страницу руководства tar(1), где приводится масса кровавых подробностей. Фактически утилита bsdtar основана на библиотеке libarchive(3), которая используется разработчиками для добавления поддержки архивирования в другие программы. Один из недостатков tar – молчаливость. Если файловая система повреждена, то одному богу известно, что сохранит tar. После этого он «успешно» восстановит файлы, которые были повреждены при первоначальном копировании. Такого рода проблемы редко случаются на практике, но когда это происходит, память о них остается надолго.
Режимы tar
Утилита tar(1) может выполнять несколько операций, управляемых посредством параметров командной строки. Эти операции называются режимами. Полное описание всех режимов tar приводится в странице руководства, а здесь будут рассмотрены наиболее типичные из них.
Создание архива
Режим создания архива (–c) применяется для создания нового архива. Если иное не указано, этот ключ инициирует сохранение всей информации на ленточном устройстве ($TAPE или /dev/sa0, если переменная $TAPE не установлена). Для сохранения всей системы надо сообщить утилите tar о необходимости рекурсивно архивировать все файлы, начиная с корневого каталога:
# tar —c /
В ответ на ленточном накопителе должен загореться индикатор. Если на ленте достаточно места, в конечном итоге на ней будет сохранена вся система. Многие современные диски обладают значительно большей емкостью по сравнению с лентами, поэтому часто имеет смысл сохранять лишь отдельные, жизненно важные части системы. Так, если все файлы, которые подвергались изменениям, находятся в разделах /home и /var, то именно эти каталоги можно указать в командной строке:
# tar —c /home /var
Вывод содержимого архива
В режиме вывода содержимого (–t) выводятся имена всех файлов, находящихся в архиве. После завершения работы накопителя можно применить этот ключ, чтобы отобразить содержимое ленты:
# tar —t .
.snap dev
tmp …
Эта операция выводит имена всех файлов в архиве и может занять продолжительное время. Примечательно, что в именах файлов отсутствует первый символ слэша («/»). Например, имя файла /tmp выводится как tmp. Эта особенность играет важную роль при восстановлении файлов.
Извлечение файлов из архива
В режиме извлечения файлов (–x) tar извлекает файлы из архива и копирует их на диск. Извлечение файлов производится в текущий каталог; чтобы перезаписать существующий системный каталог /etc, надо прежде всего перейти в корневой каталог. С другой стороны, чтобы восстановить копию каталога /etc в моем домашнем каталоге, я должен был бы сначала перейти в свой домашний каталог.
# cd /home/mwlucas # tar —x etc
Помните замечание о том, что отсутствие первого символа слэша («/») играет важную роль? Теперь ясно, почему. Если бы в именах архивируемых файлов первым символом был «/», tar всегда извлекал бы файлы относительно корневого каталога. Восстановление файла /etc/rc.conf из резервной копии всегда приводило бы к затиранию существующего файла /etc/rc.conf. При отсутствии начального символа слэша («/») в резервной копии извлечение файлов может производиться в любой каталог, например, файл /etc/rc.conf можно восстановить в виде файла /home/mwlucas/etc/rc.conf. Если файлы извлекаются не на том компьютере, где они были заархивированы, было бы крайне нежелательно, чтобы они затерли существующие файлы на текущем компьютере. Желательно извлекаемые файлы сохранять в отдельном каталоге, чтобы они не оказывали влияния на текущую систему.
Проверка архива
Создав резервную копию, ее можно проверить, чтобы убедиться, что она соответствует вашей системе. Режим поиска различий (–d) сравнивает файлы на ленте с файлами на диске. Если все файлы на ленте соответствуют файлам в системе, то команда tar –d будет выполнена «молча». Однако абсолютное соответствие будет удивительно. Обычно при проведении резервного копирования растут файлы протоколов, поэтому они не будут совпадать с сохраненными файлами. Или, если в системе есть активная база данных, ее файлы могут не соответствовать сохраненным. Если вам необходимо полное соответствие резервной копии (которая еще называется холодная копия), вам следует загрузиться в однопользовательском режиме и создавать резервную копию из него. Вам следует решить, какие ошибки сравнения можно игнорировать, а с какими следует разбираться.
Другие возможности tar
Утилита tar обладает некоторыми другими особенностями, которые делают ее более дружественной и удобной. В число этих особенностей входят подробный режим отображения хода выполнения операции,
gzip
различные способы сжатия, восстановление прав доступа к файлам и самая популярная особенность – запись архивов в файлы вместо устройства накопителя на магнитных лентах.
Использование файла вместо ленты
Ключ –f позволяет задать устройство или файл в качестве места для создания архива. Во всех предыдущих примерах использовалось устройство по умолчанию /dev/sa0 или устройство, определяемое переменной $TAPE. В случае необходимости накопитель на ленте можно указать с помощью ключа –f:
# tar —c —f /dev/east0 /
Вместо записи резервной копии на ленту можно создать tar-файл. Исходный код, распространяемый Интернете, часто распространяется в виде файлов с расширением .tar (tarballs). Для сохранения резервной копии в файле можно использовать ключ –f. Так, для сохранения глав этой книги я время от времени создавал тарбол bookbackup.tar:
# tar —cf bookbackup.tar /home/mwlucas/absolutefreebsd/
Этот файл легко можно сохранить на любой другой машине, поэтому, даже если мой дом сгорит, книга будет сохранена. Далее можно задействовать телефонный канал и линию электропередачи соседа, позаимствовать ноутбук, отыскать открытую точку беспроводного доступа к сети, запустить tar –xf bookbackup.tar и работать в окружении головешек, ожидая представителя страховой компании. (Вряд ли я смог бы сделать намного больше в подобной ситуации.)
Подробный режим
Ключ –v делает утилиту tar словоохотливой. Обычно tar работает «молча», за исключением случаев, когда появляются ошибки. Чаще всего это очень хорошо (кому захочется читать длинные списки файлов на сервере всякий раз, когда запускается процедура архивирования?), но иногда возникает желание ощутить то теплое чувство, которое дает вид работающей программы. С ключом –v утилита покажет имена всех файлов, которые упаковываются в архив или распаковываются из архива. При рутинном архивировании или разархивировании подробный режим мешает следить за появлением ошибок.
Ключ –z вызывает обработку файлов программой сжатия gzip(1) – как при архивировании, так и при разархивировании. Сжатые тарболы обычно имеют расширение .tar.gz или .tgz, редко .taz. Сжатие файлов значительно уменьшает размер архива; на самом деле многие резервные копии можно сжать на 50% и более. Все современные версии tar, в отличие от старых, поддерживают gzip. Поэтому, если необходимо, чтобы сжатые файлы мог прочесть абсолютно каждый, применять ключ –z не надо.
Сжатие
В противоположность предыдущему ключу все версии tar на всех версиях UNIX могут сжимать файлы с помощью ключа –Z, который вызывает compress(1). Программа compress не так эффективна, как gzip, но она все-таки уменьшает размер файла. Тарболы, сжатые с помощью –Z, имеют расширение .tar.Z.
Сжатие утилитой bzip
С помощью ключа y tar в составе FreeBSD поддерживает сжатие с помощью программы bzip, более эффективной, чем gzip. bzip требует больше времени процессора, чем gzip, но в наше время процессорное время не так ограничено, как во времена, кода появилась утилита gzip. Однако не все версии поддерживают bzip. Если сохраняемые файлы будут читаться только на системе FreeBSD или вы в состоянии будете установить bzip на другой платформе, используйте ключ –y.
Сжатие и утилита tar в системе FreeBSD
Библиотека libarchive в системе FreeBSD автоматически определяет тип сжатия, используемый для создания резервных копий. При создании архива вы должны явно указать желаемый тип сжатия, однако при извлечении файлов из архива можно позволить утилите tar(1) самой определять тип сжатия и Принять Правильное Решение самостоятельно.
Восстановление прав доступа к файлам
Ключ –p позволяет восстанавливать первоначальные права доступа к извлекаемым файлам. По умолчанию tar назначает владельцем извлекаемых файлов пользователя, который производит операцию разархивирования. Такой подход оправдывает себя при работе с исходными текстами программ, но при восстановлении системы необходимо восстанавливать первоначальные права доступа к файлам. (Попробуйте на протяжении некоторого времени восстанавливать эти права вручную; вы сразу поймете, почему сразу нужно все делать правильно.)
И еще, и еще, и еще…
Утилита tar имеет еще массу других функций, учитывающих изменения в резервном копировании, файлах, файловых системах и дисках, происходившие в течение десятилетий. Полный список этих функций вы найдете в странице руководства tar(1).
dump
dump(8) – инструмент для проведения резервного копирования, работающий на уровне дисковых блоков. В какой-то мере dump похож на tar(1). Существенное различие между ними состоит в том, что программа dump учитывает тип файловой системы и использует ее преимущества. Более подробно файловые системы будут обсуждаться в главе 8. Сейчас достаточно знать, что файловая система определяет порядок, в котором единицы и нули располагаются на физическом жестком диске. Утилита dump, в частности, совместима с файловой системой UFS2, используемой во FreeBSD. Скорее всего, начинающие системные администраторы хуже знакомы с dump, чем с tar, но dump эффективнее и безопаснее. Когда есть выбор, надо применять dump.1
Единственный недостаток dump в том, что эта утилита работает с файловыми системами, а не с отдельными файлами. Поэтому dump не подходит для сохранения каталога /etc, если не надо сохранять весь корневой раздел. Тем не менее есть возможность восстанавливать файлы по отдельности.
Положительная особенность dump: для сохранения и восстановления информации dump применяет различные программы (dump(8) и restore(8) соответственно). Это означает, что ключи уже нельзя перепутать: при восстановлении данных файл в системе не запишется случайно поверх файла в архиве. Кроме того, dump работает значительно быстрее, чем tar.
Управление работой dump
Самое большое преимущество dump(8) в том, что она предоставляет пользователям возможность управлять своей работой. Например, они могут указать, какие файлы не надо включать в дамп, и они не будут копироваться. У многих пользователей есть файлы, не представляющие для них ценности. Они с радостью согласятся не сохранять эти файлы при условии, что важные для них файлы будут сохранены.
Для установки флага nodump воспользуйтесь chflags(1): # chflags nodump filename
Содержимое каталога, к которому применен флаг nodump, и вложенных в него подкаталогов сохраняться не будет. Например, я использую команду chflags, чтобы избежать копирования каталога с дистрибутивами, загруженными из Интернета, и сэкономить время и место, потому что эти файлы всегда можно загрузить заново.
Уровни резервирования
Одна из наиболее интересных особенностей dump – возможность инкрементного копирования через уровни резервирования (dump level), которые варьируются от 0 до 9. По умолчанию принимается уровень 0, что подразумевает копирование всех файлов на диске, для которых не установлен флаг nodump. Более высокие уровни резервирования означают следующее: «сохранять файлы, которые были изменены или созданы с момента выполнения дампа более низкого уровня». Такая последовательность уровней позволяет выполнять инкрементные дампы – достаточно указать необходимый уровень резервирования как ключ командной строки.
Например, пусть каждый понедельник выполняется дамп уровня 0. Во вторник можно выполнить инкрементный дамп уровня 1. При этом будут сохранены только те файлы, которые изменились с момента проведения дампа в понедельник. Если в среду выполнить дамп уровня 2, то будут сохранено все, что изменилось со вторника. Однако если в следующий вторник выполнить еще один дамп уровня 1, будет сохранено все, что изменилось с первого понедельника, включая файлы, которые были сохранены в среду.
Хотя с помощью dump можно выполнять инкрементное резервирование, лучше создавать дампы уровня 0 – просто потому, что тогда будет намного легче восстанавливать файлы, чем в случае серии инкрементных дампов. Дампы уровня 0 выполняются дольше инкрементных дампов и требуют больше места, однако в большинстве случаев время, сбереженное при восстановлении данных, важнее, чем стоимость ленты. При надлежащем планировании дампы уровня 0 можно выполнять ночью.
Указывайте желаемый уровень резервирования как аргумент командной строки, например, чтобы создать дамп уровня 2, запустите команду dump –2.
dump, ленточные накопители и файлы
К сожалению, dump(8) не распознает переменную окружения $TAPE и склонен по умолчанию использовать файл устройства /dev/sa0. Однако с помощью ключа –f можно указать другой накопитель. Как и tar, утилита dump позволяет с помощью ключа –f указать файл, в котором будет сохранена резервная копия. Хотя файлы, создаваемые dump, не так пригодны для распространения, как файлы, создаваемые tar, тем не менее, это прекрасная возможность поэкспериментировать и поближе познакомиться с dump.
Прежде чем dump приступит к созданию резервной копии, она пытается определить объем доступного пространства на ленте. К сожалению, эта ее возможность не усовершенствовалась уже много лет. Когда dump только появилась, производство приводов с лентами объемом 1 Мбайт было серьезным бизнесом, и каждый производитель выпускал ленты своих форматов, следуя своим собственным стандартам. В наше время накопители стали более универсальными и стандартными, и производители обеспечивают более широкую совместимость. Емкость лент также существенно выросла, например, работая над этой книгой, я использовал привод емкостью 40 Гбайт, от которого, вполне исправного, отказался предыдущий владелец только потому, что емкость его оказалась слишком маленькой. Вот так, с улучшением стандартизации и существенным ростом емкости, dump оказалась не в состоянии определять объем доступного пространства. Чтобы обойти эту проблему, лучше всего сообщить утилите о том, что она не должна определять размер ленты, а должна выполнять дамп до достижения физического маркера конца ленты и затем запросить смену ленты. Для этой цели используется флаг –a.
dump и задействованные файловые системы
Одна из проблем, которая возникает при создании резервных копий работающей системы, состоит в том, что файловая система постоянно изменяется в процессе копирования. Эта проблема отсутствует в файловых системах, предназначенных для хранения статичных данных, или когда изменения в одной части файловой системы не вызывают изменения в другой ее части. Но в случае хранения динамических, постоянно изменяющихся и/или взаимосвязанных данных, это превращается в серьезную проблему. Данная проблема характерна для большинства баз данных. Иногда бывает нежелательно останавливать базу данных только для того, чтобы получить качественную резервную копию, а иногда даже невозможно создать дамп базы данных в виде файла, поэтому приходится прибегать к холодному копированию. Чтобы обойти эту проблему, dump способна использовать возможность файловой системы UFS2 по созданию «снимков» и тем самым обеспечить внутреннюю целостность резервной копии. Подробнее о снимках файловой системы будет рассказываться в главе 8, а пока достаточно просто запомнить, что снимок – это образ диска, созданный в определенный момент времени. Даже когда данные на диске все время изменяются, снимок остается неизменным и статичным, поэтому его легко можно скопировать.
Чтобы создать дамп снимка, укажите ключ –L. Если производить копирование задействованной файловой системы UFS2 без этого ключа, dump сообщит об этом и предложит использовать ключ –L.
Разумеется, это не устраняет проблем с базами данных – нахождение файловой системы в непротиворечивом состоянии не означает, что база данных, которая расположена в этой файловой системе, также находится в непротиворечивом состоянии. Однако можно остановить базу данных на короткое время, запустить dump и снова запустить базу данных, позволив тем самым утилите dump записать снимок в тот момент, когда база данных была остановлена. Это уменьшает время бездействия, необходимое для создания резервной копии, до одной или двух секунд.
Временные метки и dump
В файл /etc/dumpdates записывается все, что было сохранено в системе. Это наиболее полезно при инкрементном резервировании, когда для успешного восстановления системы необходимо знать дату последнего полного сохранения. Задав ключ –u, этот файл можно обновить.
Запуск dump
Теперь, объединив все полученные сведения, можно выполнить резервное копирование файловой системы. Здесь я задаю утилите dump: не вычислять количество необходимых лент, создавать резервную копию из снимка задействованной файловой системы и произвести копирование раздела /usr на уровне резервирования 0.
# dump —auL /usr DUMP: Date of DUMP: Date of DUMP: Dumping DUMP: mapping
this level 0 dump: Sat Apr 5 08:26:03 2008
last level 0 dump: the epoch
snapshot of /dev/ad0s1f (/usr) to /dev/sa0
(Pass I) [regular files]
DUMP: mapping (Pass II) [directories] DUMP: estimated 3944900 tape blocks.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 11.54% done, finished in 0:38 at Sat Apr 5 09:09:25 2008
DUMP: 28.12% done, finished in 0:25 at Sat Apr 5 09:01:40 2008
DUMP: 40.69% done, finished in 0:21 at Sat Apr 5 09:02:58 2008
DUMP: 57.26% done, finished in 0:14 at Sat Apr 5 09:01:02 2008
DUMP: 72.60% done, finished in 0:09 at Sat Apr 5 09:00:33 2008
DUMP: 87.49% done, finished in 0:04 at Sat Apr 5 09:00:24 2008
DUMP: 99.99% done, finished soon
DUMP: DUMP: 4095026 tape blocks on 1 volume
DUMP: finished in 2130 seconds, throughput 1922 KBytes/sec DUMP: level 0 dump on Sat Apr 5 08:26:03 2008
DUMP: Closing /dev/sa0
DUMP: DUMP IS DONE
В этом выводе присутствует довольно много важных сведений. Во-первых, dump выводит текущую дату и дату последней операции резервного копирования. Дата, что показана здесь, the epoch, – это лишь необычный способ сказать: «от начала времен». Как известно, эпоха UNIX началась в 1970 году, что не так давно, как можно было бы подумать. В действительности же это означает, что в файле /etc/dumpdates отсутствует какая-либо информация о резервном копировании этого раздела раньше, но это совсем не означает, что резервирование никогда не производилось.
Прежде чем приступить к работе, dump напоминает, какой раздел будет копироваться и какой накопитель на магнитной ленте будет использоваться .
Затем dump выполняет предварительный анализ указанного раздела, выясняет структуру файлов и каталогов и прикидывает, какой объем пространства на ленте потребуется . Выполнив необходимые вычисления, dump выводит результаты и приступает к резервному копированию файлов . Через каждые несколько минут dump сообщает, как далеко удалось продвинуться и сколько еще времени потребуется для полного завершения операции, благодаря чему у вас не будет появляться ощущение, что компьютер завис. Обратите внимание, как изменяется процент выполнения и немного варьируется примерное время завершения – суть в том, что любые программные таймеры, сообщающие пользователю примерное время, оставшееся до окончания операции, никогда не обладали и, наверное, никогда не будут обладать высокой точностью, независимо от используемой операционной системы.
Завершив операцию, dump сообщит объем заархивированных данных и среднюю скорость работы à, а затем еще раз выведет дату . Это не дата окончания операции – это дата создания резервной копии. Операция завершилась в 9 часов утра, но резервное копирование производилось со снимка файловой системы, который был сделан в 8:26.
В заключение еще раз сообщается, что операция закончена , и теперь можно вынимать ленту из привода.
Пропуск данных, помеченных флагом nodump
C помощью ключа –h системный администратор может указать, когда следует принимать во внимание флаг nodump. Этот ключ принимает уровень резервирования в качестве аргумента.
По умолчанию на уровне 0 dump архивирует все файлы, независимо от наличия флага nodump. На уровне 1 или выше dump учитывает флаг nodump. Ключ –h изменяет поведение утилиты по умолчанию и указывает минимальный уровень резервирования, начиная с которого следует учитывать флаг nodump. На любых других уровнях резервирования ниже указанного копироваться будут все файлы, независимо от наличия флага nodump.
Это дает возможность регулировать объем архивирования на уровне 0. Если резервная копия перестала умещаться на ленту, воспользуйтесь ключом –h, чтобы предотвратить резервирование файлов, отмеченных флагом nodump. Это даст вам передышку на пару дней, в течение которых вы сможете заказать новые ленты.
Восстановление из архива 139 Восстановление из архива
Архивы – это замечательно, но они бесполезны, если с их помощью нельзя восстановить систему. Утилита для восстановления данных, restore(8), позволяет извлекать либо целые файловые системы, либо отдельные файлы. Как и в случае с tar и dump, ключ –f позволяет выбрать устройство или файл, из которого будут восстановлены данные.
Проверка содержимого архива
Для вывода списка файлов, находящихся в архиве, следует указать ключ –t.
# restore —t
Dump date: Sat Apr 5 08:26:03 2008
Dumped from: the epoch
Level 0 dump of /usr on test1.blackhelicopters.org:/dev/ad0s1f Label: none
2 .
3 ./.snap
94208 ./bin
97995 ./bin/bc
…
Утилита restore позволяет узнать, когда была сделана резервная копия , что было скопировано и на каком уровне резервирования. После этого она выводит имена всех файлов в архиве и их местоположение в файловой системе. Для каждого файла выводится номер индексного дескриптора (inode) . (Об индексных дескрипторах мы поговорим в главе 8.)
Следует заметить, что пути к файлам указаны относительно их местоположения в оригинальной файловой системе. Мы создали резервную копию корневой файловой системы, которая здесь представлена символом точки . В действительности это корневой каталог файловой системы /usr, или просто каталог /usr. Полное имя файла ./bin/bc в оригинальной файловой системе на самом деле было не /bin/bc, а /usr/bin/bc.
Об этом необходимо постоянно помнить при поиске конкретных файлов в архивах. Для проверки присутствия некоторого файла в архиве можно использовать ключ –t. Предположим, что необходимо восстановить файл /usr/home/mwlucas/.cshrc. Первое, что приходит в голову, – это проверить наличие файла в архиве:
# restore —t /usr/home/mwlucas/.cshrc
…
./usr/home/mwlucas/.cshrc is not on the tape
Как так? Файл отсутствует на ленте? Где мои данные? Пора кричать «караул»? Конечно нет, подождите паниковать. Вспомните, этот архив понятия не имеет о существовании каталога /usr – все сохраненные пути файлов записаны относительно каталога /usr. Нужно искать файл home/mwlucas/.cshrc.
# restore —t home/mwlucas/.cshrc …
871426 ./home/mwlucas/.cshrc
Уф-ф! Файл .cshrc присутствует в архиве. Попробуем теперь извлечь его.
Извлечение данных из архива
Как только стало известно, что тот или иной файл есть в архиве, его можно получить двумя способами: или извлекать файл за файлом, или восстановить всю файловую систему.
Восстановление файла
Если надо извлечь лишь некоторые данные, следует задать ключ –x и имя файла. В этом случае будет извлечен только указанный файл. Например, для восстановления .cshrc из архива, записанного на ленту, надо набрать следующую команду:
# restore —x home/mwlucas/.cshrc
You have not read any tapes yet.
If you are extracting just a few files, start with the last volume
and work towards the first; restore can quickly skip tapes that
have no further files to extract. Otherwise, begin with volume 1.
(Пока вы не прочитали ни одну ленту. Если вы не знаете, на каком томе находятся файлы, необходимо начать с последнего тома и двигаться к первому; restore может быстро пропускать ленты, где нет файлов, предназначенных для извлечения. В противном случае начните с первого тома)
Specify next volume #: 1
(Укажите следующий том)
set owner/mode for ‘.’? [yn] y
(установить владельца/права доступа для ‘.’ ?)
В первую очередь restore просит ввести номер тома . Это порядковый номер ленты, из тех, что были использованы для создания данной резервной копии. Если архив записывался на несколько лент, dump(8) должна была сообщить вам номера лент, которые менялись в процессе копирования. (Надеюсь, вы правильно промаркировали ленты?) Если копия уместилась на одну ленту, то это будет том с номером 1.
Как только утилита restore отыщет файл, она предложит сохранить его с оригинальными правами доступа и признаком принадлежности файла . В данном примере я хотел остаться владельцем файла, поэтому в ответ на вопрос я ввел y. После выполнения операции в текущем каталоге появится каталог home/mwlucas с файлом .cshrc внутри.
Восстановление файловой системы
Восстановить всю файловую систему достаточно просто, надо лишь помнить, что лучше не восстанавливать файловую систему поверх существующей. Если требуется серьезное восстановление, то безопаснее удалить раздел и начать все заново. Если необходимо сохранить некоторые файлы из поврежденной файловой системы, заархивируйте эти файлы в отдельный архив, отформатируйте раздел, восстановите файловую систему из резервной копии, а затем скопируйте отобранные ранее файлы на место.
В следующем примере будет удален раздел на втором жестком диске, а затем данные будут восстановлены с резервной ленты. Работа с диском здесь не будет подробно рассматриваться (дополнительную информацию см. в главе 8), однако все действия в общем виде можно представить так:
- Создание новой файловой системы с помощью newfs.
- Присоединение этой файловой системы к дереву каталогов, в /mnt.
- Переход в этот каталог.
- Восстановление файловой системы с ленточного устройства по умолчанию /dev/sa0.
Вот эти команды:
# newfs /dev/ad1s1g
# mount /dev/ad1s1g /mnt # cd /mnt
# restore —r
Все настолько просто, что у вас может даже появиться желание уничтожить содержимое файловой системы только ради того, чтобы восстановить ее, не так ли?
Восстановление и последующее резервирование
Когда бы ни проводилось полное восстановление диска, перед следующим после него инкрементным дампом необходимо выполнить дамп уровня 0. restore(8) изменяет положение данных на диске. Если попытаться создать инкрементный дамп вновь восстановленной файловой системы и попытаться использовать его вместе с прежним дампом уровня 0, это приведет к повреждению данных. Всегда создавайте дамп уровня 0 сразу после восстановления файловой системы, чтобы обеспечить корректность последующих инкрементных дампов. Кроме того, нужно помнить, что при выполнении полного резервирования жить будет намного легче.
Интерактивное восстановление
Одна из наиболее интересных особенностей restore(8) – интерактивный режим (–i), позволяющий «вскрыть» дамп и получить доступ к нему с помощью инструмента командной строки. При этом можно указать файлы, которые необходимо восстановить. Интерактивный режим бывает весьма кстати, когда пользователь говорит примерно следующее: «Я случайно удалил файл с резюме. Он лежал в моем домашнем каталоге, а в его имени было слово resume. Точного имени не помню. Можно его восстановить?» Ясно, что ключ –t не поможет; точное название файла неизвестно! Вместо этого можно перейти в интерактивный режим и поискать этот файл. Это совсем несложно, а пользователь останется вам обязан.1 Запустите restore с ключом –i, и вы получите доступ к интерактивному сеансу с командной строкой, которая ведет себя почти так же, как обычная командная строка UNIX, но поддерживает только команды, необходимые для восстановления. В зависимости от типа ленточного накопителя может потребоваться одна-две минуты, прежде чем появится командная строка.
# restore —i
restore > ls
.:
.snap/ bin/ games/ include/ libdata/ local/ ports/ share/ X11R6/ compat/ home/ lib/ libexec/ obj/ sbin/ src/ restore > cd home/mwlucas
Здесь нет ничего необычного – это содержимое каталога верхнего уровня в файле дампа, в данном случае – каталога /usr. По нему можно продвигаться, используя команду cd, и выводить списки файлов с помощью команды ls, как в обычной командной оболочке. Найдя необходимый файл, его можно восстановить, для этого нужно добавить его в список извлекаемых файлов с помощью команды add. Когда все необходимые файлы будут добавлены в список, можно запустить процедуру восстановления с помощью команды extract.
restore > add ssh.tar
restore > add .cshrc
restore > extract
You have not read any tapes yet.
(Ни одна лента еще не была прочитана) …
Последующий процесс выглядит точно так же, как и восстановление в неинтерактивном режиме, – restore предложит указать номер тома и спросит, необходимо ли восстанавливать права доступа к файлам. По завершении выбранные файлы появятся в текущем каталоге.
Завершив восстановление файлов, можно завершить интерактивный сеанс работы с помощью команды quit.
Оставшись в долгу, пользователь будет стремиться не совершать подобных ошибок, потому что это даст вам возможность не только оплачивать уход за своей лужайкой. Секрет успеха системного администратора кроется в его профессионализме, в чувстве юмора и в бейсбольной бите.
Создание нескольких резервных копий на одной ленте
Если ленточный накопитель обладает достаточно большой емкостью, на одной ленте можно сохранять несколько резервных копий. dump(8) позволяет за один раз копировать только один раздел, и все же держать отдельные ленты для хранения копий каждого раздела весьма неэффективно. С помощью утилиты tar(1) можно сохранять несколько резервных копий на одну ленту, поскольку в этом случае можно с помощью команды mt(1) управлять перемоткой ленты.
Вспомните, использование файла устройства по умолчанию в утилитах mt, tar и dump приводит к автоматической перемотке ленты после каждой операции. Это означает, что вторая резервная копия затрет первую. Изменив используемый файл устройства, можно изменить поведение накопителя. Если запускать резервное копирование без перемотки, то вторая резервная копия запишется на лету как второй файл. Управляя текущей позицией ленты, можно выбирать, где производить запись или чтение данных.
Например, следующие команды запишут резервные копии трех файловых систем – /, /var и /tmp – на одну и ту же ленту:
# dump —f /dev/nsa0 —auL /
# dump —f /dev/nsa0 —auL /var # dump —f /dev/nsa0 —auL /tmp
Теперь текущая позиция на ленте соответствует концу третьего файла. Ленту можно перемотать и извлечь из накопителя, надписать на ней имена содержащихся файлов, дату копирования и спрятать в надежное место.
Если необходимо определить количество резервных копий на ленте, достаточно запустить команду mt status и посмотреть на последнюю строку.
…
File Number: 3 Record Number: 0 Residual Count 0
Обратите внимание, что номер файла стал равен 3. То есть на ленте записано три файла.
Чтобы получить доступ к файлу, необходимо выполнить позиционирование ленты в накопителе на начало файла и с помощью tar или restore прочитать данные с ленты. После перемотки ленты текущая позиция соответствует началу первого файла. Чтобы переместиться к одному из следующих файлов, следует использовать команду fsf утилиты mt(1). Команда mt fsf принимает один аргумент – количество файлов, которые необходимо пропустить. Если предположить, что изначально считывающая головка накопителя находится в начале первого файла, тогда, чтобы переместиться ко второму файлу, достаточно выполнить команду:
# mt —f /dev/nsa0 fsf 1
В результате лента будет перемотана на один файл вперед. Обратите внимание на ключ –f /dev/nsa0, благодаря которому используется файл устройства, который «не перематывает» ленту. Было бы бессмысленно сначала выполнить переход на один файл вперед, а затем автоматически перемотать ленту.
Теперь с помощью ключа –t программы извлечения файлов из архива можно ознакомиться с содержимым этого файла. Резервную копию легко можно идентифицировать по ее содержимому, поскольку при использовании ключа –t restore(8) выводит даже дату и время копирования, а также имя раздела, с которого была сделана копия. Для перемещения по ленте в обратном направлении используется команда mt bsf, которой передается число файлов, которые нужно пропустить.
Ленты требуют немного иного мышления, чем диски, но в действительности это совсем несложно и к тому же ленты по-прежнему широко используются для резервного копирования. Теперь рассмотрим некоторые другие методы защиты вас, ваших данных, вашей системы и того, что мы, системные администраторы, со смехом называем нашими мозгами.
Управление версиями
Вообще говоря, управление версиями (revision control) – это процесс отслеживания изменений. В мире UNIX под этим понимаются изменения в исходном коде и в файлах конфигурации. Управление версиями позволяет разработчику видеть, как некий фрагмент кода выглядел в определенный момент. Администратор может представить, как была сконфигурирована система до возникновения неполадок. Управление версиями может быть полезно даже скромному писателю – он может увидеть, как менялась рукопись с течением времени. Если не применять этот механизм, работа будет труднее, чем ей положено быть.
Несмотря на то, что существует много систем управления версиями, от системы управления исходным кодом SCCS (Source Code Control System) в UNIX до Visual SourceSafe компании Microsoft, здесь будет рассмотрена система управления версиями RCS (Revision Control System), входящая почти во все системы UNIX. После изучения RCS работать с большинством других систем управления версиями будет просто.
При управлении версиями, по существу, сохраняется информация обо всех изменениях, сделанных в файле, а также описание причин, вызвавших эти изменения. Во-первых, файл помечается как захваченный (checked out). Это знак системе, что файл будет изменяться. Далее файл можно отредактировать, затем записать изменения в системе, а затем файл можно передать (check in) другим пользователям для последующего редактирования. Для поддержки этих действий RCS применяет три команды: ci(1) (check in, регистрация), co(1) (check out, захват) и rcs(1).
Передовые методы управления версиями
В моей многолетней практике системного администратора я встречал множество методов управления версиями. Пожалуй, самый распространенный способ состоит в сохранении копий всех файлов с датой сохранения в виде расширения (например, rc.conf. 20060510). Однако такую методику никак нельзя назвать хорошей, более того – это плохая практика. Нет никакой гарантии, что при таком подходе будут сохраняться все изменения и отсутствует система слежения, с помощью которой можно было бы оставить комментарий, описывающий причины, вызвавшие эти изменения. Как сказал один мой товарищ: «RCS – это как горькое лекарство, которое необходимо пить, иначе вы не пойдете на поправку». Чтобы овладеть навыками работы с RCS, необходимо принуждать себя пользоваться ею, и через несколько месяцев вы будете удивляться – как вы вообще без нее обходились.
Управление версиями напоминает библиотеку – нет, не электронную библиотеку, а обычную, старую добрую библиотеку с книгами, отпечатанными на бумаге. Чтобы задействовать систему управления версиями, прежде всего надо указать системе RCS на необходимость отслеживания файла – поместить его в библиотеку. Чтобы приступить к работе с этим файлом, его необходимо получить, как книгу в библиотеке. Если файл выдан, то никто иной не может его сохранять или редактировать, хотя любой законный пользователь в то же время может просматривать, копировать, компилировать этот файл – обращаться к нему. После завершения работы с файлом он сдается обратно (check in) и становится доступен для редактирования другими пользователями. Такой порядок действий составляет основу любой системы управления версиями, а про файлы, находящиеся под контролем системы управлениями версиями, говорят, что они находятся в RCS.
В RCS каждый файл имеет номер версии. Всякий раз, когда отредактированный файл возвращается в систему, RCS сравнивает возвращаемый файл с выданным. При наличии хоть каких-то изменений эти изменения сохраняются, а номер версии увеличивается на единицу, вместе с датой и причиной изменений. Номер версии можно применять для идентификации отдельных версий файла.
Инициализация управления версиями
Процесс управления версиями начинается с регистрации файла с помощью ci(1), что напоминает сдачу книги в библиотеку. Например, хороший кандидат для защиты с помощью RCS – файл /etc/rc.conf. Для начала надо ввести ci filename, как показано в следующем листинге:
# ci rc.conf
rc.conf,v <-rc.conf
enter description, terminated with single ‘.’ or end of file: NOTE: This is NOT the log message!
>> system configuration file
>> .
initial revision: 1.1
done
При первой регистрации файла с помощью ci эта команда создает или редактирует файл управления версиями. Этот файл получает то же имя, что и оригинальный файл, но с расширением ,v. В данном примере файл rc.conf превращается в rc.conf,v . Далее система запрашивает описание файла, и его надо ввести, чтобы позднее каждый пользователь RCS мог понять, что это за файл. Это описание не так уж важно для стандартных системных файлов, таких как rc.conf, – для него вполне достаточно краткого описания system configuration file, как задано в этом примере . Более подробное описание будет очень полезно для исходного кода или файлов конфигурации самостоятельно разработанных или сложных программ. После того как описание набрано, для завершения работы ci следует ввести точку на отдельной строке . После этого будет выведен номер версии файла , который в первый раз всегда равен 1.1.
Если сразу после регистрации файла запустить ls, то можно увидеть, что файл как будто исчез. Вместо этого появится файл с тем же именем, но с замыкающими символами ,v. Это файл RCS, в котором хранятся сам файл и его изменения. Если в RCS хранится много файлов, то файлы с расширением ,v могут вносить некоторый хаос. Чтобы этого не происходило, достаточно создать каталог с именем RCS (все символы заглавные), и тогда программа ci будет сохранять файлы ,v в этот каталог, не засоряя рабочий каталог.
Для некоторых файлов не важно, что они «исчезают» при передаче, но файлы с настройками или веб-страницами не могут просто исчезнуть. Чтобы решить эту проблему, при регистрации файла нужно оставить его копию в рабочем каталоге. Для этого надо запустить ci –u. Если файл исчез, а его копию необходимо поместить в рабочий каталог без редактирования файла, надо выполнить команду co(1).
# co rc.conf
rc.conf,v —> rc.conf revision 1.1
done
Так как компьютер не в состоянии выполнить корректную загрузку без файла rc.conf, очень важно обеспечить доступность этого файла. Система RCS извлекла файл rc.conf из rc.conf,v , и теперь версия 1.1 этого файла доступна для использования. Если внимательнее приглядеться к этим файлам, можно увидеть нечто удивительное.
# ls —l rc.conf*
-r—r—r-1 root wheel 321 Apr 10 21:40 rc.conf -r—r—r-1 root wheel 527 Apr 10 21:33 rc.conf,v
Владелец этого файла – пользователь root, однако права доступа – «только для чтения» (–r––r––r––). Даже при том, что я знаю пароль пользователя root, я не имею права редактировать свои файлы! Дело в том, что файл не был захвачен мной. Файл был зарегистрирован и передан библиотекарю Revision Control System. Я могу просматривать этот файл, но для его редактирования нужно попросить разрешения у системы RCS.
Предупреждение для тех, кто использует редактор vi(1)
Предупреждение для пользователей vi: если вы или ваша группа владеете файлом, команда w! вызовет изменение прав доступа и позволит вам осуществлять запись в файл даже без его регистрации. Все будет выглядеть замечательно, однако следующий пользователь, который зарегистрирует файл, перезапишет ваши изменения! Будьте осторожны с этой командой; если vi говорит, что у вас нет прав на сохранение файла, это весомое предупреждение, к которому лучше прислушаться. Вы можете проигнорировать это предупреждение на свой страх и риск.
Редактирование файлов, находящихся в RCS
Чтобы отредактировать файл, его сначала необходимо получить и заблокировать для единоличного использования. Это не позволит редактировать файл другим пользователям, пока тот, кто заблокировал файл, не сделает необходимые изменения. Чтобы получить и заблокировать файл, следует использовать команду co –l:
# co —l rc.conf rc.conf,v —> rc.conf revision 1.1 (locked) done
Операция получения файла выглядит почти так же, как и раньше, но обратите внимание на слово locked . Этот файл захвачен и заблокирован. Только пользователь, выполнивший блокировку, может сохранять этот файл, пока он не будет разблокирован. Запустив после этой операции ls –l еще раз, можно увидеть, что права доступа к файлу снова разрешают чтение и запись, а значит, этот файл можно сохранять (права доступа рассматриваются в главе 7). Любой, кто попытается захватить этот файл, получит предупреждение о том, что файл используется, при этом будет указано имя того, кто этот файл заблокировал.
Повторная регистрация
После завершения работы с файлом его можно зарегистрировать и снять блокировку, чтобы другие пользователи могли его редактировать. Чтобы оставить незаблокированную копию файла в текущем каталоге, следует использовать ключ –u.
# ci —u rc.conf
rc.conf,v <-rc.conf
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single ‘.’ or end of file: >> clean up unneeded services
>> .
done
При передаче файла в систему RCS команда ci присвоит ему новый номер версии и запросит сообщение, которое будет записано в протоколе . Здесь надо ввести краткое описание внесенных изменений. В многопользовательской системе, возможно, понадобится описать причины, по которым были сделаны изменения. Если у вас работает система регистрации сообщений об ошибках, будет нелишним перечислить в описании номера сообщений, благодаря этому пользователи смогут получать полную историю изменений, сославшись на номер сообщения. Как и при первой регистрации, текст описания следует завершить символом точки на отдельной строке .
Благодаря сообщениям, хранимым в протоколе, другие пользователи легко узнают обо всех сделанных изменениях или могут увидеть, какие попытки предпринимались при ошибочных изменениях, когда кому-либо приходилось начать отладку. Протоколы RCS могут быть полезны и владельцу файла, спустя несколько месяцев удивленно пытающемуся вспомнить, о чем же он думал в то время.
Теперь, когда ясны основы регистрирования и захвата файлов, исследуем более интересные функции RCS: получение старых версий файлов, снятие блокировок, нахождение различий между версиями файлов и помещение идентификаторов RCS в файлы.
Просмотр протоколов RCS
Самый простой способ просмотреть историю изменений файла – это просмотреть протокол RCS с помощью команды rlog(1). Эта команда отобразит все сообщения, которые были введены для указанного файла. В приведенном ниже примере выполняется извлечение сообщений из протокола RCS для файла rc.conf, расположенного на другой машине:
# rlog rc.conf
RCS file: RCS/rc.conf,v Working file: rc.conf
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
system boot config
—————————-
revision 1.3
date: 2006/02/17 22:23:45; author: mwlucas; state: Exp; àlines: +2 -2 rename new interfaces
—————————-
revision 1.2
date: 2006/02/16 20:09:46; author: mwlucas; state: Exp; lines: +4 -0
*** empty log message ***
—————————-
revision 1.1
…
Здесь представлена вся полезная информация. Здесь видно, что файл RCS находится в каталоге с именем RCS и что файл имеет номер версии 1.3 . Описание файла, которое было введено при первой регистрации, расположено первым .
Затем следуют отдельные записи для каждой версии. Версия 1.3 была зарегистрирована 17 февраля 2006 года в 22:23. Файл был зарегистрирован пользователем mwlucas – очевидно, я допоздна задержался на работе. Изменения были не очень большими – в файл были добавлены две новые строки и две строки были удалены à. Наконец, протокольное сообщение говорит о том, что были переименованы два интерфейса . Я совершенно не помню, чтобы делал это, впрочем, это и неудивительно, раз я работал так поздно!
Самое интересное, что отсутствует описание для версии 1.2. Очевидно, в этот день я был небрежен. Интересно, что я изменил?
Просмотр истории версий файла
Увидеть отличия между двумя версиями файла позволяет команда rcsdiff(1). Эта программа принимает три аргумента: два номера версий и имя файла, как показано ниже. Я рекомендую добавлять ключ –u, чтобы различия выводились в более удобочитаемом виде.
# rcsdiff -u -rolderversionnumber -rnewerversionnumber filename
Например, запустив команду rcsdiff –u –r1.1 –r1.2 rc.conf, я мог бы увидеть примерно следующее:
RCS file: RCS/rc.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2
—rc.conf 2006/02/10 18:09:54 1.1
+++ rc.conf 2006/02/16 20:09:46 1.2
@@ -10,12 +10,16 @@
ifconfig_sk0=»name internet inet 172.16.88.3 netmask 255.255.255.0″ ifconfig_sk1=»name dmz inet 192.168.3.1 netmask 255.255.255.0″ ifconfig_sk2=»name mwlprivate inet 192.168.0.1 netmask 255.255.255.252″ +
+
usbd_enable=»YES»
sshd_enable=»YES»
ntpd_enable=»YES»
-syslogd_flags=»-l /var/run/log -l /var/named/var/run/log» moused_enable=»YES»
named_enable=»YES»
apache21_enable=»YES»
+snmpd_enable=»YES»
Команда rcsdiff просто извлекает две версии указанного файла и затем передает их утилите diff(1) . Команда rcsdiff распознает большую часть ключей утилиты diff(1), поэтому, если вы знакомы с diff, то с помощью этих ключей вы можете настраивать вывод результатов под себя. Строки, начинающиеся с символа «плюс» (+) , были добавлены в файл, а строки, начинающиеся с символа «минус» (–) , были удалены. В данном случае было добавлено несколько пустых строк, удалена переменная syslog_flags (тем самым был выполнен возврат к поведению по умолчанию, которое описано в файле /etc/defaults/ rc.conf) и добавлен запуск демона snmpd . Теперь все понятно. Жаль, что я не оставил описание для себя самого, чтобы потом не приходилось копаться в отличиях версий, но хотя бы я знаю, что было сделано. Наличие такой возможности очень удобно, особенно на рабочих системах, и особенно на тех, которые администрируются несколькими администраторами.
При запуске rcsdiff можно задавать произвольные номера версий. Это позволяет просмотреть изменения, выполненные в период между созданием любых двух версий. В предыдущем примере мы просмотрели различия между двумя соседними версиями, но точно так же я мог бы затребовать сведения о различиях между версиями 1.1 и 1.3 или даже все изменения, которые были произведены в течение предыдущего года.
Получение старых версий
Если различия между двумя версиями файла слишком велики, их просмотр может оказаться непростым делом. В некоторых случаях diff не в состоянии предоставить достаточный контекст, чтобы понять эти изменения. В подобной ситуации проще будет получить старую версию файла и ознакомиться с ней. Чтобы извлечь старую версию файла из RCS, следует использовать ключ –r. Номер версии следует указывать сразу вслед за ключом –r, без пробела:
# co —r1.1 rc.conf rc.conf,v —> rc.conf revision 1.1
done
Здесь была извлечена версия 1.1, которая перезаписала существующий файл rc.conf.
Минутку! Перезаписывать существующие файлы, особенно те, что имеют жизненно важное значение для системы, – это неправильно. Чтобы указать иное место сохранения извлекаемого файла, следует использовать ключ –p, благодаря которому содержимое файла будет выводиться на экран, и этот вывод можно перенаправить в файл.
# co —r1.1 —p rc.conf > /tmp/rc.conf.original rc.conf,v —> standard output
revision 1.1
Здесь выполняется получение файла rc.conf версии 1.1 , благодаря наличию ключа –p содержимое файла будет выводиться непосредственно на терминал. Правая угловая скобка (>) перенаправляет вывод в файл, в данном случае /tmp/rc.conf.original.
Снятие блокировок
Если вы не передали файл обратно в RCS, никто не сможет получить его и заблокировать. Если в течение дня вы уйдете домой, это может задеть других и может быть даже рассердить. Если вы ушли в отпуск, будьте готовы к тому, что его прервут. К счастью, нет никакой необходимости ждать вашего возвращения, чтобы разблокировать файл – ваши коллеги могут снять вашу блокировку и получить файл. Это как библиотекарь, который пришел к вам домой с бензопилой в руках и намекнул, что пора возвращать книгу.
Как потенциальный взломщик блокировок, вы должны быть предусмотрительны. Если кто-то действительно вносит изменения в файл в то время, как вы снимаете блокировку, то хозяина это не только не обрадует, но и серьезно разозлит. Поэтому постарайтесь сначала найти этого человека, прежде чем снимать блокировку! Однако, если вы всетаки решили снять блокировку, запустите для выбранного файла команду rcs –u. RCS попросит ввести сообщение, объясняющее причину снятия блокировки, которое будет послано по электронной почте пользователю, заблокировавшему файл.1
После снятия блокировки файл становится доступен другим пользователям для редактирования. Однако изменения, сделанные беспечным взломщиком, останутся в файле. Когда кто-то выполнит повторную передачу файла в RCS, эти изменения будут затерты. Поэтому, если эти изменения имеют большое значение, желательно скопировать файл куда-нибудь на временное хранение, пока вы не сможете получить и заблокировать файл снова.
Автоматизированный поиск блокировок
Поиск в Интернете позволит вам выяснить массу методов идентификации всех файлов, которые были оставлены в заблокированном состоянии. Если в вашей системе пользователи постоянно оставляют файлы заблокированными, можно попробовать выполнять поиск заблокированных файлов и тех, кто их заблокировал, с помощью cron и ежедневно автоматически отправлять списки нарушителей группе системных администраторов.
Получение нескольких файлов
Регистрация сразу нескольких файлов, участвующих в едином изменении, – довольно редкая ситуация. Например, изменение в DNS может потребовать вносить изменения сразу в два или более файла зон (глава 14). Для этих файлов обычно требуется оставить одно протокольное сообщение, а вам едва ли захочется вводить его несколько раз. Для примера я зарегистрирую файлы blackhelicopters.org.db и absolutefreebsd.com.db с протокольным сообщением update for new mail server.
# ci —u —m»update for new mail server» blackhelicopters.org.db absolutefreebsd.com.db
Обратите внимание на отсутствие пробела между ключом –m и кавычками, окружающими текст сообщения. Система RCS зарегистрирует все файлы из списка и к каждому из них добавит заданное сообщение в протокол.
RCS и строки идентификации
Строки идентификации (ident strings) позволяют упростить просмотр сведений о том, кто и когда изменял тот или иной файл. Так, если последнюю неделю сервер ведет себя странно, полезно знать, что изменилось неделю назад. Конечно, можно запустить rlog(1) для каждого конфигурационного файла системы и проанализировать изменения, но это немного утомительно. Куда лучше просто взглянуть на файл, в котором представлена вся необходимая информация. Вот где нужны строки идентификации. Эти строки можно поместить в файлы, сохраняемые в RCS. Когда пользователь захватывает файл, RCS автоматически обновляет эти строки.
Строки идентификации имеют формат $string$. Например, в строке $Id$ размещается информация о последнем изменении в файле. Всегда полезно разместить #$Id$ в первой строке важных конфигурационных файлов, таких как /etc/rc.conf. Первый символ # сообщит сценарию /etc/rc, что это комментарий и строку следует пропустить, но когда файл будет зарегистрирован в RCS, она примет следующий вид:
#$Id: rc.conf,v 1.3 2006/04/12 17:12:49 mwlucas Exp $
Простая строка идентификации была дополнена системой! Здесь можно увидеть номер версии файла , дату и время последнего изменения и имя пользователя, выполнившего это изменение . Это дает возможность легко ответить на вопрос: «Файл изменялся, и с кем теперь нужно поговорить об этом изменении?» Последний элемент строки – состояние RCS, произвольная строка, которую можно назначить с помощью ci(1) или rcs(1). Для файла можно задать произвольные состояния, которые позволяют понять назначение файла и условия его использования. Многие люди применяют эту строку, чтобы пометить файл как «экспериментальный» или «рабочий» или указать: «Ничего не меняйте ни по каким причинам». Обычно в системном администрировании строка состояния RCS не применяется.
Строка идентификации $Id$ встречается чаще всего, но имеются и другие строки подобные строки, например $Header$ и $Log$. $Header$ сходна с $Id$, за исключением того, что она сообщает полный путь к файлу RCS, а не просто имя файла. $Log$ – интересная строка идентификации, добавляющая протокольные сообщения RCS к самому файлу; при просмотре файла эти сообщения можно увидеть. Они могут переполнять интенсивно редактируемые файлы, но могут быть полезными для файлов, которые изменяются редко. Так, /etc/rc.conf на рабочей системе может вообще не изменяться месяц. Если описываемую строку идентификации поместить в этот файл, в нем можно будет просматривать все протокольные сообщения RCS. Сразу станет ясно, что изменено, кем и почему. Большинство других строк идентификации по сути являются подмножеством строк $Id$, $Header$ и $Log$. Полный перечень строк идентификации вы найдете в странице руководства ident(1).
Теперь, когда вы узнали, как создавать резервные копии системы и отслеживать вносимые изменения, вы можете более спокойно выполнять свою работу, зная, что в любой момент сможете восстановить систему в состояние, предшествующее последним изменениям.
Запись происходящих событий
Теперь вы можете создавать резервные копии системы, а также отслеживать изменения, производившиеся в единственном файле. Нам осталось лишь научиться выводить на экран информацию о происходящих событиях. Программа script(1) – один из редко упоминаемых, но довольно полезных инструментов, о которых должен знать каждый системный администратор. Она записывает все набранные команды, а также все, что появляется на экране. Этот инструмент можно использовать для записи ошибок или большого вывода команд, который можно проанализировать впоследствии. Например, если программа всякий раз спотыкается на одном и том же месте, можно задействовать script для копирования набранных строк и ответов, появляющихся на экране. Это особенно полезно при обновлении системы или компоновке программного обеспечения из исходного кода; последние 30 строк (или около того) файла протокола представляют собой прекрасное дополнение к письму о помощи.
Чтобы запустить script(1), достаточно просто ввести команду script. После этого вы вернетесь в командную оболочку и сможете продолжить свою обычную работу. Когда потребуется остановить запись, достаточно просто ввести команду exit или нажать комбинацию клавиш Ctrl-D. Все ваши действия будут записаны в файл typescript. Если потребуется дать файлу другое имя или сохранить его в конкретном каталоге, достаточно просто передать команде script требуемое имя файла в виде параметра:
# script /home/mwlucas/debug.txt
В письмо о проблеме, отправляемое в почтовую рассылку FreeBSD—[email protected], будет чрезвычайно полезно добавить точную запись того, что вводилось с клавиатуры и что выводилось на экран в ответ.
Диск восстановления
Наилучший способ изучить UNIX состоит в том, чтобы поиграть с этой системой, и чем труднее игра, тем больше можно узнать. Если игра идет не на шутку, что-нибудь обязательно «полетит». Восстановление неработоспособной системы, возможно, является самой короткой дорогой к получению знаний. Этот раздел предназначен для тех, кто помог системе перестать загружаться или планирует достаточно быстро набраться знаний, чтобы решиться на это. Вам придется научиться многому и быстро, хотя, в основном, и самостоятельно.
Однопользовательский режим (обсуждается в главе 3) дает доступ к множеству различных команд и инструментов. Что, если будет уничтожен один из таких инструментов? Возможно, вам даже удастся уничтожить программы в каталоге /rescue. Это как раз та ситуация, когда в дело идет диск восстановления.
Диск восстановления – это образ «действующей файловой системы» FreeBSD на компакт-диске. Он включает в себя все программы, которые по умолчанию поставляются в составе FreeBSD. Можно начать загрузку с установочного носителя, но вместо установки ОС выбрать режим восстановления (fixit mode).
Чтобы успешно применять систему восстановления, необходимо в какой-то мере понимать системное администрирование. По существу, диск восстановления предоставляет в ваше распоряжение командную строку и множество утилит UNIX. Для устранения неполадок необходимо задействовать свою голову и проанализировать сообщения об ошибках, выданные во время загрузки. Вы – против компьютера. В первых трех случаях из шести, когда я прибегал к помощи диска восстановления, победу одерживал компьютер. Однако время было потрачено не зря, поскольку теперь мне по силам восстановить поврежденную систему. Эту книгу определенно следует прочесть до конца, прежде чем пытаться что-то делать.
Пошаговое изложение процесса восстановления не представляется возможным; последовательность действий целиком зависит от ущерба, причиненного бедному, невинному компьютеру. Не надо отчаиваться – режим восстановления поможет избежать полной переустановки системы. Бывало, я случайно уничтожал каталог /etc или «подвешивал» программу getty(1), которая отображает приглашения для ввода регистрационного имени (login prompt). Осмотрительное применение режима восстановления помогает найти выход в таких ситуациях за долю того времени, которое бы потребовалось для переустановки системы.
Примечание
Важно, чтобы диск восстановления примерно соответствовал запускаемой версии FreeBSD. Мелкие различия не играют роли, однако попытка восстановить систему 6.5 с помощью диска восстановления 8-current обречена на неудачу.
Начните загрузку с установочного носителя. В первом меню будет предоставлена возможность выбора режима восстановления. Выберите его. Далее выберите носитель: CD или дискету. Если CD есть, следует предпочесть его. (Дискета восстановления содержит только программы, которые можно разместить на одном гибком диске, тогда как на CD записан полный комплект программ, которые есть в комплекте FreeBSD.) Хотя на CD может не оказаться любимого редактора или предпочтительной оболочки, на нем есть все, что «действительно необходимо».
В некоторых случаях можно надеяться лишь на то, что удастся смонтировать жесткий диск и считать с него данные. Тут поможет компактдиск восстановления, содержащий все инструменты для подключения системы к сети, благодаря чему можно будет смонтировать жесткий диск в режиме «только для чтения» и скопировать жизненно важные данные на другой компьютер. Это даст вам возможность создать последнюю резервную копию, прежде чем снести систему и выполнить ее переустановку. Если диск восстановления не содержит всех инструментов, необходимых для проведения восстановления, можно попробовать загрузиться с компакт-диска, содержащего загружаемую версию FreeBSD, например FreeSBIE. Мы еще коснемся FreeSBIE в главе 20.
Теперь, когда вы можете восстановить систему практически после любой ошибки, начинаем погружение в сердце FreeBSD – ядро.
Добавить комментарий