183
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как организовать экономный бэкап с использованием жестких ссылок

Время чтения 2 минуты
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
183
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет, вАЙТИ. Меня зовут Егор Орлов, я более 24 лет в ИТ, преподаю в СПбПУ. В этой статье мы разберем, что такое жесткие ссылки в UNIX-подобных операционных системах и как они могут применяться. А именно, как с их помощью можно значительно экономить место при резервном сохранении данных, создавая резервные копии, которые по занимаемому месту являются инкрементальными копиями, а по удобству доступа к данным аналогом полных резервных копий.

Как организовать экономный бэкап с использованием жестких ссылок

Индексные дескрипторы файлов

Погрузимся немного в особенности организации хранения файлов в файловых системах UNIX-подобных операционных систем и, в частности, Linux. Начнем с описания файла, который технически состоит из трех частей, хранящихся отдельно друг от друга.

Первая часть — имя файла

Имя вместе с идентификатором индексного дескриптора (inode) файла хранится в каталоге, к которому относится файл. Каталог — это файл специального типа с таблицей имен файлов и их номеров inode.

Посмотреть содержимое каталога можно командой ls, но, чтобы она отображала содержимое самого каталога, а не метаданных, запустите ее с таким набором параметров:


# ls -1ia /var/log | head

   352 .

   267 ..

112716 ahttpd

1905346 alterator-net-iptables

114533 audit

5842784 btmp

5842785 btmp.1.xz

 75955 chrony

3025653 clamav

259603 cups

Вторая часть — метаданные файла

В них хранятся режимы доступа к файлу, информация о владельце, даты создания и изменения. Посмотреть содержание метаданных файла можно командой stat:


# stat /etc/passwd

 Файл: /etc/passwd

 Размер: 3847          Блоков: 8          Блок В/В: 4096   обычный файл

Device: 0,28    Inode: 5033772     Links: 1

Доступ: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Доступ:        2024-06-26 08:25:52.076518894 +0300

Модифицирован: 2024-02-27 13:29:57.552367529 +0300

Изменен:       2024-02-27 13:29:57.553367531 +0300

Создан:        2024-02-27 13:29:57.551367526 +0300

Всё, кроме первой строки вывода этой команды, и есть содержимое метаданных. Они хранятся в индексном дескрипторе файла (inode), номер которого связан с именем файла через элемент в структуре каталога. Именно поэтому запись каталога указывает на индексный дескриптор с метаданными файла — эта связь имени файла и его inode и называется жесткой ссылкой.

Индексные дескрипторы находятся в специальной части файловой системы, которая называется таблицей индексных дескрипторов. Каждый дескриптор с метаданными конкретного файла — запись этой таблицы, условно ее можно назвать строкой. Большая часть файловой системы — это блоки данных.

Третья часть — содержимое

Содержимое хранится в блоках данных файловой системы. Перечень блоков с данными файла запоминается в его индексном дескрипторе.

Таким образом имя связано с индексным дескриптором, а индексный дескриптор — с блоками данных. Все три части файла хранятся отдельно, но логически связаны друг с другом.

Жесткие ссылки 

На один и тот же индексный дескриптор могут указывать несколько записей одного или разных каталогов, то есть метаданные и хранимые блоки данных одного и того же файла могут быть представлены разными путевыми именами.

Допустим у нас есть файл file1. Мы можем создать жесткую ссылку для нее командой ln:


$ ln file1 link1

$ ls -il

итого 8

12525 -rw-r--r-- 2 egor egor 42 июн 27 12:46 file1

12525 -rw-r--r-- 2 egor egor 42 июн 27 12:46 link1

Опция -i команды ls позволяет вывести номера индексных дескрипторов отображаемых файлов. В листинге выше мы можем видеть эти номера в первом столбце. Обратите внимание, что они совпадают у файла file1 и созданной командой ln жесткой ссылкой link1. Так что file1 — это такая же жесткая ссылка на метаданные, как и link1, и эти ссылки абсолютно равноправны. 

