Восстановление ACL

Переносил 4Тб данных при помощи rsync и не учел сложную структуру доступа, переносить по новой с правильными ключами - ждать еще 8 часов. Поэтому я выгрузил рекурсивно ACL:

root@server:~$ getfacl -R /archive_mount/archive > /home/user/archive2023.acl

и хотел загрузить вот так:

user@server:~$ sudo setfacl -R --set-file=archive2023.acl /archive/archive/

но, эта фигня зависла на всю ночь и никакого результата не дала, в итоге я нашел как именно восстановить ACL:

user@server:~$ sudo setfacl  --restore=/home/user/archive2023.acl | tee /home/user/report_acl.log

Для проверки я повторно выгрузил ACL после восстановления, т.к. восстановление заняло не больше пяти минут, а выгрузка из оригинала длилась полчаса. Собственно выгрузка за те же пять минут подсказала, что проблема скорее в дисковой подсистеме источника, а не в частичном восстановлении ACL

root@server:/home/user# getfacl -R /archive_mount/archive > /home/user/archive2023_2.acl
root@server:/home/user# tar -cf archive2023.tar archive2023*
root@server:/home/user# gzip archive2023.tar
root@arhive:/home/user# ll /home/user/
root@arhive:/home/user# ll archive2023_2*
-rw-rw-r-- 1 user user   392713145 Jan 24 10:58 archive2023_2.acl
-rw-r--r-- 1 user user   384913154 Jan 23 23:21 archive2023.acl
-rw-r--r-- 1 root root    29577829 Jan 24 11:01 archive2023.tar.gz

Можно было бы сравнить эти два файла прямо на сервере (cmp), но как видим из вывода выше - новый файл больше старого, т.е. они уже разные, поэтому я решил сравнить их при помощи Notepad++

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