dump


dump(8) — инструмент для проведения резервного копирования, работающий на уровне дисковых блоков. В какой-то мере dump похож на tar(1). Существенное различие между ними состоит в том, что программа dump учитывает тип файловой системы и использует ее преимущества. Более подробно файловые системы будут обсуждаться в главе 8. Сейчас достаточно знать, что файловая система определяет порядок, в котором единицы и нули располагаются на физическом жестком диске. Утилита dump, в частности, совместима с файловой системой UFS2, используемой во FreeBSD. Скорее всего, начинающие системные администраторы хуже знакомы с dump, чем с tar, но dump эффективнее и безопаснее. Когда есть выбор, надо применять dump.*

Единственный недостаток dump в том, что эта утилита работает с файловыми системами, а не с отдельными файлами. Поэтому dump не подходит для сохранения каталога /etc, если не надо сохранять весь корневой раздел. Тем не менее есть возможность восстанавливать файлы по отдельности.

Положительная особенность dump: для сохранения и восстановления информации dump применяет различные программы (dump(8) и геstore(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) не распознает переменную окружения $ТАРЕ и склонен по умолчанию использовать файл устройства /dev/sa0. Однако с помощью ключа -f можно указать другой накопитель. Как и tar, утилита dump позволяет с помощью ключа -f указать файл, в котором будет сохранена резервная копия. Хотя файлы, создаваемые dump, не так пригодны для распространения, как файлы, создаваемые tar, тем не менее, это прекрасная возможность поэкспериментировать и поближе познакомиться с dump.

Прежде чем dump приступит к созданию резервной копии, она пытается определить объем доступного пространства на ленте. К сожалению, эта ее возможность не усовершенствовалась уже много лет. Когда dump только появилась, производство приводов с лентами объемом 1 Мбайт было серьезным бизнесом, и каждый производитель выпускал ленты своих форматов, следуя своим собственным стандартам. В наше время накопители стали более универсальными и стандартными, и производители обеспечивают более широкую совместимость. Емкость лент также существенно выросла, например, работая над этой книгой, я использовал привод емкостью 40 Гбайт, от которого, вполне исправного, отказался предыдущий владелец только потому, что емкость его оказалась слишком маленькой. Вот так, с улучшением стандартизации и существенным ростом емкости, dump оказалась не в состоянии определять объем доступного пространства. Чтобы обойти эту проблему, лучше всего сообщить утилите о том, что она не должна определять размер ленты, а должна выполнять дамп до достижения физического маркера конца ленты и затем запросить смену ленты. Для этой цели используется флаг .

dump и задействованные файловые системы

Одна из проблем, которая возникает при создании резервных копий работающей системы, состоит в том, что файловая система постоянно изменяется в процессе копирования. Эта проблема отсутствует в файловых системах, предназначенных для хранения статичных данных, или когда изменения в одной части файловой системы не вызывают изменения в другой ее части. Но в случае хранения динамических, постоянно изменяющихся и/или взаимосвязанных данных, это превращается в серьезную проблему. Данная проблема характерна для большинства баз данных. Иногда бывает нежелательно останавливать базу данных только для того, чтобы получить качественную резервную копию, а иногда даже невозможно создать дамп базы данных в виде файла, поэтому приходится прибегать к холодному копированию. Чтобы обойти эту проблему, dump способна использовать возможность файловой системы UFS2 по созданию «снимков» и тем самым обеспечить внутреннюю целостность резервной копии. Подробнее о снимках файловой системы будет рассказываться в главе 8, а пока достаточно просто запомнить, что снимок — это образ диска, созданный в определенный момент времени. Даже когда данные на диске все время изменяются, снимок остается неизменным и статичным, поэтому его легко можно скопировать.

Чтобы создать дамп снимка, укажите ключ -L. Если производить копирование задействованной файловой системы UFS2 без этого ключа, dump сообщит об этом и предложит использовать ключ -L.

Разумеется, это не устраняет проблем с базами данных — нахождение файловой системы в непротиворечивом состоянии не означает, что база данных, которая расположена в этой файловой системе, также находится в непротиворечивом состоянии. Однако можно остановить базу данных на короткое время, запустить dump и снова запустить базу данных, позволив тем самым утилите dump записать снимок в тот момент, когда база данных была остановлена. Это уменьшает время бездействия, необходимое для создания резервной копии, до одной или двух секунд.

Временные метки и dump

В файл /etc/dumpdates записывается все, что было сохранено в системе. Это наиболее полезно при инкрементном резервировании, когда для успешного восстановления системы необходимо знать дату последнего полного сохранения. Задав ключ -u, этот файл можно обновить.

Запуск dump

Теперь, объединив все полученные сведения, можно выполнить резервное копирование файловой системы. Здесь я задаю утилите dump: не вычислять количество необходимых лент, создавать резервную копию из снимка задействованной файловой системы и произвести копирование раздела /usr на уровне резервирования 0.

# dump -auL /usr

В этом выводе присутствует довольно много важных сведений. Во-первых, dump выводит текущую дату (1) и дату последней операции резервного копирования (2). Дата, что показана здесь, the epoch, — это лишь необычный способ сказать: «от начала времен». Как известно, эпоха UNIX началась в 1970 году, что не так давно, как можно было бы подумать. В действительности же это означает, что в файле /etc/dumpdates отсутствует какая-либо информация о резервном копировании этого раздела раньше, но это совсем не означает, что резервирование никогда не производилось.

Прежде чем приступить к работе, dump напоминает, какой раздел будет копироваться и какой накопитель на магнитной ленте будет использоваться (3).

Затем dump выполняет предварительный анализ указанного раздела, выясняет структуру файлов и каталогов и прикидывает, какой объем пространства на ленте потребуется (4). Выполнив необходимые вычисления, dump выводит результаты (5) и приступает к резервному копированию файлов (6). Через каждые несколько минут dump сообщает, как далеко удалось продвинуться и сколько еще времени потребуется для полного завершения операции, благодаря чему у вас не будет появляться ощущение, что компьютер завис. Обратите внимание, как изменяется процент выполнения и немного варьируется примерное время завершения — суть в том, что любые программные таймеры, сообщающие пользователю примерное время, оставшееся до окончания операции, никогда не обладали и, наверное, никогда не будут обладать высокой точностью, независимо от используемой операционной системы.

Завершив операцию, dump сообщит объем заархивированных данных и среднюю скорость работы (7), а затем еще раз выведет дату (8). Это не дата окончания операции — это дата создания резервной копии. Операция завершилась в 9 часов утра, но резервное копирование производилось со снимка файловой системы, который был сделан в 8:26.

В заключение еще раз сообщается, что операция закончена (9), и теперь можно вынимать ленту из привода.

Пропуск данных, помеченных флагом nodump

С помощью ключа -h системный администратор может указать, когда следует принимать во внимание флаг nodump. Этот ключ принимает уровень резервирования в качестве аргумента.

По умолчанию на уровне 0 dump архивирует все файлы, независимо от наличия флага nodump. На уровне 1 или выше dump учитывает флаг nodump. Ключ -h изменяет поведение утилиты по умолчанию и указывает минимальный уровень резервирования, начиная с которого следует учитывать флаг nodump. На любых других уровнях резервирования ниже указанного копироваться будут все файлы, независимо от наличия флага nodump.

Это дает возможность регулировать объем архивирования на уровне 0. Если резервная копия перестала умещаться на ленту, воспользуйтесь ключом -h, чтобы предотвратить резервирование файлов, отмеченных флагом nodump. Это даст вам передышку на пару дней, в течение которых вы сможете заказать новые ленты.

Комментарии запрещены.