Количество ссылок на файл хранится в метаданных файла, это можно видеть в выводе ls после отображения режимов доступа. В нашем случае там теперь цифра 2.

Работа с содержимым файла возможна через любую из жестких ссылок. Работают любые операции чтения-записи через все путевые имена. Если удалить одну жесткую ссылку, это уменьшит их счетчик, но все остальные продолжат работать. А когда удаляется последняя жесткая ссылка и на метаданные файла более никто не ссылается, в таблице индексных дескрипторов соответствующая запись и блоки данных помечаются как свободные.

Жесткие ссылки можно создавать для объектов в других каталогах. Единственное ограничение: они будут работать только в рамках одной и той же файловой системы.

  

У механизма жестких ссылок существуют разные полезные варианты применения. Рассмотрим один из них.

Применение жестких ссылок при бэкапе данных

Допустим, у нас есть каталог с данными, который нужно бэкапить каждый день. Если делать это путем обычного копирования, объем резервной копии будет определяться как N × S. В этой формуле N — количество хранимых резервных копий, а S — объем, занимаемый каталогом с данными. 

В реальности далеко не все файлы, которые необходимо бэкапить, будут меняться каждый день. Скорее всего, даже наоборот: большинство данных не меняются неделями, потому что пользователи активно работают только со своими текущими проектами, не меняя при этом другие файлы. 

Логика резервного сохранения с использованием жестких ссылок получается следующая:

  1. Первую резервную копию делаем простым копированием исходных данных.
  2. Для второй резервной копии копируем только файлы, измененные по отношению к содержимому первого бэкапа. А те файлы, которые остались неизменными, в новой резервной копии заменяются на жесткие ссылки на файлы в первой копии.
  3. При последующих резервных копиях копируются только измененные данные по отношению к предыдущему бэкапу, неизменные заполняются жесткими ссылками.

С таким подходом мы получаем три преимущества по сравнению с классической схемой бэкапа:

  1. Значительная экономия места на диске. Жесткие ссылки используют только запись в таблице индексных дескрипторов, не занимая блоки данных. Места для хранения резервных копий требуется столько же, как потребовалось бы при использовании однократного полного копирования и дальнейших инкрементальных копий.
  2. Возможность доступа к данным в резервных копиях и восстановления данных при этом настолько же удобная. Все жесткие ссылки равноправны и позволяют получить доступ к данным файла, поэтому при обращении к любой из регулярных резервных копий мы видим все сохраненные данные.
  3. Накапливаемые таким образом резервные копии можно также регулярно удалять, начиная с самых старых. Данные останутся доступными через жесткие ссылки в более свежих резервных копиях.

Используем rsync для резервного сохранения

Посмотрим на пример реализации указанного выше подхода. Ниже простейший скрипт с утилитой rsync и опциями, чтобы проставлять жесткие ссылки для неизмененных по отношению к предыдущей копии данных.


#!/bin/sh

$OPT=-avHAX

TGT=$2/$(date +%F--%H-%M-%S)

LINK=--link-dest=../last

rsync $OPT $LINK $1 $TGT

LAST=$2/last

rm -f $LAST

ln -s $TGT $LAST

Скрипт принимает два позиционных параметра: каталог с исходными данными и каталог для хранения резервных копий. В каталоге резервных копий создаются подкаталоги с именами, соответствующими текущей дате (переменная TGT). Чтобы было проще находить предыдущие копии при последующих запусках скрипта, проставим символическую ссылку last в конце на каталог с только что созданной копией. Предыдущая ссылка при этом удаляется. 

Используются следующие параметры утилиты rsync:

  •   -a — стандартная опция архивирования;
  •   -H — копировать жесткие ссылки как жесткие ссылки; 
  •   -A — копировать атрибуты Posix ACL;
  •   -X — копировать контекст SELinux;
  •   -v — вывести список файлов и короткий итог;
  • –link-dest=../last — каталог с предшествующей резервной копией для создания жестких ссылок вместо копирования неизменившихся файлов.

Что учесть перед внедрением

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники