Перенос данных между файловыми системами сводится к пяти шагам: полный бэкап, создание новой ФС, копирование с сохранением прав, сверка контрольных сумм, правка fstab и загрузчика. Старая ФС остаётся нетронутой до момента, когда новая проверена и система успешно загрузилась уже с неё.
Ключевой риск в том, что запись на целевую ФС отказывает при формально свободном месте. На файловой системе с ограниченным пулом inode множество маленьких файлов исчерпывает ресурс создания объектов раньше, чем заканчивается место под данные, и такой отказ легко принять за нехватку диска. Механику двух независимых ограничений разбирает материал про место и inode. Проверяйте оба счётчика до старта копирования, а не после первой ошибки.
Дальше: чек-лист подготовки, выбор целевой ФС, готовые команды для каждого шага, методы проверки целостности и разбор ошибок, которые чаще всего ломают рабочую среду.
Почему миграция файловой системы - это риск и как его снизить
Переезд затрагивает данные, права доступа, ACL, расширенные атрибуты xattr, точки монтирования и записи в загрузчике. Сбой на любом слое даёт один и тот же симптом: сервер загружается, но каталоги пусты или доступ к файлам потерян.
Ошибки, которые встречаются чаще всего:
- бэкап не сделан либо сделан без проверки восстановления;
- rsync запущен без флагов -A, -X и -H, поэтому ACL, xattr и жёсткие ссылки потеряны;
- проверено свободное место, но не свободные inode на целевой ФС;
- копирование идёт в каталог, поверх которого не смонтирована новая ФС, и данные ложатся обратно на старый раздел;
- в fstab указан /dev/sdX вместо UUID, и после перезагрузки порядок дисков меняется.
Чек-лист подготовки перед первым запуском копирования:
- Оцените объём: du -sh по каждому каталогу и общее число файлов через find | wc -l.
- Сравните df -h и df -i на целевой ФС. Запас нужен по обоим показателям.
- Проверьте квоты, thin pool и динамическое выделение inode, если они используются в вашей конфигурации.
- Убедитесь, что новая ФС создана, смонтирована и доступна на запись от имени root.
- Зафиксируйте план откатa: как вернуть старые записи fstab и прежнюю точку монтирования.
Без бэкапа миграцию начинать нельзя. Развёрнутый разбор подготовки и сравнение методов переноса есть в статье Миграция системы хранения без потери данных.
Скрытые ограничения: inode, квоты и точки монтирования
Новый файл требует inode. Когда доступный пул исчерпан, создать объект невозможно даже при свободном месте под данные.
| Свободно места | Свободно inode | Что происходит |
|---|---|---|
| 0 MiB | 80000 | Под новые данные не осталось байтов, ресурс inode ещё доступен |
| 6000 MiB | 0 | Места по счётчику много, но новый файл требует inode, а пул исчерпан |
| 6000 MiB | 80000 | Запись всё равно не проходит: нужна проверка пути, кода ошибки, опций монтирования и квот |
Размер одного файла не описывает ситуацию исчерпания inode, и свободные гигабайты не гарантируют возможность создать ещё один файл. Для диагностики сравнивают показатели пространства и inode именно той файловой системы, куда идёт запись: показания соседнего раздела не объясняют отказ, даже если он находится рядом в дереве. Проверить, чем в действительности оказался путь назначения, помогает findmnt: он может быть отдельной точкой монтирования.
df -h /mnt/dest df -i /mnt/dest findmnt -T /mnt/dest du -sh /mnt/source find /mnt/source -xdev -type f | wc -l
Удаление множества пустых файлов может почти не помочь, если основной объём занят крупным объектом. Простая модель диагностики не учитывает квоты, резерв для привилегированных записей, metadata, thin pool и динамическое выделение inode. Свободные значения в двух колонках не исключают другие причины отказа, поэтому одной проверки df недостаточно. Подробности про два независимых ограничения собраны в разборе места и inode.
Выбор целевой файловой системы: ext4, ZFS, NTFS, exFAT
Перед копированием определитесь, куда переносите. Компромиссы между ФС видны в таблице.
| ФС | Права и ACL | Снимки и целостность | Совместимость | Ресурсы |
|---|---|---|---|---|
| ext4 | POSIX ACL и xattr | Штатных снимков нет | Linux | Низкие; число inode фиксируется при mkfs |
| ZFS | POSIX ACL, NFSv4 ACL, xattr | Снимки, контрольные суммы, send/receive | Linux, FreeBSD, TrueNAS | Высокие: память под ARC и DDT |
| NTFS | Windows ACL | VSS в Windows | Windows, Linux через ntfs3 или ntfs-3g | Средние |
| exFAT | Права Unix, ACL и xattr не хранятся | Нет | Windows, macOS, Linux, камеры, флешки | Низкие |
Для NAS и серверов с большими объёмами ZFS даёт снимки, контрольные суммы блоков и репликацию через zfs send без чтения файлов на уровне приложения. Плата за это: ZFS активно использует оперативную память под кэш ARC, поэтому планируйте ресурсы заранее. ext4 остаётся универсальным выбором для Linux-разделов с умеренными требованиями, но число inode задаётся при создании ФС, и увеличить его позже без пересоздания не получится.
NTFS и exFAT выбирают ради совместимости с Windows. Здесь важен подводный камень: при миграции с NTFS на exFAT права и ACL будут потеряны, потому что exFAT их не хранит. Для TrueNAS и других NAS-платформ с ZFS ориентируйтесь на датасеты, а не на один большой пул: так проще управлять квотами, снимками и правами.
Шаг 1: Резервное копирование и подготовка
Бэкап делается до любых операций с дисками и проверяется до, а не после. Для больших наборов данных удобнее копирование на внешний носитель или отдельный пул, для ZFS - снимок с отправкой на резервную систему.
rsync -aHAX --numeric-ids --info=progress2 /mnt/source/ /mnt/backup/source/ zfs snapshot tank/data@before-migration zfs send tank/data@before-migration | zfs receive backup/data find /mnt/backup/source -xdev -type f | wc -l
Проверка бэкапа включает три действия: сверку числа файлов, сверку контрольных сумм на выборке и тестовое восстановление одного каталога. Убедитесь также, что новая ФС создана и доступна на запись, а свободного места и inode хватает с запасом. Если целевая ФС оказалась отдельной точкой монтирования, это проверяется через findmnt и учитывается в путях копирования. Пошаговый сценарий с аудитом, первичной и дельта-синхронизацией и планом откатa приведён в руководстве Миграция данных в программные системы хранения без простоя.
Шаг 2: Создание новой файловой системы
mkfs и создание пула уничтожают всё, что было на носителе. Перепроверьте имя устройства дважды: ошибка в одной букве стирает рабочий раздел.
mkfs.ext4 -L DATA -m 1 -i 8192 /dev/sdb1 mkfs.exfat -L SHARE /dev/sdc1 mkfs.ntfs -L WINVOL /dev/sdd1 zpool create tank mirror /dev/sde /dev/sdf zfs create -o compression=lz4 -o atime=off tank/data
На ext4 плотность inode задают флагами -i (байт на inode) или -N (точное число inode). Меньше байт на inode означает больше объектов, но и больший расход места под служебные структуры: для склада мелких файлов запас по inode важнее, для архива крупных образов его можно уменьшить. Резерв блоков для root задаёт -m, и снижение с 5% до 1% освобождает место на больших разделах.
Для ZFS включайте compression=lz4 практически всегда: он дешёв по CPU и часто даёт заметную экономию. Дедупликацию включайте только после измерений, поскольку таблица DDT требует памяти и при неудачной оценке заметно замедляет запись. После создания смонтируйте ФС во временную точку, например /mnt/dest, и проверьте права записи.
Шаг 3: Перенос данных с сохранением прав и атрибутов
Основной инструмент - rsync. Каждый флаг в строке ниже отвечает за сохранение конкретного слоя метаданных:
- -a включает рекурсию, символические ссылки, права, время изменения, группу, владельца и файлы устройств;
- -H переносит жёсткие ссылки как ссылки, а не как отдельные копии;
- -A сохраняет POSIX ACL;
- -X переносит расширенные атрибуты, включая security.selinux и security.capability;
- --numeric-ids не сопоставляет UID и GID с именами, что критично, когда на источнике и приёмнике разные базы пользователей;
- --info=progress2 показывает общий прогресс вместо строки на каждый файл.
rsync -aHAX --numeric-ids --info=progress2 /mnt/source/ /mnt/dest/
Следите за завершающим слешем: /mnt/source/ копирует содержимое каталога, а /mnt/source создаст вложенную папку source внутри приёмника. Перед боевым запуском сделайте пробный проход с -n (--dry-run): он покажет, что именно будет перенесено и удалено.
Длительные операции запускайте внутри screen или tmux, иначе обрыв SSH прервёт копирование на середине. Для больших объёмов удобна схема в два прохода: сначала перенос, затем проверка и повторный запуск с --delete, который уберёт из приёмника файлы, отсутствующие в источнике. Флаг --delete применяйте только после успешной сверки.
Если целевая ФС не поддерживает ACL или xattr (exFAT, часть конфигураций с драйверами NTFS), флаги -A и -X либо выдадут ошибки, либо молча не сохранят атрибуты. Сверяйте вывод rsync, а не только код возврата. Для Windows-источников и гибридных схем переноса с сохранением NTFS-разрешений команды Robocopy и порядок проверки прав собраны в статье Миграция файлового сервера с сохранением прав доступа.
Шаг 4: Проверка целостности и сверка контрольных сумм
Проверка идёт от дешёвых операций к дорогим. Сначала структура и счётчики, затем контрольные суммы.
find /mnt/source -xdev -type f | wc -l find /mnt/dest -xdev -type f | wc -l du -sx /mnt/source du -sx /mnt/dest cd /mnt/source && find . -xdev -type f -print0 | sort -z | xargs -0 sha256sum > /root/source.sha256 cd /mnt/dest && find . -xdev -type f -print0 | sort -z | xargs -0 sha256sum > /root/dest.sha256 diff -u /root/source.sha256 /root/dest.sha256
Ускоренная альтернатива для поиска расхождений - rsync -avn --dry-run с флагом --checksum: он сравнит файлы по содержимому и покажет список отличий. На терабайтных наборах любой полный проход контрольных сумм читает все данные и занимает часы, поэтому планируйте окно обслуживания. Полезно добавить и сравнение структуры: diff -r -q даёт быстрый список отличающихся путей на наборах умеренного размера.
Отсутствие расхождений по файлам не означает, что запись гарантированно пройдёт в будущем. Наличие свободных значений и по месту, и по inode не исключает другие причины отказа: квоты, режим монтирования, отдельная точка монтирования на пути назначения. Проверку делайте комплексной, а не только по объёму данных.
Шаг 5: Обновление fstab и загрузчика
Стабильную привязку даёт UUID. Получите его и пропишите в /etc/fstab, оставив старую запись закомментированной для откатa.
blkid /dev/sdb1 # /etc/fstab UUID=0f8c1a3e-... /data ext4 defaults,noatime 0 2 mount -a findmnt /data
Проверка через mount -a до перезагрузки показывает синтаксические ошибки, пока система ещё работает. Дальше обновите загрузчик: в Debian и Ubuntu это update-grub, в RHEL и производных grub-mkconfig -o /boot/grub/grub.cfg, в systemd-boot правятся записи в /boot/loader/entries. Если миграции подверглась корневая ФС, пересоберите initramfs: update-initramfs -u в Debian, dracut -f в RHEL. Для корня на ZFS модули включаются отдельно, например dracut -f --add zfs или установкой пакета zfs-initramfs.
После перезагрузки подтвердите результат тремя командами: findmnt /, df -h и mount | grep data. Старую ФС не удаляйте сразу: держите её нетронутой до конца недели рабочей эксплуатации, этого времени хватает, чтобы выявить забытые каталоги.
Типичные ошибки и способы их избежать
| Ошибка | Последствие | Как избежать |
|---|---|---|
| Нет проверенного бэкапа | Откат невозможен | Сделать копию и протестировать восстановление |
| rsync без -aHAX и --numeric-ids | Потеря ACL, xattr, жёстких ссылок, смена владельцев | Использовать полный набор флагов и сверять вывод |
| Копирование в незамонтированный каталог | Данные пишутся на старый раздел, место заканчивается | Проверять findmnt -T перед запуском |
| Игнорирование inode | Отказ записи при свободном месте | df -i заранее, -N или -i при mkfs.ext4 |
| fstab по /dev/sdX | Система не загружается после смены порядка дисков | Прописывать UUID через blkid |
| Забыт update-grub и initramfs | Загрузка со старой ФС или паника ядра | Обновить загрузчик и initramfs, проверить перезагрузкой |
| Перенос прав на exFAT | Права и ACL не сохраняются | Выбрать ФС с поддержкой ACL либо переносить архивом |
Отдельно про расчистку места перед миграцией: удаление множества пустых файлов может почти не помочь, если основной объём занят крупным объектом. И наоборот, удаление одного большого файла не вернёт inode. Модель диагностики по двум колонкам не учитывает квоты, резерв для привилегированных записей, metadata, thin pool и динамическое выделение inode, поэтому при повторяющихся отказах смотрите код ошибки, опции монтирования и путь назначения. Разбор типичных отказов записи при свободном месте приведён в материале о двух независимых ограничениях.
Особенности миграции на NAS и в виртуальной среде
На TrueNAS и других NAS с ZFS перенос удобнее делать на уровне пула и датасетов. Создайте пул в интерфейсе, затем датасет с нужными свойствами: recordsize под профиль нагрузки, compression=lz4, atime=off, квотами по необходимости. На время сетевого переноса приостановите расписание снапшотов и задач репликации, иначе промежуточные снимки займут место и усложнят откат. Если датасет использует NFSv4 ACL, а источник отдаёт POSIX ACL, преобразование может изменить набор прав, поэтому проверьте доступ к нескольким каталогам после переноса. Три стратегии миграции на TrueNAS Scale с готовыми командами и настройкой SMB, NFS и iSCSI описаны в руководстве Перенос данных на TrueNAS Scale.
В виртуальной среде порядок другой. Сначала снимите снапшот ВМ, затем подключите новый виртуальный диск, скопируйте данные внутри гостя и правьте /etc/fstab по UUID. Если меняете контроллер диска, например с IDE на virtio-scsi, добавьте нужные модули в initramfs гостя до перезагрузки, иначе система не найдёт корень. Для ZFS в гостях проверьте, что модули включены в initramfs, а пул импортируется по метке, а не по путям /dev/sdX.
Начните с репетиции: скопируйте один каталог, не связанный с продакшеном, сверьте контрольные суммы, проверьте права через getfacl и прогоните mount -a. Такой прогон на небольшом объёме выявляет ошибки в путях, флагах и опциях монтирования до того, как они коснутся боевых данных.