Как я понял, зачем читать всякие статьи, когда есть man pages по любой программе.
прочитал man rsync и (что вижу в man'е - то пишу) взялся за бэкап lvm снапшота
rsync -vrhtlcpA --delete-before --progress --stats /tmp/root/ /media/wd/backup/001/а что? :)
там действительно написано, что:
-v, --verbose - отображать то, что происходит.
-r - рекурсия
-h - удобочитаемый вывод
-t - сохранять метку времени
-l - сохранять ссылки, как ссылки, а не как файлы (при восстановлении, к примеру, я восстановлю файл какой-нибудь библиотеки, а не ссылку. - реальный файл, на который ссылка ссылалась, мог поменяться (обновления прошли, к примеру), а так как вместо ссылки в каком-нибудь месте будет файл (старый. чего ему поменяться при обновлении, если это вообще раньше лишь ссылка была), то это не есть гут. поэтому - "-l"
-c - md5 проверка.
-p - сохраняю права
-A - ACL, так же
теперь (ради интеерса):
du -h /media/wd/backup/001
.....
....
6,1G,
а
du -h /tmp/root
.....
....
5,7 G!!!!!!!!!
Почитал man du
есть ключ
-L, --dereference
(Раскрывать символьные ссылки (показывать дисковое пространство, используемое файлом или каталогом, на которые указывает ссылка, вместо пространства, используемого самой ссылкой)
Ключ "-L" я не указывал. Получается, что du утилитка подсчитала все верно. Да и ключ "-l" в rsync был указан.
Отсюда, два вопроса.
1. Что я сделал не так.
2. Как правильно читать, тогда, man страницы, если у меня остались вопросы. Второй вопрос важнее.
3. Существует ли "стандарт" по ключам, которые нужны при бэкапе *nix систем. Ядро ключей (без доп. ключей таких, как "-z" итд.)
Ведь! man страница - это дока сама в себе и человек может прочитав ман, просто от фонаря начать лепить ключи, "разумно" полагая, что раз в man это написано, почему бы и не применить.
То есть, есть ли четкая дисциплина, чем нужно окружать man руководство по опр. программе, ибо форумы и "баяны" типа "как я делал то-то и то-то" есть "руководства" кустарные. В них могут быть допущены ошибки даже не частного характера, а концептуальные.
С другой стороны, ваяя самому какой-либо "план" по работе с чем-либо, получается что нужно знать все man страницы, info страницы , все rfc, уметь держать все это в уме, в реальном времени, что бы верно сделать даже крупику каких-либо действий в системе.
Отсюда получается, что должен быть какой-то третий вариант. Некий стандарт действий, что ли + стандарт пути, по которому обычный пользователь может добраться до такого руководства.
Задав же вопрос на форуме, человеку может быть дан ответ человека, кто еще меньше что-либо соображает в предмете. И дан "красиво". То есть, прочитав такой ответ, человек может и не увидеть изъяна, а спустя год у человека, кто послушает такой ответ и воспроизведет его, спросят, "а зачем ты так делаешь - так не надо" и т.д.
Наверное, золотая середина - опыт, а не всякие стандарты.
Отсюда, простой вопрос №2 из всего вышесказанного, по пункту 2:
Кто и как ищет решения. Какой документ берется за стержень и чем окружается.
Конечно, человек не машина и все тут очень динамично, но все же!
Первый вопрос по самому rsync. откуда аномалии в разности размеров каталогов.
много буков - да. кому не интересно - не вопрос. не навязываю отвечать, или ругать.
Просто, хочется разные мнения услышать.
