Те из вас, кто долго работает в сфере информационных технологий, уже не раз сталкивались с проблемой потери данных. Но мы продолжаем уделять этому вопросу слишком поверхностное внимание.
Многие считают, что аппаратура сейчас надежна, и из-за своей лени никогда не делают резервных копий. Техника хороша, но на моих глазах умерло уже несколько винчестеров, украдено из офисов 5 компьютеров, полностью сгорел вместе с кабинетом один сервер. А кто из жителей великих башен города New York думал, что к ним в гости прилетят самолеты? Кто-то скажет, что такие слава безжалостны, ведь произошла трагедия, но мы тоже не застрахованы от жестоких действий террористов, и Россия уже воочию столкнулась с этим. И как бы не было больно, закрывать на это глаза нельзя. Необходимо делать все, чтобы данные были сохранены в любой ситуации.
Резервное копирование — сохранение всех важных файлов в другом каталоге или на отдельном носителе. Если регулярно осуществлять такую операцию, то в случае непредвиденной ситуации есть возможность восстановить файлы из резервной копии и продолжить работу с незначительными потерями.
13.1. Основы резервного копирования
Чтобы финансовые потери от утраты информации были минимальными, нужно знать, откуда может прийти угроза. Помимо того, вы должны проанализировать данные, которые вы сохраняете. От этого зависит, как часто нужно производить резервное копирование и каким методом.
Скорость восстановления работы после внештатной ситуации зависит от того, как хорошо вы подготовитесь. Необходимо заранее проиграть все возможные варианты и желательно отработать процесс восстановления на практике, используя тестовую систему, чтобы не пришлось изучать по ходу дела.
Чтобы понять, что резервное копирование необходимо, давайте рассмотрим основные ситуации, когда оно помогает.
□ Случайное изменение или удаление файлов
Когда к серверу подключается новый пользователь, не имеющий достаточного опыта работы с компьютерами, то очень часто нелепые действия приводят к уничтожению данных. При правильной политике безопасности могут быть разрушены только собственные файлы пользователя, но и они могут иметь ценность для организации.
□ Нарушение работы устройств
Когда я только начинал знакомиться с компьютерами, то в обиходе были дискеты 5,25 дюймов и жесткие диски с максимальным размером в 20 Мбайт. Если винчестеры были достаточно надежны, то информация на дискетах постоянно пропадала из-за порчи поверхности носителя. С переходом на дискеты 3,5 дюйма ситуация изменилась не сильно, а вот надежность жестких дисков повышалась. Но когда мы начали оперировать гигабайтами, то в определенный момент я реально столкнулся с проблемой испорченных блоков (Bad Blocks). В определенный период (примерно за полгода) мне пришлось сменить три жестких диска разных производителей размером от 10 до 20 Гбайт. Это было как набег саранчи, которая уничтожала информацию. В настоящее время надежность дисков снова стала улучшаться, но ее нельзя назвать идеальной. Всегда есть вероятность, что диск выйдет из строя.
□ Стихийные бедствия и потеря техники
Не будем больше говорить о терроризме, потому что есть и другие причины утраты техники. Если оглянуться на конец 2004 и начало 2005 года, то замечаешь, что наша планета начинает преподносить страшные сюрпризы. Я имею в виду участившиеся наводнения, смерчи, землетрясения и пожары, которые могут уничтожать дома, офисы и целые города. Если есть резервная копия, и она хранится в другом городе (в этом поможет Интернет) или несгораемом сейфе, то восстановить данные не составляет труда.
□ Хакеры и эпидемии вирусов
Как же без этого. Это чудо информационной жизни, без которого уже никуда не денешься, и приходится выстраивать всевозможные оборонительные рубежи. Какое средство чаще всего используют для защиты от вредоносного кода? Конечно же, антивирусы, но они запрещают выполнение любого известного штамма. Но хакеры придумывают новые программы и способы обхода антивирусов. И именно они наносят максимальный ущерб, потому что для них нет еще эффективного метода лечения. Потери от эпидемий с каждым годом увеличиваются, но их можно сократить с помощью резервного копирования и восстановления.
Этот список можно продолжать еще долго, но я надеюсь, что смог вас убедить в необходимости иметь резервную копию всей значимой информации.
К важным данным можно отнести:
□ Системные конфигурационные файлы
На первый взгляд, это не так важно, потому что в таких файлах нет секретной для организации информации. Но конфигурирование ОС и всех программ с чистого листа потребует гораздо больше времени, чем восстановление через резервные настроечные файлы. А это влечет за собой потери из-за простоя, что для некоторых компаний может исчисляться миллионами рублей.
□ Документы пользователей
В директории /home могут быть отчетные документы или программы, которые необходимы пользователям для работы.
□ Базы данных
Корпоративные данные хранятся в удобном для работы хранилище — базах данных. Любая компания может понести большие убытки в случае их потери.
□ Web-сайты
Любой динамично развивающийся сайт (от корпоративного до домашней страницы) или портал содержит файлы и сценарии, потеря которых может оказаться ощутимой в денежном эквиваленте.
Базы данных требуют отдельного разговора, потому что в них резервное копирование зависит от средств, предоставляемых СУБД (Система управления базами данных). И этот вопрос мы отдельно затрагивать не будем. Но большая часть теории, рассмотренной в данной главе, может в равной степени относиться как к файлам, так и к базам данных.
13.2. Доступный на все 100%
Если посмотреть на возможные источники потери данных, то видно, что наиболее вероятными будут вторжения хакера или нарушение работы оборудования. Если в первом случае достаточно восстановить утерянные файлы, то во втором может потребоваться замена оборудования с полной переустановкой системы. Чтобы этот процесс не отнял слишком много времени, лучше всего заранее иметь в наличии комплектующие, которые могут выйти из строя — жесткий диск, память, материнская плата, процессор.
Если в вашей сети каждая минута простоя сервера может оказаться фатальной, то лучше поступить одним из следующих способов: построить кластер или содержать резервные серверы.
Наиболее надежным является построение кластера. Если один сервер выходит из строя, то его нагрузку берет на себя другой. Это позволяет добиться практически 100% устойчивости оборудования от вероятных неполадок. Но организация кластеров — достаточно сложное и дорогостоящее занятие, поэтому компании стараются найти любые другие возможные варианты.
Большинство программ промышленного назначения уже имеют встроенные средства кластеризации. Их работа достаточно простая и дешевая. В сети находятся несколько серверов, один из которых является мастером (Master), а остальные — подчиненные (Slave). Основной компьютер регулярно посылает в сеть информацию о своей работоспособности и передает подчиненным серверам изменения, которые происходят в базе данных, чтобы на всех машинах была одинаковая копия БД. В том случае, когда связь с главным компьютером прерывается, всю работу на себя берут подчиненные серверы.
Помимо повышения надежности работы кластер может увеличивать и производительность, если все серверы будут функционировать параллельно и нагрузка будет распределена равномерно. Это позволит более эффективно использовать оборудование и пропускную способность сети.
Более дешевым вариантом является использование резервных дисков. Допустим, что у вас есть один сервер, который должен быть всегда доступен пользователям. В нем устанавливаем дисковый массив RAID (Redundant Array of Independent Disks, матрица независимых дисковых накопителей с избыточностью) и обязательно с поддержкой зеркалирования (Mirroring), т.е. RAID 1 или RAID 1+0.
Примечание
RAID 1 — зеркалирование (два диска содержат одну и ту же информацию). RAID 0 — параллельная запись на два диска, за счет чего скорость доступа к устройству увеличивается, но на безопасность это не влияет. RAID 1+0 — комбинация зеркалирования и параллельной записи.
В этом случае RAID заботится о сохранности данных, т.к. их запись производится на два диска одновременно. Если один из них сломается, то полная копия есть на другом.
А что если выйдет из строя материнская плата или процессор? Их замена потребует времени, а мы договорились, что это недопустимо. Чтобы сократить простой в случае нештатной ситуации, подготавливаем заранее сервер с идентичной конфигурацией оборудования. В случае нарушения работы железа достаточно подключить RAID-массив к резервному серверу, переключить сетевой кабель и можно продолжать трудиться. Так как оборудование на обоих компьютерах одинаковое, переустановка системы не потребуется, и RAID будет работать на другом, сервере без изменения конфигурационных файлов.
Если в вашей сети несколько серверов с одинаковой конфигурацией, то один резервный компьютер может служить заменой для любого из них. Таким образом, обеспечение сохранности данных становится намного дешевле построения кластера.
В одном офисе я видел очень интересное решение. На всех клиентских компьютерах были установлены маленькие жесткие диски, на которых работала только ОС и необходимые ей файлы и программы. Помимо этого у всех были подключены большие диски через Mobile Rack (устройство, позволяющее сделать винчестер съемным). Администратор каждый вечер снимал эти диски и делал резервные копии на своем компьютере.
Такой подход позволяет при возникновении проблем с железом или ОС снять жесткий диск и перенести на другой компьютер. Для этого у администратора всегда есть подготовленный системный блок, который может заменить испорченное оборудование.
13.3. Хранение резервных копий
Несмотря на использование RAID 1 и кластера, резервное копирование никто не отменял, и его делать необходимо. Но куда производить резервирование? Однажды меня вызвали восстановить данные после выхода из строя жесткого диска. Воскресить информацию, конечно же, не удалось, потому что винчестер вышел из строя окончательно и бесповоротно, поэтому я задал вполне логичный вопрос: "А где резервная копия?". Ответ был прост (впрочем, как и владельцы компьютера), запасная копия делалась на тот же диск, но только в другой раздел. Некоторым людям очень тяжело объяснить, что при поломке винчестера, как правило, становятся недоступными все его разделы, а не один из них.
Но самое интересное во всей этой истории то, что диск начал рассыпаться уже достаточно давно. Так уж получилось, что основной раздел был в начале диска, а раздел для резервной копии — в самом конце. Уже несколько месяцев во время резервирования происходили ошибки доступа, и никто не обращал на это внимания. Диск явно начал сыпаться, начиная с раздела, на котором хранилась резервная копия, и постепенно испорченные блоки покрыли весь винчестер.
Резервную копию всегда нужно делать на отдельный носитель. Это может быть как отдельный жесткий диск, благо цены на них падают не по дням, а по часам, или любой сменный носитель достаточного объема.
Хранение на отдельном носителе позволяет решить проблемы с оборудованием, но не гарантирует защиту от воровства или стихийных бедствий. Меня поражают администраторы, которые используют сейфы для хранения абсолютно бесполезных бумаг, гарантийных талонов, а резервные копии помещают в простой деревянный ящик. Хочется спросить таких людей: "А зачем вы защищаете сервер всеми доступными средствами, когда можно просто украсть копию данных из шкафчика?"
Резервная копия тоже должна быть под надежной охраной. Лучше всего воспользоваться несгораемым сейфом, тогда вашим данным не страшны даже стихийные бедствия.
В настоящее время в Интернете снова начинают расширяться услуги по предоставлению дискового пространства. Сделав резервную копию на сторонний носитель, можно быть уверенным, что данные будут надежно спрятаны. Владельцы сервисов защищают такие диски с помощью RAID-массивов, поэтому на сервере информация не исчезнет.
Можно с уверенностью сказать, что такой подход к хранению данных будет развиваться, потому что компания Apple с помощью своей новой технологии iDisk сделала интернет-диски удобными и доступными для своих и Windows-пользователей. На очереди и остальные системы. Подробнее о технологии iDisk можно узнать на сайте компании Apple http://www.mac.сom/1/iTour/tour_idisk.html (рис. 13.1).
Рис. 13.1. Сайт, посвященный технологии iDisk от компании Apple
Если для вас использование подобного диска слишком дорого (например, неприемлемы затраты на трафик из-за большого количества данных), то о сохранности резервных копий придется позаботиться самостоятельно.
В качестве носителей информации в настоящее время можно использовать съемные жесткие диски, магнитные ленты, CD-R/RW, DVD-R/RW, диски JAZ, ZIP. Выбор конкретного носителя зависит от размера данных и необходимой скорости резервирования.
В настоящее время появились очень удобные внешние винчестеры, подключаемые по USB или FireWire. Такие диски легко переносимы и имеют большой размер. В домашних условиях я использую именно такой носитель, сбрасывая все данные с ноутбука на жесткий диск.
13.4. Политика резервирования
От того, как вы будете резервировать данные, зависит скорость проведения операции и потери после восстановления. Если информация на сервере занимает сотни гигабайт, то необходимо достаточно много времени на ее копирование, что вызовет большую нагрузку процессора. Если процедура выполняется по сети, то и канал связи будет перегружен, что сделает сервер менее доступным.
Ваша задача организовать резервирование максимально эффективным методом, чтобы оно занимало как можно меньше времени, и при этом создавалась копия всех необходимых данных.
При планировании резервирования вы должны учитывать, что если произойдет поломка жесткого диска, то все изменения, внесенные с момента создания последней копии, будут потеряны. В связи с этим необходимо сохранять важные данные как можно чаще, но при этом не забывать, что это достаточно накладный процесс для сервера.
Итак, сколько носителей информации нам понадобится, с какой частотой и как их использовать? Это зависит от многих факторов:
□ хранящаяся информация;
□ частота изменения данных;
□ наличие возможности ручного восстановления большого количества потерянных данных;
□ максимальное время простоя (недоступности) сервера;
□ категория наиболее часто меняющихся данных.
И этот список можно продолжить, но мы на этом пока остановимся. А просто начнем рассмотрение. Нужно четко себе представлять, какие данные в системе изменяются. После этого разделите их на три группы в зависимости от периодичности модификации: часто, редко и с определенным интервалом.
Основные директории, которые должны резервироваться:
□ /etc — содержит конфигурационные файлы;
□ /home — пользовательские файлы;
□ директория, содержащая Web-файлы.
В остальных каталогах администраторы редко держат документы или файлы, требующие дополнительного копирования. Программы из директории /bin или /usr нет смысла дублировать, потому что их легко переустановить, особенно если сохранена вся конфигурация.
13.4.1. Редко, но метко
К нечасто изменяемым файлам можно сразу отнести конфигурационные файлы (директория /etc). В этом каталоге массовые корректировки происходят на этапе установки сервера. Затем компьютер может работать годами, и изменения происходят в случае обновления программ или внесения каких-то поправок.
Для хранения конфигурации хватит даже самого небольшого носителя с невысокой скоростью. Единственное требование к нему — должна быть возможность перезаписи. Я для этих целей использую ZIP- и JAZ-диски. В заархивированном виде достаточно одной дискеты.
Так как конфигурация изменяется редко, то можно делать копии сразу после внесения правок. Для этого достаточно записать измененный файл на диск без копирования всех конфигурационных файлов.
При восстановлении данных необходимо всегда начинать с конфигурации, в первую очередь с файлов /etc/passwd и /etc/shadow. Если этого не сделать, то ни одна программа не сможет установить правильные права доступа.
Воссоздание прав может произойти неверно, особенно нужно уделить этому внимание, если вы применяете дополнительные средства фильтрации разрешений, используя программы, предоставляемые сторонними разработчиками.
Прежде чем восстановленную систему сделать доступной, необходимо убедиться, что все файлы находятся в том же состоянии, как перед сбоем, особенно права доступа.
13.4.2. Зачастили
Часто изменяемыми могут быть базы данных и основные файлы и документы пользователей (директория /home), которые корректируются каждый день. Их резервные копии можно и нужно создавать ежедневно. Если процесс копирования отнимает слишком много времени, то следует это делать после рабочего дня или в обеденный перерыв, когда нагрузка на сервер ниже. Чтобы не сидеть над компьютером в такие моменты, можно создать сценарии, которые будут выполняться по расписанию. Если производить резервирование два раза в день (в обеденный перерыв и в конце рабочего дня), то в случае аварии вы рискуете потерять изменения только за полдня (с момента резервирования до сбоя системы).
Для этих данных я использую 7 перезаписываемых носителей. Каждый из них я называю соответственно дням недели, потому что в понедельник копирую информацию на диск с надписью "Понедельник", во вторник пишу на диск "Вторник" и т.д. Помимо этого, каждый понедельник все данные записываются на одноразовый носитель типа CD-R или DVD-R.
13.4.3. Часто, но не все
Далеко не все файлы в директории /home изменяются ежедневно. Большинство из них не трогается годами. Чтобы не тратить каждый раз время на такие данные, можно использовать команды, которые позволят копировать только то, что корректировалось. Самый простой вариант — выбрать все файлы, у которых дата изменения находится в определенном промежутке времени.
При использовании такой политики можно действовать следующим образом:
□ в конце недели производится полное копирование директории /home;
□ каждый день можно сохранять измененные файлы.
В случае аварии восстановление должно происходить точно в той последовательности, в которой происходило резервирование. Сначала воссоздается полная копия. Потом по очереди возвращаем на место все файлы из резервных копий. Если порядок будет нарушен, то вы рискуете заместить новый файл более старым.
Копирование данных по дате изменения удобно, но доступно не всегда. В большинстве утилит есть только обновление существующей копии. В этом случае сначала создается полная копия, а потом с помощью специального ключа задается обновление файлов, которые были изменены.
Этот способ хорош, но он заменяет все старые файлы. После этого нельзя откатиться назад и узнать, что было до последнего резервного копирования. С другой стороны, при наличии полной копии для восстановления достаточно скопировать ее в систему, и работа может продолжаться.
Каждый день изменяется не так уж много файлов, поэтому резервирование будет происходить достаточно быстро, и его можно делать в процессе работы сервера. Но в данном случае вы рискуете испортить документы. Допустим, что есть два файла, информация в которых жестко связана. Если во время копирования одного файла другой будет модифицирован, то в резервную копию первый попадает измененным, а второй — нет. После восстановления могут возникнуть серьезные проблемы в работе, потому что нарушится целостность данных.
13.4.4. Периодично
Данные, которые изменяются с определенным интервалом, нужно резервировать в соответствии с этим параметром. Например, некоторые файлы используются во время ежемесячной отчетности. Как правило, они достаточно большого размера, и создавать регулярно резервную копию не имеет смысла. Намного эффективнее делать это в конце отчетного периода, а потом весь месяц не тратить ресурсы на лишние операции с неизменяемыми данными.
13.4.5. Полная копия
Наиболее надежным способом является создание полной копии всего жесткого диска. В этом случае информация может сохраняться в независимости от файловой системы, потому что программа копирует весь диск (один к одному), используя прямой доступ к дорожкам. Восстановление полной копии гарантирует, что все права настроены четко, и программы сразу же готовы к использованию.
Но этот способ имеет достаточно много недостатков:
□ необходимо много времени;
□ слишком большая нагрузка на сервер;
□ невозможно реализовать средствами Linux. В большинстве дистрибутивов нет необходимых программ;
□ в резервную копию попадают все файлы, и даже те, которые не являются необходимыми, например директория /tmp.
Резервирование полной копией очень удобно использовать для переноса данных на другой сервер или тиражирования конфигурации. Например, вам необходимо настроить несколько однотипных клиентских компьютеров. Сконфигурируйте один, сделайте его полную копию и восстановите на остальных машинах. Такой метод надежнее, чем простой перенос файлов с одного компьютера на другой.
13.4.6. Носители
Теперь рассмотрим, сколько носителей нам понадобится для хранения всех резервных копий. Для каждого типа данных нужны свои носители, потому что их копирование происходит с разной периодичностью и рассматривать их надо отдельно:
□ конфигурационные файлы. Мы уже определились, что для них достаточно ZIP- или JAZ-диска. Желательно иметь две одинаковых копии, потому что любые дискеты портятся и выходят из строя намного чаще, чем жесткие диски;
□ периодично обновляемые данные. Их лучше всего записывать на съемный носитель и хранить длительное время. Я для этих целей использую CD-R, потому что его объема достаточно для моих данных и при этом информацию нельзя стереть. Каждый месяц я делаю такой диск и сохраняю его в течение года. Таким образом, я по резервной копии всегда могу просмотреть данные за любой отчетный период;
□ часто обновляемые данные. При выборе носителя главным критерием должна быть скорость работы, потому что чаще всего эти данные имеют большой размер. Резервное копирование должно производиться максимально короткое время, чтобы сервер не ощутил долговременных нагрузок.
Как видите, политика резервирования зависит от многих факторов. Я постарался показать вам основные принципы, по которым вы должны строить свою схему. Предложенный в этом разделе подход не сможет одинаково подойти для всех систем, но его можно использовать как базовый.
13.5. Резервирование в Linux
Мы будем рассматривать только те возможности, которые уже реализованы в Linux. Я не буду рекламировать сторонние разработки. Я вообще не люблю кого-то выделять, потому что могу недооценить другие продукты, с которыми я не работал или не знаком в достаточной степени.
А что есть встроенного в Linux? Это простые команды копирования и архивирования, которые можно автоматизировать, прописав в планировщике задач. Если резервирование требует выполнения нескольких директив, то из них можно создать файл сценария для ОС, который будет выполнять все необходимое.
13.5.1. Копирование
Самый простой вариант создания резервной копии — использование команды cp (копирование файлов). Только в этом случае необходимо обязательно сохранять права доступа к файлу. Вот как может выглядеть команда, дублирующая директорию /home на примонтированном к системе диске /mnt/resdisk:
cp -a /home /mnt/resdisk
В данном случае я использовал ключ -а, который равносилен указанию сразу трех ключей (-dpR):
□ -d — не следовать по символьным ссылкам. Мы копируем каталог в таком виде, как он есть;
□ -р — сохранять права доступа к файлу;
□ -R — копировать каталоги рекурсивно, чтобы на архивный диск попали все файлы и подкаталоги.
Получается, что команда, показанная выше, идентична следующей:
cp -dpR /home /mnt/resdisk
С помощью этой директивы мы создаем полную копию каталога. А как можно сохранить изменения? Для этого необходимо произвести копирование на тот же диск, только с указанием ключа -u:
cp -au /home /mnt/resdisk
Таким образом будут скопированы все файлы из директории /home, дата изменения которых позже документов из директории /mnt/resdisk.
13.5.2. tar
Копирование по одному файлу не очень удобно. Лучше, когда все находится под одной крышей. В Linux есть утилита, которая собирает все файлы в один. Этот процесс называют архивированием, но вы должны учитывать, что tar не сжимает файлы. Если вы объединяете файлы общим размером в 2 Мбайта, то архив будет иметь размер чуть больше (размер всех файлов плюс заголовок tar).
Преимущество сборки целой директории в один файл состоит в том, что им проще потом управлять и сжимать специализированными программами.
Для архивирования, как минимум, нужно выполнить команду:
tar cf архив.tar директория
Здесь у нас два параметра:
□ c — указывает на необходимость создания архива;
□ f — назначает архивный файл или устройство (по умолчанию используется /dev/rmt0).
Итак, для архивирования директории /home выполняем следующую команду:
tar cf backup.tar /home
При использовании параметров cf файлы в архив попадают с сохранением пути. Если распаковать созданный нами чуть выше архив, то в результате в текущем каталоге будет создана папка /home, а в ней уже будут располагаться все пользовательские директории. Например, если разархивировать из директории /home, то папки пользователей окажутся в /home/home, а если находится в /etc, то пользователи увидят свои директории в /etc/home.
Чтобы добиться правильного результата, нужно перейти в корень диска и выполнять команду там:
cd /
tar xf /home/backup.tar
В данном случае мы из корневого каталога разархивируем резервную копию, которая находится в файле /home/backup.tar.
Помимо этого, для архивных операций могут пригодиться следующие ключи утилиты tar:
□ v — вывести на экран информацию об архивируемом (или распаковываемом) в данный момент файле;
□ z — найти и обработать при распаковке gzip-архивы;
□ p — разархивировать всю информацию о безопасности;
□ d — найти отличия между архивом и файлом в системе;
□ t — просмотреть содержимое архива;
□ u — обновить файлы в архиве, которые были изменены;
□ n date — добавить в архив только те файлы, которые изменены позже даты, указанной в параметре date.
□ P — не удалять первый символ "/". В этом случае, откуда бы вы не распаковывали, файлы попадут на свое родное место.
С помощью утилиты tar можно архивировать сразу несколько директорий. Следующая команда помещает в архив /home и /etc:
tar cf backup.tar /home /etc
Чтобы просмотреть содержимое архива, можно выполнить команду:
tar tvf backup.tar
В ответ на это, на экране будут показаны все файлы и директории архива, их права доступа и владельцы. Результат можно увидеть в листинге 13.1.
Листинг 13.1. Результат просмотра содержимого архива
drwx------ 504/504 0 2004-11-27 20:24:05 home/adr/
drwxr-xr-x 504/504 0 2004-11-27 20:24:05 home/adr/.kde/
drwxr-xr-x 504/504 0 2004-11-27 20:24:05 home/adr/.kde/share/
-rw-r--r-- 504/504 118 2004-11-27 20:24:05 home/adr/.gtkrc
-rw-r--r-- 504/504 24 2004-11-27 20:24:05 home/adr/.bash_logout
-rw-r--r-- 504/504 191 2004-11-27 20:24:05 home/adr/.bash_profile
-rw-r--r-- 504/504 124 2004-11-27 20:24:05 home/adr/.bashrc
-rw-r--r-- 504/504 5 2004-11-27 20:24:05 home/adr/text
-rw-r--r-- 504/504 2247 2004-11-27 20:24:05 home/adr/.emacs
Посмотрите на последнюю колонку, где показано расположение файла. Обратите внимание, что путь не начинается с символа "/", указывающего на корень диска. Поэтому такой архив нужно распаковывать в корне, иначе он будет создаваться в текущей директории.
13.5.3. gzip
В ОС Linux есть достаточно много различных утилит для упаковки данных. Наиболее популярной из них является gzip. Преимущество архивирования над простым копированием данных заключается в том, что результирующая копия занимает меньше места, а значит, носитель для резервирования нужен меньшего объема.
Чаще всего резервированию подлежат документы, размер которых в заархивированном виде может уменьшаться на 90%. Текстовые данные сжимаются намного лучше, чем программы.
Недостаток архивирования — возрастает нагрузка на процессор и может потребоваться больше времени на создание полной копии.
За счет того, что архив занимает намного меньше места, его копирование на сетевые ресурсы или запись на съемные носители (ZIP, JAZ, CD-R/RW, DVD-R/RW и др.) будет производиться быстрее. В итоге может получиться, что временные затраты на архивирование (с учетом занятости процессора) будут равны времени на копирование без архивирования.
Прежде чем сжимать какой-либо файл, рекомендуется подготовить tar-архив. Потом достаточно выполнить команду упаковки:
gzip -уровень файл.tar
В качестве ключа -уровень нужно указать степень компрессии. Максимальный уровень равен 9. После этого указывается имя tar-архива. Давайте сожмем архивный файл, который мы создали из директории /home, применяя наибольшую компрессию. Выполните следующую команду:
gzip -9 backup.tar
Теперь просмотрите содержимое директории (команда ls). Обратите внимание, что файла backup.tar больше нет. Вместо него появился backup.tar.gz, размер которого значительно уменьшился.
Чтобы разархивировать такой файл, можно пользоваться все той же командой tar, только необходимо указать ключи xfz:
cd /
tar xfz /home/backup.tar.gz
Эта команда сначала разархивирует gz-файл и тут же распакует tar-архив.
Если необходимо из gz-файла снова получить tar-архив (без его распаковки), то можно выполнить команду:
gzip -d /home/backup.tar.gz
После этого вы снова можете увидеть файл backup.tar, а backup.tar.gz исчезнет.
Теперь вы готовы написать свой сценарий, который будет собирать директории для архивирования в tar-файл, а затем сжимать его, чтобы уменьшить его размер. Но зачем использовать две команды, когда можно обойтись одной. Вот как это делается:
tar cvf - /home | gzip -9с > backup.tar.gz
В данном примере мы собираем в tar-архив директорию /home и тут же сжимаем ее утилитой gzip.
Помимо gzip для архивирования иногда используется утилита compress, но ее возможности по сжатию ниже, и к тому же вокруг нее были скандалы и разбирательства по поводу лицензии. Большинство администраторов уже перешли на использование gzip, и я вам рекомендую с самого начала привыкать к этой программе.
13.5.4. dump
Все предыдущие команды, которые мы рассматривали в данной главе, не являются специализированными командами резервирования. Это просто команды копирования и архивирование файлов. Утилита dump предназначено именно для создания резервной копии файловой системы Ext2.
Для выполнения резервной копии нужно, как минимум, указать:
□ -n — уровень резервной копии, который может изменяться от 0 до 9. При значении о создается полная резервная копия. Уровни выше 0 означают формирование резервной копии изменений, произошедших с момента последней полной резервной копии или создания копии с меньшим уровнем;
□ -u — требование при удачном завершении резервирования обновить файл /etc/dumpdates, в котором хранятся даты резервных копий;
□ -f файл — имя файла или устройство, на которое нужно производить резервное копирование.
Итак, простейшая команда создания полной резервной копии выглядит следующим образом:
dump -0u -f /home/backup.bak
Для сохранения изменений нужно изменить уровень, указав значение больше нулевого, например:
dump -1u -f /home/backup.bak
Для восстановления файлов из архива используется команда restore. Но прежде чем ее запускать, вы должны убедиться, что находитесь в директории, которая принадлежит восстанавливаемой файловой системе.
Директиве restore достаточно только указать ключ -f и файл, который нужно восстановить. Если применить ключ -i, то вы попадаете в интерактивный режим, в котором можно задать файлы для восстановления. Интерактивный режим похож на командную строку, в которой можно путешествовать по архиву и выполнять следующие директивы:
□ help — вывести краткую помощь по доступным командам;
□ ls — отобразить содержимое текущей директории;
□ pwd — показать текущую директорию;
□ add директория — добавить в список для восстановления указанный в качестве аргумента каталог;
□ cd — сменить текущую директорию;
□ add директория — удалить из списка восстановления директорию, указанную в качестве параметра;
□ extract — восстановить все файлы из списка;
□ quit — ВЫХОД.
13.6. Защита резервных копий
Нет смысла защищать систему, если компакт-диски с резервными копиями беспорядочно лежат у вас на столе. Резервные копии хранят все основные данные компьютера, и если диск попадет в руки хакера, то уже не надо будет ничего взламывать.
Однажды я видел, как секретные данные с хорошо защищенного сервера каждый час копировались на простой компьютер пользователя, на котором все настройки были установлены по умолчанию. Такую систему хакер взломает за пять минут.
К защите резервных копий нужно подходить со всей ответственностью. Самый простой вариант — поместить их в сейф. Но лучше будет зашифровать файл перед записью резервных копий на носитель. Напоминаю, что сделать это (для примера с файлом backup.tar.gz) можно с помощью пакета OpenSSH, используя следующую команду:
/usr/bin/openssl des -in /home/backup.tar.gz -out /home/backup.sec
В ответ на это будет создан файл backup.sec. Именно его и надо записывать на носитель для долгосрочного хранения. Только не забудьте удалить потом с диска файлы backup.tar.gz и backup.sec.
При восстановлении файл сначала необходимо расшифровать:
/usr/bin/openssl des -d -in /home/backup.sec \
-out /home/backup.tar.gz
После этого уже можно разархивировать все файлы на свои места.