CC BY
25М.С. Хрычев
ПОДХОДЫ И ПРАВИЛА РЕЗЕРВНОГО КОПИРОВАНИЯ
UNIX-ПОДОБНЫХ ОС
Актуальность выбранной темы обусловлено тем, что вопросы резервного копирования часто появляются в различных обсуждениях интернет-сообществах. Многие решения опираются на то, что достаточно архивировать данные с помощью tar, dar и других вспомогательных инструментов Unix-подобных ОС, но для того, чтобы сделать правильную резервную копию необходимо приложить немного больше усилий и обладать определенными знаниями, чтобы учесть все детали и нюансы.
Ключевые слова: unix, резервная копия, метаданные, файловая система, права доступа, дисковое пространство, индексный дескриптор.
В данной статье я постараюсь осветить основные моменты, которые необходимо учитывать, при создании правильной резервной копии, раскрою детали и нюансы, на которые, в первую очередь, необходимо обратить внимание в Unix-подобных ОС. Данная статья посвящена инженерам и продвинутым пользователям, которые в необходимой степени понимают принципы работы Unix-подобных ОС.
Создание резервных копий - очень важный процесс с точки зрения бизнеса и обеспечения сохранности информации пользователя, так как в любой момент информация может быть потеряна, в результате технического сбоя или искажения, посредством попадания вредоносного ПО в ОС.
Вы прекрасно понимаете, что в резервной копии сохраняются не только данные, но и метаданные, которые служат для того, чтобы описывать сами данные, говоря простым языком - это данные о данных. Так же должны учитываться другие факторы: файлы специальных устройств, какая файловая система используется, ее версия и атрибуты.
Данные о данных
Давайте разберем, что включают в себя метаданные файлов:
•Права доступа
•Идентификаторы пользователя и группы
•Время изменения файла/индексного дескриптора (i-node)
•Время последнего доступа
•Дополнительные атрибуты: sticky bit, SUID, SGID, блокирование
Вполне логично, если при создании резервной копии не учесть права доступа, то при восстановлении из такой копии, ОС, с большей долей вероятности, может оказаться в неработоспособном состоянии. Для примера, возьмем modification time (mtime) - время, когда было изменено содержимое файла, используется в дистрибутивах управления пакетами: rpm, yum, dpkg, apt и если не восстановить корректный mtime, то системы управления пакетами могут давать серьезные сбои.
В разных ОС семейства unix могут потребоваться различные подходы для сохранения целостности этой информации. Рассмотрим на примере использования tar, обязательно, при создании копии необходимо использовать ключ --preserver-permission, так как при жестких параметрах umask (маска режима создания пользовательских файлов) ограничения будут применяться к файлам, которые Вы собираетесь восстановить. Так же важно учитывать в каком виде хранится информация о владельце файла: текстовый или числовой. По проведенным мной исследованиям я обнаружил весьма занимательную вещь и увидел, что во многих программах для создания резервных копий, выбор пал на текстовое представление, это обусловлено тем, что такой вид более удобочитаемый для человека. Я против такого подхода, так как для создания резервной копии всей системы это очень плохое решение. Поясню, к примеру, вы решили восстановить систему с помощью Live CD, что достаточно часто происходит в реальном мире, тогда при восстановлении, файлам пользователя bin, будет присвоен идентификатор файловой системы, базирующийся на ин-
© Хрычев М.С., 2021.
Научный руководитель: Вавренюк Александр Борисович - кандидат технических наук, доцент. Национально исследовательский ядерный университет МИФИ, г. Москва.
формации из /etc/passwd с этого Live CD. Ключевой момент, что этот идентификатор в нашей восстанавливаемой системе, может быть присвоен другому пользователю и соответственно восстановленные файлы будут принадлежать совершенно другому пользователю и Вы, конечно же, понимаете, к чему это в конечном итоге приведет. Сделаем из этого вывод и правило, которое заключается в том, что всегда необходимо хранить информацию о владельцах файлов, исключительно в числовом виде. Если вернуться к tar, то это достигается использованием ключа --numeric-owner.
Необычные файлы
В Unix-подобны ОС существуют и другие, специальные файлы, о которых необходимо позаботиться и брать в расчет заранее:
•Разреженные файлы
•Жесткие и символические ссылки
•Туннели и именованные туннели
•Блочные файлы устройств
•Другие виды
Вся работа Unix-подобных ОС заключается в работе с файлами. В них нет различий между каталогами и файлами, так как каталоги — это тот же файл, который объединяет в группу другие файлы для удобства навигации, поиска и структурирования информации. Все внешние (аппаратные) устройства представлены в виде набора файлов, которые находятся в каталоге /dev и только с помощью этих файлов ОС может работать с ними.
Вспомним для чего нужны и за что отвечают каждый из видов специальных файлов.
Блочные файлы - это файлы устройств, которые обеспечивают буферизованный доступ к аппаратным компонентам. Т.е. рассматривая запись на жесткий диск, данные записываются не сразу, а накапливаются в буфере, пока не наберется достаточное количество, чтобы записать все за один раз, тем самым экономится энергия и используемый ресурс устройства.
Символические ссылки - файлы, которые указывают на другие файлы в системе по их имени. Их можно сравнить с ярлыками в Windows.
Жесткие ссылки - дополнительный указатель на индексный дескриптор (i-node). Они указывают на одно и то же место на диске и это два разных файла, с одинаковым содержимым.
Разреженные файлы - файлы, в которых нули не записываются и не размечаются в дисковом пространстве, поддержка таких файлов в файловой системе, служит для экономии места на жестком диске.
Туннели и именованные туннели - файлы, с помощью которых осуществляется связь между двумя процессами, где перенаправляется вывод одного процесса на вход другого.
Критически важно, в программах резервного копирования, учитывать разреженные файлы, так как использование программ без поддержки таких файлов, считываются как обычные и будут занимать больше места на жестком диске. Следовательно, при восстановлении копия может не вместиться на жесткий диск.
Важно учитывать сохранение всех ссылок, поэтому при разработке своей программы, необходимо учитывать сохранение целостности как символических, так и жестких ссылок. Причем с жесткими ссылками надо быть осторожнее, так как у них есть определенного рода ограничения - они должны находиться в одном древе каталогов и не могут ссылаться на файл за пределами файловой системы. В данном случае надо понимать и закладывать реализацию создания копии и восстановления одного раздела за раз. Это объясняется тем, что, если создать архив, который включает все точки монтирования, то для него необходимо предпринять дополнительные действия для того, чтобы данные были восстановлены в нужных разделах. Гораздо проще и надежнее сначала восстановить данные в один раздел, а затем скопировать и распределить части на другие разделы.
Необходимо учитывать и принципы работы туннелей, так как их необходимо не просто скопировать, а воссоздать на восстанавливаемой машине.
Работающие процессы
При создании резервной копии всегда следует учитывать процессы, которые работают в текущий момент времени, так как во время копирования данные могут быть подвергнуты изменениям. По возможности остановите работу ваших программ, где это невозможно необходимо сделать дампы в файлах с обязательной отметкой времени создания. В случае повреждения данных этих программ, всегда можно будет восстановить их состояние и исключить риск потери всех данных. Возьмите за правило, что, создавая дампы, вы всегда защищаете себя от непредвиденных ситуаций в будущем.
Принципы, которые лучше не забывать
Размер архива. В большом разнообразии файловых систем всегда есть очень важное ограничение -это размер файла. При создании любой резервной копии необходимо учитывать размер архива. Моя реко-
мендация заключается в том, чтобы создать архивы, размером чуть-чуть меньше 2 Гб, так как файлы такого размера поддерживаются почти всеми файловыми системами. Если же архив выходит за пределы данного ограничения, то лучше его разделять на части.
Копирование в другую файловую систему. Копировать файлы в том виде, в котором они есть в другую файловую систему - очень плохая идея, так как если это делать простым копированием cp -a, необходимо убедиться, что конечная файловая поддерживает все, что есть в исходной файловой системе. По этой причине надежнее сохранять данные в архивы, можно посмотреть на примере tar, dar.
Восстановление из копии. Главным критерием хорошей программы для резервного копирования служит хорошо продуманные параметры по умолчанию для сохранения всех метаданных, которые будут использоваться при создании и в последующем при восстановлении из резервной копии.
Инкрементные копии. При инкрементном подходе необходимо с осторожностью подходить к определению изменившихся данных. Рекомендуется использовать проверку контрольной суммы, но у нее есть один минус - требует больших временных затрат. Если способ с контрольной суммой не подходит, то можно использовать проверку по ctime, в этом случае файловая система так же должна поддерживать ctime, к счастью, большее множество файловых систем unix это умеют. Крайне не рекомендуется отслеживать изменения через mtime, так как в качестве примера можно привести - образы дисков, которые были смонтированы как устройства через losetup, при таком монтировании и последующей записи у них не меняется mtime.
Копия всего раздела. Самая надежная копия - это копия всего раздела, где происходит создание снимков всей файловой системы с сохранением всех данных и метаданных. В данном случае, при создании снимков, необходимо так же учитывать процессы, которые могут изменить данные во время копирования, обязательно делайте дампы приложений там, где это возможно.
Заключение
Можно сделать вывод, что создание хорошей резервной копии - достаточно сложный и трудоемкий процесс, который требует детальной проработки. Описанные выше нюансы и правила максимально примитизированы для простоты понимания, не забывайте и используйте их для разработки собственных стратегий резервного копирования и восстановления.
Библиографический список
1.Эви Немет, Гарт Снайдер, Трент Хейн, Бэн Уэйли. Unix и Linux. Руководство системного администратора.
- 2014.
2.Сэм Алапати. Современное администрирование Linux. - 2016.
3.https://www.opennetru/docs/RUS/linuxsos/ch22 1 .html.
ХРЫЧЕВ МИХАИЛ СЕРГЕЕВИЧ - магистрант, Национально-исследовательский ядерный университет МИФИ, г. Москва.
