Переход на Linux. Бэкап\восстановление пакетов\документов. Работа с ntfs

жду и приветствую решения для локального копирования данных \ восстановления данных используя стандартные средства системы Linux(консольный cp, du и т.д.).

rsync -avP --size-only /media/HDD/Back/ /media/HDB/Back/

(обратите внимание: /media/HDD/Back/ со слешем на конце = «скопировать содержимое директории»)

--size-only заставит rsync сравнивать файлы только по размеру, поскольку POSIX ACL на ntfs-3g по умолчанию не работает.

Если ещё добавить параметр -n, rsync напишет, что собирается сделать, но не сделает этого (режим dry run).

Правильно ли я понимаю, что если у меня будут файлы измененные таким образом, что не будет изменен их размер(число байт в файле останется неизменным), то мне нужно будет делать синхронизацию по контрольным суммам таким способом ?:

rsync -avPс /media/HDD/Back/ /media/HDB/Back/

Кроме того почитал параметры rsync'a, нашел параметр -r --recursive. в описании написано следующее: «Указывает rsync копировать каталоги рекурсивно. Без указания этого rsync совсем не будет копировать каталоги.». Обязательно ли мне использовать его, если внутри каталога Back есть и другие каталоги, или по-умолчанию считается, что будет копирование рекурсивно?

Еще есть вопрос по поводу проверки правильности синхронизации после выполнения rsync. Каким образом можно проверить правильность синхронизации или будет достаточно провести эмуляцию(если ничего не вывело, то все скопировано верно???):

rsync -navP --size /media/HDD/Back/ /media/HDB/Back/

Вопрос с параметр -r снят(не заметил что -a автоматически включает -r)

P.S. Если будет полезно: до этого замечал такую вещь как изменение в выводе команды du до посещения каталога через Dolphin и после посещения(без изменения файлов и каталогов). Судя по всему он оставляет там какую-то информацию.

Скорее всего, создает или изменяет файл .directory

rsync использует контрольные суммы автоматически (без параметров -c и --size-only), если видит, что атрибуты файлов (времена создания/модификации/доступа) изменились. Если заставить его использовать контрольные суммы для всех файлов, синхронизация займёт очень большое время.

rsync в какой-то степени сам проверяет себя по ходу работы, так что если он отрапортовал об успешном завершении, делать больше ничего не надо. rsync -navP можно использовать, чтобы посмотреть, чем на GNU/Linux различаются два дерева файлов.

Похоже, что проблема как-то связана с Alternate Data Streams

Не совсем, но близко. В Linux принято считать место, занимаемое собственно директорией (имена файлов, их атрибуты, размеры и т.п.), а в Windows — нет. Размеры директорий не всегда напрямую связаны с числом файлов в них. Иногда они могут иметь разный размер, даже если в них одинаковые файлы. Я не знаю способа заставить du прекратить учитывать размер директорий, но сам в таком случае пользуюсь Midnight Commander. В нём можно запросить собственный формат в статусной строке. Если поставить size:12, размеры до терабайта будут показываться в байтах.

пакетов\документов

Что это за напасть с обратными слешами? Ты когда от руки пишешь, тоже обратные косые черты ставишь?

Но мне ручное копирование и указанный выше алгоритм в принципе устраивает, в связи с чем я жду и приветствую решения для локального копирования данных \ восстановления данных используя стандартные средства системы Linux(консольный cp, du и т.д.). Но буду рад и услышать про надежные средства резервного копирования в Linux\Windows(как дополнительно).

man rsync уже советовали?

du до посещения каталога через Dolphin и после посещения(без изменения файлов и каталогов). Судя по всему он оставляет там какую-то информацию.

миниатюры картинок наверное. Потому-что всякую чушую оно хранит в своей отдельной базе AFAIK.

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

атрибуты, размеры и т.п.

ЩИТО?

Я не знаю способа заставить du прекратить учитывать размер директорий

ничего, что каталоги — тоже файлы?

(обратите внимание: /media/HDD/Back/ со слешем на конце = «скопировать содержимое директории»)

Обрати внимание, что в /media/HDB/Back/ слеш в конце не нужен.

Кроме rsync, в твоем случае можно использовать cp -u

  -u, --update
     copy  only  when  the  SOURCE file is newer than the destination
     file or when the destination file is missing

tar и md5sum, git для контроля файлов не устраивают?

tar, это слишком долго получится для 200 Gb данных. Там же не целиком другие данные, а только часть.

Решение с rsync вполне устраивает. Единственное хотелось бы еще способов для проверки действительно ли совпадают после синхронизации и размеры и количество файлов, каталогов либо суммы. du по понятным причинам не подходит. Либо пользоваться тем-же rsync с ключом -n(если ничего не вывело, то все в порядке и каталоги совпадают?). К предложенным выше решениям по rsync добавил еще ключ --delete. Как оказалось на втором бэкапе были каталоги\файлы аналогичные тем что в оригинале но с другими названиями. На windows не замечал этого(потому-что проверял через размер и количество), но после rsync'a получились дубликаты.

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