фон:
Будучи немного трусливым, я до сих пор имел ddцелые файловые системы для резервного копирования. Главным недостатком стало чрезмерное использование памяти для этих полных резервных копий (которые, к сожалению, также включали свободные блоки)
вопрос
Я хотел бы сделать резервную копию только файлов внутри файловой системы, но при этом иметь возможность пересоздать файловую систему, если это необходимо. Хотя данные могут быть легко извлечены (например, через rsync -a),
мне интересно, есть ли какие-тослучаиЯ упускаю из видугденапример,Будет ли иметь значение номер inode, назначенный файлу?
Это особенно актуально на фоне резервного копирования /корневой файловой системы с системой на ней. Я не так уж беспокоюсь о файловой /home/системе, но достаточно изобретателен, чтобы ожидать, что может произойти что-то странное при восстановлении /корневой файловой системы, и вдруг иноды изменились?
Хороший ответ включал бы в себя наиболее полный список случаев, в которых номер inode может иметь значение и в конечном итоге вызывать проблемы.
обновлять Некоторые эксперименты показывают, что, например,жесткие ссылки(естественно ссылаясь на тот же самый inode) может потребоваться некоторое внимание. Не уверен, нужно ли их переназначать обязательно тот же самый inode.
К счастью, количество жестких ссылок на простом Ubuntu 12.04 составляет всего около 10 файлов (чтобы я мог записать их в скрипт и восстановить при необходимости, и rsync -aмне было бы неважно количество инодов).
Пример один случай, который я считаю важным, это случайселинуксмодуль безопасности, поскольку он в основном использует номера инодов. Так что это уже один случай, но, возможно, есть и другие.
Обновление2
Я только что запустил тестовое резервное копирование и восстановление фиктивной системы Ubuntu 12.04 с использованием rsync -aHпри переформатировании раздела между этим для настройки новой ext4 с помощью mkfs.ext4 /dev/sdX -U oldfsUUID. По сути, когда файлы были восстановлены, все наиболее часто используемые иноды больше не были связаны с исходными. К счастью, поэтому кажется, что для этого одного случая моей установки Ubuntu 12.04 иноды, похоже, не имели значения. Я знаю, что это не доказывает многого. Я все равно был бы признателен за ответ со списком проблемных случаев. Тот, который selinuxя уже упомянул, но я думаю, что их может быть больше, и, следовательно, есть шанс получить хороший ответ от кого-то, кто знает.
решение1
Номера инодов не имеют значения для обычных приложений. Это отчасти потому, что номера инодов используются редко, а отчасти потому, что если бы приложение зависело от номеров инодов, оно бы перестало работать после цикла резервного копирования и восстановления. Поэтому системы резервного копирования не восстанавливают номера инодов, поэтому приложения от них не зависят, поэтому системам резервного копирования не нужно восстанавливать номера инодов.
Большинство подходов к резервному копированию даже не смогут восстановить номера инодов. Драйвер файловой системы в ядре использует любой свободный инод при создании файла, нет способа ограничить это из приложений.
В некоторых файловых системах даже нет номеров инодов.
Единственное, для чего приложения используют номера инодов, — это проверка того, обозначают ли два пути один и тот же файл: сравните номер устройства и номер инода в определенный момент времени. Для этого номер устройства и номер инода не обязательно должны оставаться постоянными с течением времени. Сами программы резервного копирования делают это для обнаружения жестких ссылок.
Нет способа открыть файл по номеру его инода или получить путь к файлу по номеру его инода (за исключением инструментов отладки, требующих доступа к базовому блочному устройству). В большинстве файловых систем путь указывает на инод, но инод не содержит указателя на каталог, содержащий файл, поэтому это невозможно реализовать без обхода всей файловой системы. Кроме того, файл может быть даже удален (например, может иметь счетчик жестких ссылок 0, ожидая закрытия, прежде чем его содержимое будет удалено, а его инод освобожден).
SELinux использует иноды для отслеживания контекстов, а не номера инодов. Контексты SELinux хранятся с использованием путей, как и все остальное.
rsync -AHX— безопасный и распространенный способ создания резервных копий.
Я могу вспомнить одно приложение, которое использует номера инодов: некоторые версииНегодяй, одна из первых полноэкранных игр на основе терминала, которая мотивировала библиотеку Curses, используемую до сих пор. Она сохраняет номер inode в файле сохранения, чтобы предотвратить случайное копирование файлов сохранения. Я никогда не видел, чтобы это делалось в «серьёзном» приложении.