Linux
Шрифт:
/tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash)
Для некоторых служб нужны права rw. Атрибут no_root_squash защищает систему NFS от отображения идентификатора суперпользователя в какой-либо другой. Если этот атрибут не будет задан, то различные демоны могут не заработать.
Теперь запустите службы NFS (rpc.portmap и rpc.mountd) и снова попробуйте бездисковую загрузку. Если все прошло удачно, то ядро сможет подмонтировать корневую файловую систему и пройти все стадии загрузки до появления приглашения входа в систему. Вполне вероятно, что по ходу загрузки у вас будут выдаваться сообщения о проблемах с некоторыми службами. Так и должно быть. Дистрибутивы Linux ориентированы на операции с диском, и поэтому для бездисковой загрузки требуются небольшие изменения. Самой большой неприятностью является зависимость
Конфигурация клиента
Чтобы клиент был правильно сконфигурирован, необходимо скомпилировать ядро операционной системы Linux с поддержкой корневой файловой системы на NFS. Кроме того, следует разрешить получение ядром IP-адреса из запроса ВООТР. Надо также вкомпилировать драйвер для вашей сетевой карты в ядро. Для уменьшения объема ядра можно отключить лишние свойства и опции.
Ядро, полученное после компиляции, необходимо преобразовать в загрузочный образ. Это делается аналогично тому, как мы создавали загрузочный образ дискеты для DOS. Для создания образа воспользуйтесь утилитой mknbi-linux. После создания загрузочного образа, поместите его в каталоге /tftpboot под именем, определенным в /etc/bootptab. Убедитесь, что файл доступен для чтения любому пользователю, потому что у TFTP-сервера нет специальных привилегий.
Дальнейшая проверка загрузки бездискового клиента должна подтвердить правильность наших настроек.
Ссылки
• www.linuxfocus.org/Russian/Septemberl998/article63.html – Кен Яп. Введение в сетевую загрузку и протокол Etherboot.
• alst.odessa.ua – Алексей Стахнов. Удаленная загрузка. Сервер Linux. Клиентская часть DOS, Windows 3.1. Инструкция по установке и настройке.
• www.slug.org.au/etherboot/.
• ftp.microsoft.com/bussys/clients/msclient/.
• ftp.microsoft.com/bussys/winnt/kb/Q142/0/62.txt.
• ftp.microsoft.com/bussys/winnt/kb/Q128/7/51.txt.
• Страницы man для пакетов Etherboot, Netboot.
• Соответствующие HOWTO (см. гл. 13).Глава 33 Резервное копирование и хранение данных
Резервное копирование выполняется с целью получения копий данных, сохраняемых на случай их потери или разрушения. Подобные копии должны создаваться периодически, в соответствии с заранее установленным графиком. Схемы резервного копирования изменяются в зависимости от размеров и степени охвата резервным копированием операционной системы, а также от выдвигаемых требований по надежности сохранения жизнеспособности системы. Элементы системы резервного копирования должны включать необходимое оборудование, носители резервных копий и специальное программное обеспечение. В качестве оборудования может использоваться достаточно широкий набор аппаратных средств, начиная от обычного дисковода и заканчивая библиотекой ленточных устройств. Тип и количество носителей определяются используемым оборудованием, объемами обрабатываемых данных и выбранной схемой резервирования данных. Используемое программное обеспечение может быть очень разнородным, начиная от бесплатных утилит типа tar, cpio, gzip и закашивая распределенными системами управления хранилищами данных.
Резервное копирование информации используется для:
• восстановления файлов, случайно удаленных пользователями или утерянных из-за отказов дисковых устройств;
• получения периодически создаваемых моментальных снимков (snapshots) состояния данных организации. Эта информация может широко использоваться для различных технических и деловых целей;
• получения данных для восстановления после аварий. Система резервного копирования обязательно является составной частью любого продуманного плана восстановления системы. В случае широкомасштабных катастроф данные доставляются из архивов, сохраняемых в отдельном помещении.
Планирование резервного копирования
При разработке системы резервного копирования одной из важнейших составляющих является выработка правильного набора требований к комплексу резервного копирования. Постарайтесь учесть все аспекты резервного копирования, сделайте два варианта сметы – минимально необходимый и желательный, и обоснуйте руководству
Основным фактором, определяющим стоимость системы резервного копирования, является объем архивируемых данных и время, выделяемое на эту процедуру. Чем больше объем данных, обрабатываемых системой резервного копирования в единицу времени, тем дороже получается создаваемая система. Если на проведение резервного копирования ваше серверное хозяйство может выделить ограниченный интервал времени, или если оно функционирует круглосуточно, при планировании системы резервного копирования следует учитывать это обстоятельство, поскольку изменение резервируемых данных до завершения создания резервной копии приводит к получению некорректной резервной копии системы. В том случае, если вы можете остановить работу сервера либо по окончании рабочего дня сервер не используется, процесс резервирования становится тривиальным и, как правило, достаточно дешевым.
Ежедневные процедуры копирования должны выполняться в то время, когда данные находятся в некотором стабильном состоянии, например после окончания рабочего дня. Если не представляется возможным исключить сервер на время создания резервной копии из производственного процесса, руководство фирмы должно знать о возможных осложнениях – обычно это не совсем корректное сохранение информации. В серьезных серверах баз данных об этой проблеме знают, и существуют методы получения точной резервной копии баз данных.
Большинство систем резервного копирования строится на использовании либо команды сгоп, либо собственных утилит автоматического вызова программ по установленному расписанию. Как правило, они позволяют разрабатывать и поддерживать относительно сложные графики проведения работ. Кроме того, системы резервного копирования могут предусматривать прямое взаимодействие с приложениями с целью запуска их собственных механизмов резервного копирования. Зачастую для целей резервного копирования используются программы и скрипты собственной разработки, учитывающие особенности функционирования вычислительной среды организации.
Выбор схемы хранения резервных данных является еще одним фактором, оказывающим существенное влияние на стоимость создаваемой системы резервного копирования. Схема хранения должна учитывать специфику организации, а также требования, устанавливаемые контролирующими органами (например для банков требования Центрального банка в отношении резервирования данных очень высоки). Кроме того, при выборе схемы хранения должны учитываться и требования, сформулированные в плане восстановления после аварий.
Большинство систем резервного копирования обеспечивают эффективное использование носителей информации за счет организации, по крайней мере, двух независимых уровней хранения данных. Так, полная копия содержит копии содержимого всех без исключения файлов системы. При инкрементном копировании в архив помещаются только те файлы, которые были изменены с момента создания последней полной или инкрементной копии. Используя различные алгоритмы резервного копирования, можно разработать стратегию резервного копирования, которая сбалансирует требования к эффективности и надежности.
Приведем пример схемы резервного копирования, которая может быть реализована в достаточно крупной фирме. Все данные копируются по субботам. С воскресенья по пятницу выполняется создание инкрементных копий. Носители информации с еженедельными и ежедневными копиями возвращаются на перезапись через месяц.
Формат хранения резервных копий должен быть таким, чтобы резервную копию при желании можно было развернуть на другой операционной системе (например, Windows). Рекомендуется пользоваться программами tar и gzip, аналоги которых существуют практически в любой операционной системе. Это позволит в случае надобности извлечь нужные файлы практически где угодно.